Ep#98 – Taylor Smith – Breaking Down the Latest in Software Security Standards & the Impact on SaaS Businesses

Speaker 1 (00:06):

You’re listening to The Virtual CISO Podcast, a frank discussion providing the best information security advice, and insights for security, IT, and business leaders.

If you’re looking for no BS answers to your biggest security questions, or simply want to stay informed and proactive, welcome to the show.

John Verry (00:26):

Hey there, and welcome to yet another episode of The Virtual CISO Podcast. With you as always, John Verry your host, and with me today, Taylor Smith.

Hey. Taylor.

Taylor Smith (00:35):

Hey, John. How are you doing?

John Verry (00:36):

I am doing pretty darn good today. How about yourself?

Taylor Smith (00:40):

I can’t complain. Friday.

John Verry (00:42):

You can complain, but it’s not going to do you any good anyway, so don’t bother, right?

Taylor Smith (00:45):

Right.

John Verry (00:46):

So I always like to start folks off easy. Tell us a little bit about who it is that you are and what is it you do every day?

Taylor Smith (00:53):

So I’m Taylor Smith. I am a penetration tester, specifically the network and application penetration testing lead at Pivot Point Security. I’ve been here since 2016, so you’ve been dealing with me for a while. I’m getting old, John.

John Verry (01:10):

Anybody who’s looking at this image, not listening to your voice is going to look at that and go, “How the hell is she saying she’s getting old?”

Taylor Smith (01:19):

But my day-to-day is a good variety. I do participate a lot in penetration testing clearly, but as of late, we’ve been shifting a lot into helping with compliance models, maturity models, and getting businesses and development teams up to speed on the current security standards which has opened a lot of interesting doors, so we’re going to talk a lot about that today. So it’s very exciting.

John Verry (01:43):

Yeah. We’re definitely at an inflection point in the application security space. It’s remarkable how fast it’s changing.

I always ask, what’s your drink of choice?

Taylor Smith (01:53):

So they say that the security industry runs on caffeine and bourbon, and I lean to the caffeine. So I drink specifically Pipeline Punch Monster energy drink, and a lot of it.

John Verry (02:04):

So you just gave me an idea for another business that we need to do, caffeinated bourbon.

Taylor Smith (02:10):

Ooh. It’s like a heart attack.

John Verry (02:13):

Then the information security industry doesn’t have to choose.

Taylor Smith (02:17):

Finally, an option for everyone.

John Verry (02:19):

You see my brilliance, clearly. I can tell by that look on your face.

Taylor Smith (02:24):

John, you’re an idea man. What can I say?

John Verry (02:27):

All right. So I’m going to apologize to anyone who listened to the podcast that I did with Elzar Camper, with regards to the SSDF, the Secure Software Development Framework, because I’m going to steal a little bit of the beginning here.

So 2011, Marc E. Andreessen very famously said software is eating the world, because at that point, he thought that software would transform entire industries and not shockingly, as brilliant as he is, he was right.

So what we’ve seen is, as software has really transformed that, it’s also transformed scrutiny.

Early on, most of the scrutiny that we did of applications was what I’m going to refer to substantiative testing, or what some people call dynamic application security testing, and maybe a little bit of code review. And we know that didn’t work real well.

We’ve shifted to better models. So things like the OWASP application security verification standard, where we’re shifting left a little bit.

But even more so, as you said, we’re hitting this inflection point right now where folks are trying to move security left, and the way you move security left is to drill in a little bit more into the software development lifecycle methodology and make sure that the model that we’re using is something which is likely to produce a secure piece of software at the end, and this idea and using one of those tools, the OWASP SAMM is really what the focus of this podcast is about.

So for folks that may be familiar with that buzzword, SDLC, can you define what an SDLC is just a level set here?

Taylor Smith (03:55):

Sure. So the SDLC is the Software Development Life Cycle, and it’s used to describe the internal business practice of developing software, but it’s such a broad term.

So you’ll look it up on Google and you’ll get your little circle images with eight to 13 different steps and it’s nice and clean. But as software has become more complex, so has the Software Development Life Cycle.

So we get into the weeds a lot, talking about things like Agile development, so it’s easier to keep things simple by just referencing the Software Development Life Cycle.

And as a security person, it hasn’t always been thrilling. Software Development Life Cycle takes into account security, but it has never been the biggest focus. The main focus with the development life cycle is to develop, so up to this point, that has been the big focal point.

John Verry (04:43):

Yeah. And sometimes you’ll hear that phrase, SSDLC, where someone will put a secure Software Development Life Cycle, and I think that’s meant to suggest that it is a more security enriched version of an SDLC.

Taylor Smith (04:55):

Right. And you’ll also hear OWASP references in SAMM a lot, the SDL, which is secure development life cycle. Lots of vague terminology there, but we’ll get into it.

John Verry (05:07):

One thing we’re not short of in information security is acronyms, right?

Taylor Smith (05:10):

That’s the true. The alphabet soup.

John Verry (05:12):

Exactly. All right.

So now that we’ve got a good understanding or a good definition, if you will, of SDLC, what is the OWASP SAMM?

Taylor Smith (05:20):

So brief history. The original SAMM model is from 2009 and it was originally known as O SAMM. And despite minimal support, it’s been pretty sound and used for over the past 10 years.

So before I start going into what it is, I just want to make it clear this has been around for a while. We’re currently on the version two, which is just called the OWASP SAMM.

And to put it in OWASP beautiful language, it’s the Software Assurance Maturity Model, that’s what SAMM stands for, and it’s meant to assess the SDL, secure the dev life cycle, quantify its maturity, and we’ll get into that too, or rather, its current level of secure functions, and then provide guidance on adjustments and changes that can increase that maturity and improve overall security.

It’s a mouthful, but if I had to cut it to one sentence, it’s a measuring tool to help improve the general security of software in development, and it supports the entire life cycle.

So the whole purpose of SAMM is to not just shove it in at some point during the SDLC, but for it to be an integral part to the entire SDL, so it’s also very flexible.

So it’s a maturity model that is tailored to the needs of all different development teams, cycles, businesses, and structures. Really cool.

John Verry (06:36):

So you mentioned a couple times and used that phrase, maturity model. Tell me what you mean by a maturity model and how can we use a maturity model to improve the security of our applications?

Taylor Smith (06:48):

So we see maturity models a lot outside of cybersecurity. They’re higher level business usage sorts of tools.

The idea of a model is that you’re not perfectly replicating reality, but you’re building something that can simulate it in such a way that it gives you valuable output.

But basically, it’s just attempting to measure continuous improvement. And the term maturity references the improvement levels of the varying stages of the SDLC.

So where it may be used to try to put a number to current business functions somewhere else, what we’re doing with SAMM is focusing on the SDL by taking a look into the maturity of business functions over time to influence security improvements.

I know that sounds like a lot of jargon that doesn’t really explain what maturity means, but as you start to look at the various business definitions in SAMM, it starts to make sense what a mature application may look like versus a… They don’t like to use the term immature. They use the term terminology less mature.

So the model is built to help with continuous improvement, and that’s why the term maturity is used because it’s just like a child growing up.

You start small. You get big. Mature.

John Verry (08:02):

Got you.

So most maturity models run from a zero to five, where zero is absolutely doesn’t exist. Three is moderately mature, well documented. Four is usually continuously improving. Five is usually optimized.

Does SAMM work on a similar model?

So at the end of an assessment, you’re going to have scores associated with different practices, and then we’re going to say, “Well, that score is, or isn’t reasonable and appropriate to your particular risk of the application and the types of data you process,” and then we’ll set a target.

Is that the way that you’re typically working with it?

Taylor Smith (08:39):

You’re pretty much nailing it from a simple perspective.

So SAMM is built into five different business functions, and then each of those business functions is split into different security practices, so three security practices per business function.

And then each of those practices is scored on a one to three scale, with one being least mature, three being most mature.

And then each one of those practices also has a stream. And those streams are the activities that can be performed to improve the maturity level of that particular security practice.

So you will, during a SAMM assessment, be using that scoring methodology to produce scores, one to three with decimals in between, to quantify the maturity of each individual business function.

And the business functions are pretty generic, so they do have straightforward nomenclature, but there are things that even if internally a business or a development team doesn’t have defined, they will recognize what those definitions mean and can adjust them for their own needs.

John Verry (09:44):

Got you. I know that I’ve seen the phrase that SAMM is prescriptive, so it sounds like those streams would be the prescriptive guidance that we would use to help someone move from one maturity level to the other, to the next?

Taylor Smith (09:59):

Yeah. So that is when while the scoring is the initial assessment, the whole goal of SAMM is for it to be an ongoing process of growth. So it does reference those streams to provide activities in that prescriptive model.

So each one of those streams gives a varying level of reference. And one of them, I like to reference as a sample when I’m trying to explain this to clients, I like to look at the verification business function, which we’ll go into detail about each business function, but that’s where you find my job. You find the penetration testing details.

And in the verification function, there’s a security testing requirement.

And the stream A, which is the more scalable stream, that’s the more flexible stream, tends to be easier to achieve. And for that particular business function, it’s do automated testing. Nice and easy. Nice and prescriptive. You’re able to do something, in addition, that can improve your security posture.

And then stream B tends to be a more advanced approach, which can jump you up to the next maturity level.

So for stream B, it’s performed manual security testing of high risk components. It’s all that penetration testing work.

So that’s where the streams come into play is with it being a prescriptive model of maturity, and that’s how you’re able to take your development from one stage to the next.

John Verry (11:25):

When you’re doing application security pen testing, we tend to favor doing our testing against the OWASP application security verification standard.

So I was chatting the other day with a client and I jokingly referred… I was talking with them about shift left. They didn’t seem like they had much of an SDLC, so I was trying to get them to think about looking at the SDLC.

So we started talking about SAMM, and they were a little bit confused about, “Well, I thought you said I should use ASVS versus SAMM,” and I jokingly referred to it as like, “You got chocolate in my peanut butter and I got peanut butter in your chocolate.”

And with another client, I referred to it as, “If you know the symbols of yin and yang. The ASVS has got that little dot of SAMM in it and the SAMM has that little dot of ASVS in it in a weird way.”

So can you talk a little bit about SAMM and ASVS and how in a mature program that’s producing really great applications that those two standards would be supportive of each other.

Taylor Smith (12:21):

Yeah. And I like that chocolate peanut butter approach because I like to call it a peanut butter jelly sandwich. So it’s the same mindset, but I love ASVS.

So ASVS serves as more of a template. It uses a series of controls, which is like a really big to-do list that developers can use internally as a metric to build their application. But then testers can also use those same requirements to test the application and perform a full scale penetration test.

So it’s a twofold tool. OWASP says it’s a threefold because it also provides guidance, which I still feel is on that internal side.

But that area is where you start to get a lot of overlap with SAMM. A lot of what ASVS uses as requirements can often mirror what SAMM influences in its various business functions, and in its activities associated with different streams.

So technically, a pen test fits into the verification business function, and that’s where all that security testing occurs. It’s a validation.

But really when you’re looking at ASVS and SAMM side by side, a lot of stuff also falls into other business functions.

I like to pair these two as one project, because then you’re getting the best of both worlds. You’re referencing both SAMM and ASVS, and a developer can use the requirements from both to cover the majority of their security bases.

A lot of the activities in SAMM end up actually meeting requirements for ASVS and it provides a general framework of activities to make you feel a little less lost.

SAMM tends to be a little less piecemeal than ASVS. It’s very general and it’s built that way so that it is flexible so that different teams and different development styles can use it.

ASVS is significantly more granular. It gives you very precise definitions and very precise requirements that you can adjust according to your particular applications needs, but it gives you a little bit more of a technical direction.

So when you pair these two [O OFF 00:14:19] projects together, you get something really, really valuable. You get the full security coverage which is like more than you can ask for.

John Verry (14:28):

Yeah. Sort of like one plus one equals three.

What I said to someone the other day about it, is that when you look at SAMM and a SAMM assessment, it validates that you’ve got the right processes in place to result in an application which is secure. And then when I talked about ASVS, I said it is a mechanism to validate that the net application that you did develop using the SDL is secure.

So they fit together in that way because you can have a well defined process that for one reason or another doesn’t yield exactly what you expected to at the end. And they work together in this continuous improvement model.

Are you familiar with, and you mentioned a little bit about the history, and I might be wrong about this and I should have done some research before I say this, but my recollection is that BSIMM and SAMM, at one point they started life together. And some of our clients occasionally will say to me, “Hey, this sounds a little bit like BSIMM.”

Is SAMM and BSIMM pretty similar?

Taylor Smith (15:30):

So yes and no. They have similar origins, so you’re right. You’re not totally dumb here. BSIMM branched…

John Verry (15:34):

I am totally dumb and right. I think it’s really more appropriate, right?

Taylor Smith (15:40):

They’re not mutually exclusive, are they, John?

John Verry (15:44):

No. And by the way, neither is bourbon and caffeine. I’m telling you. If I’m not paying attention to you, you’ll realize why. I’m getting rich in my head with this caffeinated bourbon idea.

Taylor Smith (15:56):

You got to hurry up before the market goes.

John Verry (15:59):

Yeah, we can’t release this podcast because I don’t want my idea getting out before the intellectual property has been locked up with a patent.

Taylor Smith (16:06):

We’ve already ruined it. But either way, so BSIMM did come from SAMM. It diverged from the original SAMM project, so that one that’s been around since I was about a child.

John Verry (16:20):

Don’t remind me.

Taylor Smith (16:21):

I’m catching up.

John Verry (16:21):

Me too. It’s just slightly older. More mature.

Taylor Smith (16:24):

A more mature model.

John Verry (16:26):

More mature child than you.

Taylor Smith (16:28):

John, we went to college together, come on.

But BSIMM is very narrative. If you read through BSIMM, and the OWASP guys have referenced this a couple of times through their various trainings and through conversations I’ve had with them.

Whoever wrote BSIMM had a good sense of humor is the running joke, but it’s very narrative and it’s very concrete, and it’s good. I’m not here bashing BSIMM for being creative and narrative.

BSIMM is structured to observe and report. It is descriptive rather than SAMM’s prescriptive.

It is not there to provide you guidance. It is not there to be flexible for you. It is there to determine if you are meeting the guidelines set by the particular BSIMM security model. And in case you needed the acronym, I don’t know if we said it, it’s the Building Security and Maturity Model.

So it’s also a maturity model, but in being descriptive, it’s going in and seeing things as they are, defining them and scoring them, while SAMM is meant to do something similar with more of a focus on continuous improvement rather than trying to get the best score.

SAMM very specifically states in all its documentation and all its tools that your goal isn’t necessarily to get the high score. It’s not to win the game. It’s more to meet the security requirements that fit the needs of your particular business strategy or your application development strategy.

While BSIMM tends to be a bit more concrete in, “Here are the requirements you need to meet, and here’s a very strict set of guidelines to do that.”

So one of the metaphors that I’ve seen used is BSIMM is walking into a room and saying, “You don’t have lights in here,” and then SAMM is going into a room and saying, “You don’t have lights in here. Here are your five different lighting options for how you can meet this requirement.”

John Verry (18:20):

Got you. And I think to some extent, A, the fact that we’re huge fans of OWASP and we already using the ASVS, and B, that type of more helpful guidance is why we tend to lean more towards SAMM. But I don’t think we’d be unhappy if we heard someone was using BSIMM because we know that if someone used BSIMM well, they’d also end up in a good spot.

Taylor Smith (18:41):

Yeah. And I think in our case, we just need a lot of that flexibility because we have clients from every type of business, every type of maturity level and all across the globe. So with OWASP, we’re getting something that is a lot more case specific so that if we come across something that just doesn’t fit what BSIMM might require, we can kind of work with them in a way that makes more sense for their use case.

John Verry (19:10):

Yeah. The folks at OWASP do a good job with all of their frameworks of dealing with context. So even within the application security verification standard, this idea that we have three different levels depending upon the risk of your application, rather than just, “Hey, here’s how you build a secure app.”

So that kind of flexibility is just inherent in a lot of the stuff they do, which is, like you said, for consulting organization that works for the diversity of organizations, super helpful.

Okay. So I always like to where possible, move a little bit more to the tangible realm.

Because we’ve talked about SAMM and I think we’ve done a great job of explaining to people why SAMM is relevant, let’s drill in a little bit and let’s talk a little bit, and put some meat on this bone a little bit.

Let’s maybe just walk through the business functions a bit, and maybe you can give us some concrete ideas of how they work and what some of those practices might be associated with them.

So let’s start with governance. That’s the first business function of SAMM.

Taylor Smith (20:08):

Sure. And as we go through, you’ll notice… So every single business function has three pieces, but there’s always one piece that seems to serve as the finest definition, if I had to put a definition on a sticky note.

So for governance, I always like to look at its policy and compliance. That being said, it also has strategy and metrics, and then education and guidance as its three separate strategies.

But policy and compliance speaks to the businessy side, and I think a lot of that makes sense when you’re talking especially to non-technical individuals, because oftentimes in compliance, you are required to educate and guide, and you’re also required to maintain a strategy and some form of metric.

But governance is that concept of maintaining, and it gets a little in the weeds because when you’re talking about SAMM, you’re looking at the development strategy. You’re looking at the application development, but a lot of the pieces can apply to an entire company’s culture, so I try not to get too muddy with this.

But basically, the governance covers all the various requirements that would be associated with maintaining things like metric and log, any policies that need to be met, and compliancies that need to be met for various security requirements that can be stateside, federal, industry-specific.

And then educating and guiding staff specifically to follow secure practices, and that tends to be one of the more difficult pieces in development, simply because the developers typically know what they’re doing from a technical level, but when security gets into the mix, it can get a little foggy.

So go governance is more of the management, almost of people rather than strictly of the application and then strategy, and metrics, and policy, and compliance fall into that.

John Verry (22:08):

Got you. And then next function that they have is design.

Taylor Smith (22:10):

Yes. So pretty much everything but governance, I really, really love because it speaks to my technical soul.

John Verry (22:18):

And it explains why I like the govern one, right?

Taylor Smith (22:22):

Yeah, right. I was going to say which tunes your favorite, John?

John Verry (22:24):

Yeah. When you knew that.

Taylor Smith (22:25):

But design is, it demonstrates how SAMM gets in at every level of the development life cycle, that the design is supposed to try and catch the application before it gets to a point of use. So threat assessment, making and defining firm security requirements, and then security architecture, security at the core. And these three activities are all associated with the direct design of the application and it can get…

And that’s the thing with SAMM is everything gets a little muddy, but this is really how an organization defines the software within its development projects, and that goes as far as lethal architecture.

One of the examples I like to pull in this is things like suppliers come into this one a lot. So if you’re getting code from someone else, if you’re getting materials from someone else for testing, that falls into the security requirements of design. It’s evaluating the supplier. Making sure requirements are available for suppliers to see. Making sure you have all the documentation and the various maturity levels of that design element, then play into that.

John Verry (23:36):

And that would be like right now, with all of the emphasis on the secure software development framework and SBAM software bills of material, that supplier security and ensuring that those third party libraries that we’re using are secure. That would be how that would interface with those, right?

Taylor Smith (23:53):

Right.

And then design also contains the threat assessment. That’s when you’re trying to quantify your risk of attack. That’s where you’re trying to quantify what is this application going to be vulnerable to? And that’s why a lot of that third-party stuff also comes into play. So it all just starts to fit in really in a nice bundle because the three pieces all play off of each other.

John Verry (24:15):

Got you. The third function is implementation.

Taylor Smith (24:18):

Implementation. So these are all the activities that are related to deployment. So builds and deployment, and different versions of the applications.

And these ones seem, based on their verbiage, a little bit more broad. So you’ve got secure build, secure deployment, and defect management, which are all things that any developer is really familiar with. If you can code without bugs, you’re miracle.

So this is more so looking at your build process, looking at your deployment process, to make sure that everything is secure from every set. And the various maturity levels have to do a lot with records and dependencies, and making sure that there’s a process for handling the pipeline overall, and then making sure that nothing gets lost in the process. There’s no interception during the build process. Any defects are managed properly.

At no point in the maturity model, does it say, “There’s no problems,” but it does speak to the flexibility of SAMM. It’s just like, “Okay, here are the things that you need to have ready for deployment. Here are the things you need to have ready for release.” A lot of basic protection measures. A lot of life cycle tracking, documentation. Documentation all day long.

John Verry (25:37):

I know that the next function is your favorite. Verification.

Taylor Smith (25:37):

Yeah. This is my favorite. So I’m a little biased. Verification is where I live, technically speaking.

I don’t like to say that all the pen testing stuff has to stay in verification because a lot of what we provide in the value is in our reports that you can use in other parts.

But verification is where you are making sure that all your security policies that you’ve put in place, either in all the other business functions or just in general, are working how they’re supposed to.

So you’ve got architecture assessment, requirements driven testing, and security testing. And these three different pieces all require different kinds of assessment, but oftentimes, you can get them… well, I’m speaking from a Pivot Point Security experience.

So for us, we like to try and provide these in a bundle, but looking at your architecture, making sure that you’re getting proper testing, making sure that you’ve got proper documentation, and then you’re having third party or internal review of that documentation of architecture and inventory to make sure everything is where it’s supposed to be.

Requirements driven testing, which is typically testing for things like security controls or code testing. This is where a lot of talking about the actual code comes into play as far as security is concerned.

And then security testing, where you’re going to have a lot of requirements in the streams that sound pretty straightforward. Get tested, specifically.

And I like that it defines security testing and then application testing separately. So even though the entirety of stream B is all perform manual penetration testing to some degree, it’s all different kinds of penetration testing.

So I feel like it’s one of the harder areas to mature because you need to get that oftentimes, outside or oftentimes, especially trained in on that, and that can be very time consuming, but once you’ve got that implemented into your development routine, it’s awesome.

John Verry (27:37):

Quick question for you, and this is where your deeper technical expertise is. I get a little fuzzy on some stuff.

So increasingly, it seems as folks go towards Agile, DevOps, CICD, there’s a little bit of a blurring between that verification.

So in an old Waterfall methodology, you’d get everything built and then you would do the testing. But as we now are integrating… On some of these tests and some of these… There was an example.

We’ve got architecture validation, some component of architecture validation is to ensure that the infrastructure is where it’s supposed to be. And at this point, it’s infrastructure is code and it’s maybe being done through some form of code review.

Same idea with maybe we’re integrating some form of code scanning in. Does that code scanning and things of that nature fit into that verification stream? Does it fit into the implementation stream?

Where does that fit?

Taylor Smith (28:30):

So it does end up fitting into-

John Verry (28:32):

Or a little bit of both.

Taylor Smith (28:34):

-Technically, on paper, verification.

I would say, as far as the work that you’re going to be doing, as far as the man hours, you’re going to be looking at verification and implementation.

A big thing that we run into a lot is trying to encourage security testing in the process. You have the code, but you have not fully finished the application build. Get the code assessed, someone who can read the code, review scan, and find issues before implementation continues.

But that process requires a lot of overlap with the implementation structure, which then requires a lot of overlap with the design. So you’re going to see a trend where things technically fit under one sense of the model, but then they fall into three or four of them at a time.

John Verry (29:24):

Yeah. So it’s like many things these days. You present something in a linear fashion, but there is natural iteration within.

Taylor Smith (29:34):

Right. And I think that’s why OWASP visually, when they display these as a table, it’s a falling table, and it’s a path because you can visually and mentally build connections through the various different parts and move blocks around as you need it. It feels more natural for it to fall than for it to flow.

John Verry (29:54):

Right. Now that we’ve got this implemented and validated, the next and last process is operations.

Taylor Smith (30:03):

Operations, and this business function I want to say is not from the original SAMM.

While they were building out version two, they added an additional piece to the model.

So operations, every piece of it says management, incident management, environment management, operational management. And it’s all the things that you have to do every day to maintain the CIA triad, essentially. And it’s the operational lifetime of an application and all the data it handles.

So when I doodle this on my project sketches, this is CII. This is making sure that your confidentiality, your integrity, and your availability stick around.

So this is another one that’s difficult to mature because it’s always going to be changing. And that being said, every piece of this model can change at any time. That’s the part of growth, and especially with security, things are never static.

But this is where the dependencies start to really ramp up because this is how you’re going to be up-keeping your application long term.

So this is making sure that you’re logging data, making sure that you have well documented processes for all kinds of incidences, environmental controls, operational controls. This is also where you’re going to be managing things like access, user management.

It’s a big one. And even though it’s got the Same number of streams and maturity levels as, as everything else. A lot of it is just going to end up being more time consuming and more costly to document just in my humble opinion, just because it is this is the long term.

And I think that’s why, and I don’t want to speak for OWASP, but the addition of this has been really positive, I think, because it makes developers think in the long term.

I think when you’re building something and you’re on SCRUM, and you’re working day to day, and you are finally getting down to the crunch of an application, the idea of up keeping it for 10, 15, 20 years can be really exhausting, so this helps a lot.

John Verry (32:10):

Right. And a great example of that is whoever built, I forget the name of the company that built the physical security cameras that were integral to the Mirai Botnet. No one ever thought about patching and updating, and firmware updates of those devices, and of course, those devices became vulnerable, and somebody was able to take them all over and launch Gigabit Level, distributed in hour service attacks for that reason.

So I agree with you completely, that I think that this is an amazingly important update, even just the idea of ensuring that they understand that they’re integral to ensuring that the application is creating the information necessary to detect and respond to an incident which is going to have grievous and negative impact to an organization.

So I agree. Really cool that they added this on. Thanks for pointing that out. I’m embarrassed to admit that I didn’t realize SAMM one did not include this.

Taylor Smith (32:59):

No, you’re good.

A lot of the goal that OWASP was trying to make was to try and maintain that cross compatibility.

So we see there’s documentation available, crossing SAMM with BSIMM, crossing SAMM with SSDF, which is NIST, and it’s hard to fully equate things in such different frameworks and such different models.

So the addition has complicated the paperwork a little bit, but I think overall, the benefits have been tangible.

John Verry (33:31):

You mentioned SSDF. We’ve mentioned that a couple of times. I do think that it’s important to point out, and I think it’s a nod, if you will, to OWASP SAMM that the Secure Software Development Framework, which came out from NIST, NIST 800-218, references for all of the controls, the equivalent SAMM guidance, and when we’re doing work with our clients with SSDF, we’re pretending to do a combination of SAMM and SSDF together, correct?

Taylor Smith (33:59):

Absolutely. And a big part of that is SSDF, at this time of the recording, has not fully released their exact requirement guide. And a lot of things in happen that way. A lot of developments in security are organic, so to compensate that they do reference SAMM a lot. They do have references to BSIMM, but I favor the connections between SSDF and SAMM, and that’s why we do combine those two, particularly when we’re working with clients who are going to be needing to meet the SSDF requirements, but don’t know how to do it. SAMM gives them a really, really good baseline that’s really flexible to their business model, and it has like that blessing from NIST directly in its documentation, so.

John Verry (34:44):

I’m looking through my notes. I think we beat this up pretty good. Anything we missed from your perspective?

Taylor Smith (34:49):

Not at the top of my head. Just constantly singing the praises of OWASP over here.

John Verry (34:54):

Yeah. I’m a big fan of anybody that produces open, trusted guidance, and I can’t think of anybody who produces any more trusted guidance than OWASP.

All right. So hopefully, you’re going to come up with something good here. Give me a fictional character, a real world person you think would make an amazing or horrible CISO and why?

Taylor Smith (35:11):

So I’m hoping someone hasn’t already done this one, but I just finished re-watching…

John Verry (35:16):

You mean you haven’t listened to every single podcast we’ve ever done and cataloged every amazing and horrible CISO?

Taylor Smith (35:23):

Hey, I did, but I lost my notebook, John. I left it on the train.

John Verry (35:28):

Oh, my razor thin ego has been terribly bruised, Taylor.

Taylor Smith (35:33):

That’s been my job for six years, John, but I just finished my re-watch of Jurassic Park and Ian Malcolm, dear sweet Jeff Goldblum. I think he would be the best, worst CISO because he lives for the anticipation of constant chaos, and I think that’s an important part of the job, but damn, he’d be annoying.

John Verry (35:59):

Yeah. You could pick Jeff Goldblum out of a number of movies. What was it? The End of The World, The Fly. There’s a number of movies where you could make an argument that he’d be really good or really bad.

All right. If folks wanted to reach out, what’s the easiest way to get in touch with you?

Taylor Smith (36:16):

Pivot Point Security, [email protected] is the easiest way to find me. All my other social media is very snarky. So you can find me on Twitter, @Boomslang, and I’ll send you how to write that.

But I do a lot of penetration testing posts, lots of technical material, but I also do malware analysis and write ups as well.

I don’t like to be caged, so lots of materials and a lot of just sharing OWASP.

I strongly advise going to OWASP and just eating everything there, because their documentation is top notch.

John Verry (36:50):

I could not agree with you more. And on that note-

Taylor Smith (36:53):

We’re free.

John Verry (36:54):

-We’re done.

Thank you, Taylor.

Taylor Smith (36:55):

Goodbye, John.

John Verry (36:56):

Appreciate it. This was a lot of fun.

Taylor Smith (36:58):

Awesome. And I will talk to you later.

Speaker 1 (37:02):

You’ve been listening to The Virtual CISO Podcast.

As you probably figured out, we really enjoy information security, so if there’s a question we haven’t yet answered or you need some help, you can reach us [email protected].

And to ensure you never miss an episode, subscribe to the show in your favorite podcast player.

Until next time, let’s be careful out there.