Press Release
What exactly is a Software Development Life Cycle, and how does NIST’s Secure Software Development Framework impact that cycle and your organization?
Of note, the SSDF will definitely impact you if your software is used by the US Government and will likely impact you even if it isn’t. There are a few choice practices that can help make sense of these two critical processes and provide the highest chance for success.
I invited Elzar Camper, Director of Cyber Security Solutions & Practices at Pivot Point Security, onto the show to unpack SDLCs, the SSDF and lay out the shifting landscape of government regulations and software development.
Join us as we discuss:
- Defining SDLC’s and the SSDF
- Four core best practices in cybersecurity
- Assessing existing procedures and adapting to the SSDF
- How you can use the SSDF to your advantage
To hear this episode, and many more like it, you can subscribe to The Virtual CISO Podcast here.
If you don’t use Apple Podcasts, you can find all our episodes here.
Listening on a desktop & can’t see the links? Just search for The Virtual CISO Podcast in your favorite podcast player
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, Mr. Camper. How are you today, Elzar?
Elzar Camper (00:36):
I’m doing great. How you doing, Mr. Verry?
John Verry (00:38):
Good. A little bit less noisy than Friday when we originally scheduled?
Elzar Camper (00:43):
Yeah. The construction has calmed down in my building, so it’s actually tolerable. So much a much better day.
John Verry (00:48):
And I forgot to put my headphones on.
Elzar Camper (00:50):
Yeah.
John Verry (00:50):
Yeah. Jeez.
Elzar Camper (00:51):
The joys living in the city.
John Verry (00:52):
Yeah. Listen, everything has pros and cons to it, right?
Elzar Camper (00:58):
Yeah, absolutely.
John Verry (00:59):
All right. So except for software security, nothing but pros there, we can agree on that, right?
Elzar Camper (01:04):
Absolutely. Yeah.
John Verry (01:04):
All right. So I always like to start super simple. Tell us a little bit about who you are and what is it that you do every day?
Elzar Camper (01:13):
Okay. So I am the practices director at Pivot Point Security. You are my boss, and I was mandated today to be here for this podcast, which I’m extremely excited to be here for it. No. So no, Pivot Point Security, been here about eight months now, maybe 10 months now, actually. And it’s something that I’ve been looking forward to coming back to working here, working with you again. Started 17, 18 years ago, my career in cyber security with yourself and happy to be back. Spent that in-between time in the federal government working the state department. I had the joy of being a diplomat for a long time, working at embassies and concerts overseas. So happy to be home and happy to be back at Pivot Point.
John Verry (01:50):
Yeah. Well, we are absolutely happy to have you as well. So I always ask, what’s your drink of choice?
Elzar Camper (01:57):
So it’s interesting. I was going to say bourbon, and it’s true, but I know you’re-
John Verry (02:00):
You’re just catering to me.
Elzar Camper (02:02):
No, no. You know what it is, though? I know you’re a bourbon guy. So you’ve asked me any real deep questions about bourbon, I can’t answer them. So I’m going to go with extra dirty martinis, vodka. Yeah.
John Verry (02:13):
That’s comical. So over the weekend I told you that I was out with the family when we did a brewery, three breweries, and we stopped in Brooklyn and we stopped for dinner, and for some reason my daughter looks across the table at me and she goes, “You know what I really want to order? I’ve never had, but I’ve always wanted to try it because I think I would look sophisticated.” I’m like, “What?” She goes, “A dirty martini.”
Elzar Camper (02:36):
Nice.
John Verry (02:36):
So I started laughing. But she doesn’t want to do it because she doesn’t want to get a bad drink. So of course, what do I do as the good dad? I order a dirty vodka martini.
Elzar Camper (02:47):
Nice. But you’ve got to do the blue cheese olives, you know? They take it up a notch. If you’re going to show me really fancy, you’ve got to do the blue cheese olives.
John Verry (02:52):
I had just regular olives, and I will admit it was pretty good.
Elzar Camper (02:55):
Yeah.
John Verry (02:56):
Although, she takes two sips and goes, “Yeah, it’s okay,” and enjoyed her drink while I choked it down.
Elzar Camper (02:56):
Yeah.
John Verry (03:01):
All right. So today’s conversation is around the software development framework, and as I was preparing for it, I wanted to use the quote, “Software as eating the world,” because I thought that was such a great quote. And I could not believe that Marc Andreessen coined that in 2011. If you think about how cognizant he was of where we were going, it was a nod to how software he thought would transform entire industries. And we’ve seen that come to realization. And as software has transformed our everyday lives, and it absolutely has, it’s also transformed the risk environment that we live, right? And the logical reaction to that is greater software scrutiny.
And initially, we probably got a little over our ski tips, so to speak, and really we weren’t paying enough attention to information security from an application perspective. And then the scrutiny was around substantial testing, right? If you think about pen testing, and then some code review. And that has not worked terribly well, or we wouldn’t have all of the breaches that we have. So we’re now in this, I think, phase of shifting left, as you hear people say, and I think the software development life cycle, and the SSDF are the next step in the evolution of shifting left. So for purpose of making sure we’re all on the same level, because I think APSEC is one of those places where some of the words and phrases might not be fully defined. Can you first explain what is an SDLC?
Elzar Camper (04:32):
Yeah. It’s interesting you say that, too, because if you Google SDLC, right, you get a couple different definitions, and one of them is obviously software. One of them is also systems. So I think sometimes people see SDLC, and depending on where you fall in the IT world, it could be systems or software. So I think that’s the most important thing to start with, that we’re talking about software, not systems, and they are different processes.
But the idea of an SDLC, software-wise, is basically just a methodology. Now whether it’s formal or informal, the concept is basically for designing, creating, and maintaining software. And how do you maintain the integrity of a piece of software is the most important thing. I think to your point earlier, when you talked about software eating the world, I think the goal definitely is to shift left. Right? But I think the demand for people to get their products out in the market, the demand of being first to market just makes this such a difficult process sometimes because people, historically, have seen security in the SDLC is slowing everything down. So the whole goal is how do we automate this and how do we really show security as a business enabler, a business driver versus a hindrance?
John Verry (05:37):
Yeah. I mean, in all forms of security, there’s always the balance between managing risk effectively with security and having some impact on the effectiveness and efficiency of operations.
Elzar Camper (05:49):
Yeah.
John Verry (05:50):
Right? You’re not going to have a control without it having some level of impact. So I think really, like you said, it’s a matter of finding that right balance. And I think you’re right. I think as we’ve gone to a more DevOps oriented world, the way that we can find that balance is by automating some of that security.
Elzar Camper (06:06):
Absolutely, because you said earlier, too, it’s a risk-based approach of making sure that whatever you’re putting in, the planning and implementation of any kind of security into the SDLC is really a risk-based approach. Not every application needs the same scrutiny. Now the high-level practices are always important. The high-level task of how you go about implementing security into the SDLC is important and can be consistent per organization, but you’ve just got to be careful to make sure that you’re not taking the same approach for every application that’s developed because every application has different means, different data. They interact with different kind of users. So I think it’s important to really take that risk-based approach to make sure that what you’re doing makes sense for the organization.
John Verry (06:50):
Yeah. That’s interesting because I think we tend to think about taking the risk-based approach on the backside. So as an example, the OWASP Application Security Verification Standard, right? We’ve got three discrete risk levels associated with that. I don’t think most people, including myself, a little bit less than I probably should, really think about making sure that the SDLC is appropriately tailored to the risk of that specific application. And I guess, and we’re going to talk about this, but I guess that we would probably determine that through some threat modeling, correct?
Elzar Camper (07:16):
Correct. Right. Threat modeling, understanding what kind of data is being processed, who the client is, all those things are so important, and making sure that what you’re asking from the developers and from the organization is realistic for the arena they play in.
John Verry (07:29):
So now we have, I think, a very clear definition of what we refer to as an SDLC and software, specifically. So what is the SSDF?
Elzar Camper (07:38):
So the SSDF on NIST 800-218, the secure software development framework, really it is four practices and 42 tasks. It tells an organization, outlines for them what they can do to improve the integrity of their software. It can be used by any sector, whether it’s going to be for the internet of things devices, whether it’s going to be for critical applications, web browsers, whatever it is, it’s something that there’s these different practices and tasks for things that can be integrated into any SDLC, and it allows you to set future targets. So if your organization, initially, you look at the four practices and the 42 tasks, and you say, “Okay, we’re able to achieve 20 of these in this year,” and then you start to roll into a different task as the majority of the SDLC progresses, it gives you a target.
So that’s the really nice thing about it. It doesn’t have building maturity levels into it, but it does reference other standards that do have building maturity models such as the BSIMM or whether it’s OWASP, SAMM, things like that. And I think from the last thing it really does is it allows another organization, so when they’re requiring software, they can have an independent framework to say, “Hey, where do you stand on the SSDF?” Now, I said before the SSDF references many, many other frameworks, which is a nice thing about it. But it does give that government standard that maybe one approach, high-level approach of things organizations can do to really give a third party or the government an understanding of how a piece of software was built.
John Verry (09:08):
Gotcha. And in terms of breaking it down a little bit more than that, can you maybe break down the standard a little bit, maybe at least at large group level and explain some of the things that it does cover?
Elzar Camper (09:19):
Yep. So four practices, right? So the first practice is prepare the organization. That has 13 general tasks. And this is things talking about documenting your security requirements, the policies, the procedures, the standards around, “What does your organization need to do to build secure software and maintain the integrity of the software?” It also gets into things of how do you communicate to third parties, whether it be your clients, whether it be the government, whether it be a subcontractor who’s developing a module for the piece of software, things like that. It really gets into the SDLC roles and responsibilities, which is nice. So it’s actually mapped to the NIST 801-181, I believe, document, the NICE framework, right?
And the nice thing about it, it actually identifies different task associated with different parts of the standard. So if we’re talking about this instance of prepare the organization and you have a software developer, or you have a security analyst, something like that, it actually tells you the actual task that individual is going to need to do as part of their job to help the organization meet that practice, for example.
It also talks about executive support. So like any good standard, if you’re talking like, for example, ISO right? 27001, that having that executive support to make sure that the standard is going to be actually adopted internally, operationalized, and actually be implemented across the board, which is great. And then it gets into things like securing endpoints, developer machines, EDRs. Do you have an EDR? Do you have an XDR? Things like that. And that’s high level, like the first one, right? How do you prepare your organization to get ready to adopt this standard? And there’s three other practices, too. So we can get in those if you want.
John Verry (10:58):
Gotcha. Yeah. I would like that. So prepare the organization is that understand where we are and where we’re going.
Elzar Camper (11:05):
Yeah. Yes.
John Verry (11:06):
Which is fundamental, I think. And I really do-
Elzar Camper (11:08):
I thought you might’ve. Yeah.
John Verry (11:10):
Yeah, exactly.
Elzar Camper (11:11):
Everybody’s favorite. Everybody’s favorite.
John Verry (11:12):
If it isn’t documented, it doesn’t exist from an auditor’s perspective, right? And I do like the fact that you emphasize the importance of governance and of management’s commitment. And if you’re listening to this podcast and you’re somebody who is responsible, at a CXO level, for an organization that develops software, at the end of the day, if you don’t have tone at the top, you are not going to have secure software design, which is what we’re trying to get to. So I’m glad you actually stressed that.
Elzar Camper (11:37):
That’s extremely important because you know how it is, right? You can have all the policies and procedures and changes you want, but if no one thinks it’s important and no one’s pushing it, it’s not going to go anywhere. It’s like, “Oh, put that on the shelf. That’s for the auditors, but this is how we do it.” So you don’t want that to happen. You want to merge those two, obviously, and have an effective program at the end of the day.
John Verry (11:56):
Gotcha. And so you said there were four main-
Elzar Camper (11:59):
There’s three others.
John Verry (11:59):
… domains?
Elzar Camper (12:00):
Yeah.
John Verry (12:00):
So what’s two?
Elzar Camper (12:00):
Practices, right. So number two is going to be protect the software. And this is really, you really get into the focus of the integrity of the software. How is the software being built? Where is the software being stored or using code repository? What kind of access people have to that repository? How are you doing hashes for released files? How is the software being checked out? And this is when it gets into one of the bigger terms that people like to talk about, is the SBOM, right? The software bill of materials. Is that available for the piece of software? And then is it not only available, is it updated every time the software is released?
Because an SBOM is great. It gives you a really good understanding of the different third-party libraries that might be associated with that piece of software, all the different open source technologies that have been incorporated into the application, and you need to understand what versions are they? Are they vulnerable? And if so, how do you identify them proactively? And that’s where the SBOM comes into play. Biggest thing, though, is you can’t just be a one time snapshot of every time you do a new release, you need that updated SBOM to show, “Okay, we know it’s in this version, we know it’s in this version.” So any organization that can look and see, “Okay, I’m running version 14.7,” it’s very clear of what third-party libraries are actually included in that version.
John Verry (13:14):
So would it be wrong to think of an SBOM as the ingredients label on the food packaging that I just bought?
Elzar Camper (13:23):
I think that’s a very good way to think about it. Yeah.
John Verry (13:23):
Okay.
Elzar Camper (13:27):
Without [inaudible 00:13:27], yeah.
John Verry (13:28):
Right. And then I think the only difference maybe with an SBOM is that on a food label, I might see food coloring, yellow number three. And I might recognize that might have negative impact to me as a consumer, and the SBOM, the idea behind that is that if we’re using third-party libraries, if those libraries have some known flaw, some known vulnerability, that should advertise that to me in the same way that seeing artificial colorings and flavorings that I don’t want to eat in my food. I wouldn’t want to have these bad libraries, if you will, in my software food.
Elzar Camper (14:05):
It should. And the interesting thing is how detailed is an SBOM, right? And internally, you run an SBOM, it should do exactly what you just said. Right? It should tell you what vulnerabilities are associated with certain libraries and certain pieces of software. The question is, if people start producing these and they’re making them readily available, at what level do you filter that information? Do you filter it to the individual buying the software? Do you make it available on your website? It’s obviously going to be very sensitive. So there’s things you’re not going to want to disclose, but definitely, I mean, that’s the idea of it, but an SBOM is only going to be as effective as the piece of software that’s also identifying the particular vulnerabilities within those third parties, right?
So you can generate one that says, “This is what we have in it.” But then it’s on the purchaser to scrutinize every piece, every DLL, whatever is in there. That’s just not sustainable. So it has to be more of a proactive response to, “Okay, we generate an SBOM, and then whether it’s greens and reds or something like that to show the internal staff of, “Hey, okay, we should really update these or remove ones, if we can, that are vulnerable.” But you really need the context of, “Okay, not only do we know what’s in it, we know it’s vulnerable,” and that process is automated.
John Verry (15:16):
So you brought up something that I had, and this is why I love chatting with people is that I think of things that I didn’t think of. And I didn’t really think about that idea, much the same way that we’ve worked with a bakery that had sold 20 million dollars’ worth of a certain product through a very famous store. And they had the highest level of security I’ve ever seen to keep the ingredients in this baked item secret. To some extent, do orgs want to keep the ingredients in their application secret? And then how do we balance that disclosure versus their right to having … That list might be some level of intellectual property, from their perspective.
Elzar Camper (15:57):
I mean, it’s a great point. And to be honest, I don’t know. I mean, where’s the line, and then who gets to draw the line? When you’re dealing with the government, they’re going to draw the line. If you’re going to want to sell software to the government, they’re going to tell you exactly what they’re going to want from you. Now, whether that’s a very detailed SBOM or just a, “Hey, we have one, if you want to see it,” I expect it to be somewhere in between that.
The interesting thing to your point, though, if you’re selling another piece of software or piece of software to another organization, do they really have … I mean, how much can they ask about? Where is that line of, “This is all the ingredients to our secret sauce, right? And I haven’t thought about that, but it’s a really good point of how much do you turn over? And then what is it if most of your application is open source versus what you’ve actually written? And then does that change what they’re going to view as being your product versus [inaudible 00:16:50]?
John Verry (16:50):
And even the value of the product. Yeah.
Elzar Camper (16:50):
Exactly. Right.
John Verry (16:53):
“Hey, wow. You’re charging us 100 grand.” I mean, basically, you just glued together a bunch of libraries. What would prevent us from doing that?
Elzar Camper (16:58):
Exactly. Right. So it’s interesting. I don’t know. I don’t know what’s going to happen, but I guess we’ll find out. So I’m curious to see how that works out.
John Verry (17:07):
Yeah. There’s one other thing that you also made me think about that I hadn’t thought about is that there’s the one side of I’m getting the SBOM and you’re confirming to me that you don’t have vulnerabilities in the libraries that you’re using, but the other side value of having me having an SBOM about what’s in your software is like when we had the OpenSSL problem. How many products were using that OpenSSL? And that gives me the ability to proactively take action because I could then, at that point, maintain a database of all the critical apps that I have exposed. Then if a vuln gets published, I can say, “Do any of the applications that we use, use this in their library? And if so, how do I throw a web application firewall up, or how do I take down that application to them, or how do I get in touch with the vendor to ask them if they’ve got a patch and get that patch deployed as quickly as possible?”
Elzar Camper (17:52):
No, absolutely. That’s the point, right? But I think, too, what happens when you come across these libraries that can’t be quickly fixed or OWASP is not going to work for? I’m never going to say ignorance is bliss, but there are times when you might then point out so many different … The amount of information that comes out on a daily basis around anything information security is hard to digest, right, when it comes out to different vulnerabilities, critical flaws, everything that comes out. And I agree with you 1,000 percent that you definitely want to know when something that you’re hosting has a vulnerable piece of software.
But I guess the question is, if that’s known to the public, if that’s a vulnerable … There’s a critical piece of this one module, this one DLL, whatever it is, is vulnerable, and that SBOM is known to the public, does that increase the attacks that are gong to take place? So good and bad that comes with it. You definitely want to know, it’s definitely a big benefit if you can do something about it. But also, if you can’t do anything about it, it does increase your attack surface.
John Verry (18:57):
Yeah. And I agree with you. I don’t think that it’ll be general practice to take an SBOM and post it on the internet, on your website-
Elzar Camper (19:04):
Right. Right. You would hope.
John Verry (19:05):
… for that reason, right?
Elzar Camper (19:06):
Right.
John Verry (19:06):
I mean, and even if there’s a zero day out there that you don’t know about, but some bad guy does, he can then go around and say, “Okay. Hey, I don’t have to look for the software that might be vulnerable to this. These guys were nice enough to publish it for me.”
Elzar Camper (19:19):
Right.
John Verry (19:19):
All right, so we beat up, “Practice to protect the software.”
Elzar Camper (19:23):
Yes.
John Verry (19:23):
What’s practice three?
Elzar Camper (19:24):
Practice three is going to be produced well-secured software. So this has 16 tasks. This is where we get into things we talked about earlier, of risk modeling, threat modeling. How do you track risk? How risk affects your design decisions? Are you using a standard? So for example, this is not reinventing the wheel, and this is where third-party software comes in even more. So the idea of using standardized security services or standardized services that have already been developed, log management or identity management, whatever it is. Don’t reinvent the wheel. Us what’s out there. It’s also been vetted and has enough eyes on it on a regular basis. And just maintaining well-secured libraries and modules.
They also talk about a little bit here about obtaining SBOMs from different components of the software that goes into your software. So the idea, too, is how far down do you go? For example, if you have a product that you get an SBOM for and they have sub vendors or et cetera, I mean, how many SBOMs are going to be generated? Is it just for the main piece of software? So it should be interesting to see how that plays out. It also gets into things like, “Are you following secure coding practices? Are you doing code reviews, static versus dynamic?” All the different things that your organization should be doing.
They talk a little bit about automation as well, which is nice. So they’re really trying to push people towards the idea of you can have a person doing it, which is fine for some organizations, or if you can, when you can, try to automate as much as possible because you want to make sure that you’re not slowing down the process, you’re speeding it up, but you’re also speeding it up while you’re ensuring the integrity of the software.
John Verry (20:57):
Yeah. And for some organizations, the idea of doing things manually, and if they’re releasing daily or bi-daily, is no longer practical in the world of DevOps, right?
Elzar Camper (21:07):
Yeah.
John Verry (21:08):
Exactly. And that’s actually interesting that they do the idea of, “Don’t reinvent wheels,” which I think is important. You see people come up with proprietary encryption algorithms, and you’re just like, “Why?”
Elzar Camper (21:21):
Yeah. Why? And when that person leaves, who developed it, they’re like, “Okay. Well, then what?”
John Verry (21:25):
Right, right. Yeah, exactly. Okay. So what’s the fourth practice?
Elzar Camper (21:29):
The fourth practice is going to be responding to vulnerabilities, and this really comes down to, talked about it for a second there, of monitoring the vulnerability databases, threat intelligence, hopefully to be able to automate it somehow, if you can, tie your SBOM to that would be even better. Right? If you’re able to say, “Hey, these are the pieces of my software,” and then tying threat intel to that, it’s great. Right? It’s the ideal scenario. It also gets into things of vulnerability disclosures. What’s your policies against disclosing vulnerabilities and software that’s out there in the wild to your customers and remediation policies, things like that? How do you track vulnerabilities, and then how do you calculate the risk? Are you using a standard risk model, and then what’s the plan to respond to all those things?
So it’s not just tracking and saying, “Okay, we do track it,” but okay, what are you going to do to respond to it? How are you going to handle inquiries from your customers? How are you going to handle releases, things like that? And then are you doing things like root cause analysis? Are you not just identifying the vulnerabilities and fixing them, but are you looking at what went wrong somewhere in the SDLC, somewhere in your process, standards, or procedures to say, “Okay, we had another cross site scripting vulnerability. Okay. This is the third one we’ve had this year. Is it a training issue? Do we need better coding practices? What is really the problem and why does this continue to happen?”
And then that’s the last thing, of continuously reviewing and updating your SDLC to make sure that you’re not just spinning your wheels. It’s great to shift left, but if you’re not shifting left and then being proactive when you do find problems, going back to the root calls and trying to address it, whether training issues or whatever, is making sure that you’re moving forward within your maturity levels within your organization.
John Verry (23:12):
Gotcha. So the SSDF, see if I get this right, the SSDF is a tool that we can use to either assess and/or help us build and optimize our software development life cycle methodology so that the likelihood that it produces a more secure piece of software, at the end on a consistent basis, is really what’s what it’s intended to do.
Elzar Camper (23:38):
Absolutely. I mean, that’s a very, very fair summary.
John Verry (23:42):
Okay, cool. So if that is right, what drove the US government to issue the SSDF?
Elzar Camper (23:48):
So it started in, I think it was May of 2021, executive order, section four. Section four, I believe it’s enhancing software supply chain security. And basically, the government was trying to find ways to how do they make sure that they’re buying secure software? And it’s all about the integrity of the supply chain, and their real priority during the executive order was on critical software, of “How do we make sure that when the US government buys critical software, that this is secure, this is things that should be in our environments, et cetera.
So the first question I think a lot of people had was, “Okay. Well, what’s critical software mean? What’s defined as critical software.” I mean, that’s different to different people, right? And NIST was nice enough to give us 11 categories of critical software because they’re very forward leaning, and I love the work that NIST does, and they really focused on the idea of it should focus on standalone and on-premises software first. And then it listed the 11 categories. And some of the categories, some things that they mentioned were things like identity and access management, especially within the cloud. Those are things where everybody’s concerned about, operating systems, hypervisors, also two containers, Dockers, Kubernetes, the world, things like that.
Talked a little bit about web browsers. So traditional web browsers, Chrome, Firefox, et cetera. They talked about endpoint solutions, so EDRs, XDRs, making sure that if that’s installed on the local workstation, that that’s also looked at. They talked about things like network controls, VPN software, DNS resolvers, things like that. They got into more of network protocols, so firewalls, intrusion detection systems, IPSs, application firewalls were mentioned in there. And then talked about things like SIMs. So more of operational monitoring tools, log correlation engines, things like that, remote scanning.
So if you’re going to have [inaudible 00:25:47], something like that, or an OpenVAS, or you can name what your favorite vulnerability scanning tool is, things like that, that’s all identified as critical software. And then they close it out talking about remote access and backup and recovery and remote storage pieces of software. So the basics, the normal ecosystem of an organization, the big pieces of it, things that can touch process, critical data, things that might give somebody elevated privileges or access are really how they define critical software.
John Verry (26:19):
Interesting. So I’m assuming that you could probably trace that to things like SolarWinds and the OpenSSL issue that we talked about prior because I’m surprised, and I haven’t read that NIST guidance specifically, so you just educated me. I’m surprised that there was no mention at all of SaaS. I mean, what you really just made mention of is a lot of the critical infrastructure, security infrastructure within an organization, making sure that the tools that we rely on to be secure are actually secure themselves.
Elzar Camper (26:49):
Yeah. I think maybe the SaaS stuff was maybe because of FedRAMP. Maybe they thought that there was more because they’re talking about on-premises versus, obviously, cloud, and they were focusing on on-premises software as critical software. My guess is maybe because they thought FedRAMP maybe is proactively addressing some of the SaaS type of stuff, so maybe they’re like, “Okay, maybe we can do that second.” But that’s a guess maybe.
John Verry (27:13):
Yeah. So I think the list you just gave us is those organizations that we know the government will explicitly say, “We expect this stuff to have gone through SSDF.”
Elzar Camper (27:13):
Yeah.
John Verry (27:26):
So for folks that are listening, how would an organization that it doesn’t explicitly apply to benefit from the SSDF?
Elzar Camper (27:35):
So I think the best thing to think is it’s going to raise the bar because I think you might start to see things like SSDF or used as a marketing thing of like, “Hey, we align to this.” So when I think of organizations that if we’re talking about organizations starting to the government right now, or will be in the future, that don’t fall into this category, they eventually will. So I don’t want to make it sound like they’re talking about starting with critical security or critical software, but the goal is to have this to any piece of software the government procures, and this isn’t like CMMC when it’s just the [inaudible 00:28:10]. This is government wide, federal government wide.
So if you’re producing software, whether it’s either incorporated into a larger application or something you’re selling direct to the government, it’s something that they should be aware of. It also allows them to start now proactively identifying, “Okay, this is the way that we’re going. The whole concept of shifting left is being pushed out by the government. It’s going to be adopted by the private sector more and more, and it’s something that organizations need to do to stay competitive, I think, as it comes to not just first to market, but also having a secure product that’s first to market, I think is going to hopefully become more the norm in the future.
John Verry (28:48):
Yeah. Interestingly, we have a client that we work with that produces, I’ll loosely call it a healthcare device, and they are being asked about the SSDF and about an SBOM already. So they’re not in the government food chain. This isn’t a governmental entity. It’s a healthcare entity that’s asking them this. So I do think that there’s a general recognition of the potential import of this, that I think if you are producing software or you’re producing a device that has software on it, you probably should be cognizant of.
And I think there’s one other way that you might benefit from this. If you are consuming software, one of the best ways to gain some level of assurance and some level of knowledge about how mature their practices are is to ask them about their SDLC, to ask them if they are SSDF compliant, to ask them if they can produce an SBOM. So your third-party risk management practices, I would suggest, and we’re recommending to our clients already, that they add these types of issues into their third-party risk management processes.
Elzar Camper (29:54):
Yeah. And I think it’s like everything else, right? The executive order also talked a lot about Zero Trust. Now, Zero Trust has been out before, right? It’s been out for a long time, the concept of it in the private sector. But until it came back into the executive order, now everybody’s talking about Zero Trust again. So it’s one of those things that the government is like an amplifier, I think, for a lot of these things, that they’re not always in front, but when they get there and they start to talk about things, it tends to bring more attention to it. And then you start to see it roll in the contract, start to see it roll into, like you’re saying, TPRN programs or things like that people are asking more questions around that concept because it’s getting more publicity. So no, I definitely agree with you there.
John Verry (30:36):
All right. Do we have a schedule yet, if you will?
Elzar Camper (30:39):
Yeah, yeah.
John Verry (30:40):
When do we think SSDF goes into effect?
Elzar Camper (30:42):
Yes. Good question, right? So interesting enough, we’ve got to think, right? So SSDF was actually finalized this year, in 2022, February by NIST. A month later, NIST, or OMB, actually, required federal agencies to adopt the SSDF and said that they need to start implementing it into their risk profiles and how they’re going to implement it within their mission, things like that. Right? And then a day later, so this all happened in March of 2022, so it was the 7th of March. The 8th of March, another announcement came out from OMB saying it’s going to work with the private sector over the next 60 days, which puts us about a week or so ago, to talk about how companies have to comply with it, so the attestation requirements for an organization.
So everybody right now is just waiting for OMB to really be clear of how companies and when have to really attest to it, right? So obviously, first party or third party or something in between, right? So I think the best guess is people think by the end of the year it’s going to be maybe requiring some of the bigger contracts, or it might come out saying, “Okay, by this time you need to be.” But then, by next year, it’s probably going to be rolling into a lot of different contracts of critical software, probably, and obviously then work its way down the road.
But I would think what you’re going to see is probably a similar push to what you saw for CMMC, is you might have the big companies, the Primes that are like, “Okay, we’re going to start moving a little bit quicker than the smaller companies,” and then they’re going to probably start putting a little more pressure on the subcontractors to be like, “Hey, you need to start aligning your programs if you’re developing software on our behalf with the SSDF.” So I think you might start seeing, probably toward the end of the year, a lot more of that type of activity.
John Verry (32:27):
And this is a hard question to … I know SSDF is new, so if somebody is sitting here listening to this, going, “Oh crap, this is going to apply to me,” and they’re like, “Eh, I don’t think our development processes are where they need to be,” how long will it take to go through the process of assessing where they are and then putting the right mechanisms in place to get to a point that they can either self attest, or if there is a third-party attestation to it? I mean, is it going to take them a week? Is it going to take them a month? Is it going to take them a year?
Elzar Camper (32:58):
So the quicker part is going to be the gap assessment, right? So that’s a couple weeks, right? So if you’re coming to organization, if you’re looking at, “Okay, this is our program. Here are our policies or our standards. Here are the people who develop it. You can talk to them.” Traditional gap assessment, like you’re going to do with any other framework, I think the tough part is making sure the scope is correct and the boundaries are set up correctly of the actual attestation of, “Okay, do we understand if the applications we’re talking about or the development units we’re talking about are actually the ones that fall into critical software or need to meet the standard of SSDF?
So I think the first conversation you have to have is that important scoping and boundary conversation and the understanding of, “Okay, what is the application doing? What kind of data does it host? Who are you selling it to, or who else is using it?” So I think that’s extremely important. I mean, it’s tough because every organization is different when you come in. Organizations already have SDLCs that may be aligned with OWASP or BSIMM or something like that It’s just going to be a mapping exercise and identifying some of the differences, maybe in the language.
But I’d say a few weeks to start out from the gap assessment, the heavy life is going to be in the remediation. So it’s one thing to identify the problem and scope it. It’s a whole nother issue to say, “Okay, we see where you are, maturity wise.” And the question is, if they’re starting from nothing, how do you change all their processes and standards and then train that to the people who are actually developing the software? And that’s when you come into … You’re looking at months, right? Because you’re talking about retraining staff of how to do something. You might be changing the way that their pipeline works. You might be adding additional training requirements to the organization, might be saying, “Hey, you don’t have this role. You need this feature, this functionality built into this system.” And then you have to follow it, you have to operationalize it before you can really attest that it’s actually working. So I think that could take months.
John Verry (35:01):
Yeah. And actually, and you didn’t cover a couple of things that could make the months go to many months. Do they need budget?
Elzar Camper (35:07):
Oh, absolutely.
John Verry (35:08):
Right? So if you think about if they need a … Let’s say they’re working in a particular language, there may be only one or two automated code scanners that really will be effective for them. And you can spend six figures or 50,000 bucks on a code scanner.
Elzar Camper (35:22):
Yeah.
John Verry (35:22):
Right? So if you don’t have that money budgeted, you might have to wait a year to get that budgeted. The second thing is, do you have the right people on your team to be able to do the work? So it might not just be a training. You might need more people, or you might need a different type of person. And right now we know that there’s a tremendous shortage of the kind of people that you’d want, the more that’s security oriented DevOps or sec DevOps oriented kind of people.
Elzar Camper (35:43):
Yeah.
John Verry (35:43):
You might be able to get by with someone more quality oriented or somebody more in that space, but maybe not. So that might be another thing. You might not be able to find the right people to be able to actually affect these changes in your environment.
Elzar Camper (35:55):
No, absolutely. I mean, we both know better than most that attracting, retaining, and being able to grow that talent in any organization is tough. And the application security engineers and that level of individual is extremely hard to attract and retain. So for the larger companies, they’re going to be fine. They have larger budgets. I’m not saying that it’s not going to impact possibly their bottom line, but normally bigger companies are able to deal and absorb these things more proactively and easier.
Where I think the challenges are really going to present, and I think where they’re presented for things like CMMC is the SMBs. How does a small to medium-size business take something like an SSDF when they might have a very informal methodology for the SDLC and put this formality around it? Now, the nice thing is the SSDF doesn’t tell you how to do everything. It’s practices and its tasks, and it’s really outcome focused. So if you take the risk-based approach of saying, “This is why we do it this way, or this is why this works this way,” I mean, it doesn’t have to be prescriptive to every possible reference control within the SSDF. And that’s the nice part about it. It can be customized to the environment based on risk.
John Verry (37:11):
You mentioned OWASP, SAMM, you mentioned BSIMM. If I asked you just generally, how would you compare the SSDF to those documents? I mean, is it an analog? How would you compare them?
Elzar Camper (37:26):
So the OWASP, SAMM, and SAMM being security assurance maturity model and BSIMM being building security in maturity model are both secure development frameworks, for lack of a better word, maturity models. Better word to use. So basically they’re mapped to the SSDF. They’re mapped to the different tasks that are underneath the different practices. And it’s different in a sense of the things like OWASP, SAMM, and BSIMM are much more prescriptive of saying exactly what to do. The nice thing about the SSDF is it’s mapped to all of these things. So the SSDF is a high-level framework of things you should do. This is the concept, this is the practice, this is the task. But then the references is really where the strength of the SSDF comes into play.
Things like OWASP, SAMM, things like BSIMM. It’s also map two. I think it’s like 800-160, 161 systems engineering, and then the supply chain risk management stuff. And that’s where the prescriptive type of text comes in of, “Okay, this is the general concept from the practice and the task level, but this is how you would achieve that.” And that’s really the power of it. The SSDF is just a framework. It’s just saying, “Hey, this is what we’re trying to hope.” This is a negative notional examples, which shouldn’t be taken verbatim, but they give notional examples of what that could actually look like. So the nice thing about it, it’s mapped to all those different frameworks of different standards, which get into more of the weeds. They actually have maturity models in them built into them as well, which is really nice.
So an organization might be at maturity level one for OWASP, SAMM, or BSIMM, but it meets the overall objective of the practice of the task. And then you can actually look at it and say, “Okay, I meet the bare minimum and I’m at maturity level one,” and you can actually work your way up to give yourselves a roadmap to, “Okay, I get it. I meet the bare minimum, but how do I now increase the efficiency of my program?” which is pretty nice.
John Verry (39:26):
Gotcha. So simply speaking, the SSDF is the what and why, and then it gives you references to things like OWASP and BSIMM for potential ways how. So it’s a non-prescriptive framework.
Elzar Camper (39:39):
Yes.
John Verry (39:39):
The SSDF. Okay, cool. All right, we beat this up pretty good. Is there anything we missed?
Elzar Camper (39:46):
I think we hit a lot of it. I think the one thing I really like about it is the fact that the advantage is right. It’s broadly applicable. It provides organizations a roadmap, and the fact that it is mapped to well-known standards tells me that they understand that, “Hey, listen, this is definitely a framework. If you really want to get into the weeds and find what’s relevant to your organization, this is where to go.” So the nice thing about it is organizations that have a mature SDLC, they’re not going to have to reinvent the wheel. They’re not going to have to change anything. It’s just basically a mapping exercise. So I think that’s really nice.
I think anytime a new standard comes out, I always hold my breath for a second because you’re really going to be worried about, “Are we making this overly complicated? Are we going to make organizations now have to jump through additional hoops that are going to increase costs and things like that?” And while the SSDF is going to make organizations do mapping exercises or do the gap assessments, things like that, I think it’s well intentioned and I think it has to happen. The idea shifting left has to happen from a standpoint of information security. Proactively trying to get in front of vulnerabilities within software is extremely important. And I don’t see how else, outside of doing this and really getting to the point of, “Are we building secure software?” of how you start to reduce the backend cost of penetration testing and vulnerability assessments. All these things that are still important, but really that’s not where the investments should really be. You need to start shifting left and invest in building quality code from the beginning.
John Verry (41:14):
Right. So SSDF, well done. We’re secured by design. We’re not relying on secure by good fortune.
Elzar Camper (41:23):
Right, exactly. Right. Yeah. Which a pen test can lead you to believe sometimes.
John Verry (41:28):
Absolutely. Substantiated testing is not the way to know that you have a secure application.
Elzar Camper (41:33):
Yeah. I did want to bring up one more thing that I forgot to mention about the attestations. So NIST did put some stuff out there when they were recommending … They did recommend that the government start with first-party attestations and then take a risk-based approach to having third-party attestations. And they actually recommended against providing low-level artifacts as part of the process. I think the idea was the government doesn’t have the expertise to review a bunch of very complicated and well detailed SBOMS and a bunch of other artifacts that will slow down the procurement process. So they’re focusing really on requesting high-level artifacts. And I think that’s probably going to be how this starts off. So it’d be interesting to see how OMB comes out with their guidance and what they’re requesting.
John Verry (42:21):
Yeah. And for anyone that’s thinking to themselves, “Well, that’s great. I can just send a letter that says I’m secure,” I will say this is, I think the government is getting smarter about how to hold people’s feet to the fire. With CMMC, of course, we’ve got some level of assessment, but even just the requirement for a senior authorizing official to sign off on a document with the threat of, and then ramping up the Department of Justice with the Civil Cyber Fraud-
Elzar Camper (42:51):
Yeah, False Claims Act.
John Verry (42:52):
Yeah. I mean, they recovered 20 billion plus dollars in 2020. I don’t know what 2021 brought. But yeah. I mean, if they do what they did with Sarbanes–Oxley, and they do what they’re doing with some instances of CMMC, and it requires a senior official to sign off at that risk, I think people are going to probably take it pretty serious.
Elzar Camper (43:12):
Absolutely. I think the last thing anybody wants is to fall into that crowd of, “Okay, we said we did it. Here’s our piece of paper.” But it’s the SPRS score of everybody has 110, right? Well, do you? So when you start to ask those questions and you start to dig into it a little bit, and if you have the whistleblower programs that a lot of these things are coming from, the False Claims Act is not something anybody wants to be associated with.
John Verry (43:36):
Yeah. I agree with you there.
Elzar Camper (43:38):
Yeah.
John Verry (43:38):
So give me a fictional character or a real-world person you think would make an amazing or horrible CISO and why.
Elzar Camper (43:45):
I was thinking about this. I think an amazing CISO, I think it would have to be comedian, and it doesn’t matter who it is because-
John Verry (43:55):
No, you have to give me a name. You have to give me a name.
Elzar Camper (43:57):
Yeah. I would go with old school Rodney Dangerfield or somebody like that. Like doesn’t get any respect. Maybe something like that. CISOs are getting a lot more respect, so I’m not saying they’re not. But I think you need the personality of, with the amount of changes and the amount of standards and frameworks and the workload, you have an ability to laugh about it or it’s hard to keep your sanity in the word of InfoSec.
John Verry (44:19):
Yeah. And I think that’s one of the reasons why you always hear me say it’s serious work that we don’t do seriously sometimes because if you don’t laugh, you cry. Right? I mean, it’s as simple as that.
Elzar Camper (44:30):
Well, I came to the world of law enforcement, being a criminal investigator, and it’s the same thing of you’re dealing with sometimes very serious topics, and sometimes you’ll see people smiling and giggling because if you don’t laugh, you cry sometimes. And it’s one of those things that you’ve got to find the humor in a lot of things.
John Verry (44:44):
Yeah. And if you think about it, I mean, the best funerals I’ve been to are a bunch of people sitting around laughing and celebrating someone’s life.
Elzar Camper (44:52):
Yeah, absolutely.
John Verry (44:54):
For that same reason. All right. This was awesome. If folks wanted to get in contact with you, what’s the easiest way?
Elzar Camper (45:00):
Email address, [email protected] or go to Pivot Point Security website, reach out, say hello. Be happy to talk.
John Verry (45:09):
Sounds good, man. Well, thank you for coming on. I appreciate it.
Elzar Camper (45:12):
Yeah. Thanks for having me.
Speaker 1 (45:13):
You’ve been listening to The Virtual CISO Podcast. As you’ve 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 at [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.
