110. The DevSecOps Playbook with Paul McCarty - Part 2
Paul McCarty is a DevSecOps evangelist, and his recent chat with Claire was so great, we had to split it into 2 parts. In part 2 they discuss minimum viable security product, the Software Bill Of Materials (SBOMs) and making governance material consumable for senior audiences, no matter how unsexy policies might be.
Paul is the founder of SecureStack, the world's first DevSecOps Maturity Platform. Paul has been helping organisations build more secure applications for almost 30 years. He’s worked for large organisations like NASA, Boeing, Blue Cross/Blue Shield, John Deere, the US military, but he’s also worked with several startups going back to the mid nineties. Paul is a frequent contributor to open source and Linux projects and is a co-organiser of several community group meetups here in Australia.
Links:
The Security Collective podcast is proudly brought to you in partnership with LastPass, the leading password manager.
Transcript
CP: Hello, I'm Claire Pales, and welcome to The Security Collective podcast. This week, we're bringing you part two of my chat with Paul McCarty. In this episode, Paul and I discuss minimum viable security product, the software bill of materials and making governance material consumable for senior audiences, no matter how unsexy policies might be. If you haven't listened to part one, head back there first and take a listen. If you have heard part one, and you're ready for part two, here's Paul McCarty starting where we left you last week.
CP: I mentioned a term before minimum viable security. Tell me about your involvement in that product that's being developed at the moment? And how does it work to support businesses, because I know you can apply these principles to any size of organisation. So MVSP.
PMc: Minimal viable secure product, the web address is mvsp.dev. MVSP was built to be basically a baseline checklist of what you would expect. The way I like to think about a Claire is like what would I or you expect a company that we're going to buy a product from or consume the product, what we expect would be the baseline of the things that they have. So it includes things like logging, and patching and, you know, using source code management and a bunch of these really kind of basic constructs. It's a checklist. It's ultimately an open source repository. But it's a checklist of things that you can use to do self assessments for vendor assessments. It's backed by some heavyweights it's backed by Google, Slack, Asana, Salesforce and a bunch of other organisations, including Secure Stack, we're really excited to be part of the kind of governing group of organisations involved. But yeah, that's ultimately what it is. It's a baseline with which you would expect somebody you can buy something from is going to adhere to.
CP: And this is a value, I guess, in third party risk assessments or third party assurance, is it also something that you can use around things like M&A, when you're not just buying a product from someone, but you're actually looking at buying a whole business?
PMc: For sure. Basically, it can be used in any scenario where two organisations are looking to operate together, whether that's M&A, or whether that's a partnership. And it's meant to be like, bi directional too like, hey, here's our MVSP, show me yours and I'll show you mine kind of thing. It's built to be just prescriptive enough where you can say, we do that or we don't do that, right? Because it's supposed to be a really simple baseline, a way for anybody to look at the way it describes things and say, yeah, we do that, or yeah, no, we don't do that.
CP: Which I think some organisations have tried to use ISO and SOC2 and those types of standards in a similar way. Would you agree with that?
PMc: Yeah, they have. I think the problem is, and this kind of alludes to, like, why I wrote the DevSecOps playbook too as well, but the MVSP, you know, its focus is its ability to have this kind of bidirectional back and forth between vendors or partners about, we do the basic things that we need to do. Whereas especially ISO where it's talking about kind of the policies and procedures in the in the internal functions that, you know, hold security data and knowledge, it's really hard for an engineer, or a technical person to look at ISO 27,001, less than with 02, or SOC2 for that matter, and understand what to do with a lot of it right. Like, fortunately or otherwise, I've spent hundreds of hours mapping SOC2, ISO 27,001, ISM, and a bunch of other frameworks, NIST 800, SSD F and a bunch other stuff to the software development lifecycle functions. And you read things like, define and implement an SDLC process for application design, development, deployment and operation in accordance with security requirements defined by the organisation. You're like, how does an engineer do anything with that, right? And I understand why those things have to exist at the high level. But then when somebody, their employee or their software engineering team, something like that, they don't know what to do with it. That's the problem. And the MVSP tries to address that by specifically being this baseline way to say, is this company doing basic things that we would expect them to do? And the DevSecOps playbook has a different focus, which is a specific list of tasks that the different teams within the organisation can do to make DevSecOps happen. And I think that's ultimately what was the takeaway that I've gotten over the years of working with these compliance frameworks is that they have different audiences. And they have different perspectives. And we can't take something like an ISO 27,001 doc or SOC2 doc and give it to software engineers and expect them to do anything significant or material with it, right. And that's just the reality of it.
CP: Yeah, I mean, you've got to have documentation that's fit for purpose. And that, as you said, is actionable by the audience. So, if there's an opportunity with this minimum viable, secure product, to have people talking the same language, that's a really great outcome.
PMc: 100%. That's simple stuff, right? Because the working group is spread across the world and comes from different organisations in different roles. That's a really good representation of that kind of generalised basic checklist. I have mad respect for the MVSP, I just wish we updated it more often than once a year.
CP: Right. Okay, cause I was going to say to you, yeah, this is a moving feast. So how often does that get reviewed or do people contribute to it?
PMc: Yeah, we have working group meetings every quarter and the one we just had is an anticipation of the next set of updates. And that's great. When you have a large group of people in organisations being a part of a framework like that, you know, it needs to be thought out. Whereas something like the DevSecOps playbook, I want to be opposite. I want anybody in the world to fork that repository, make a change, if the rest of us think it's legit, I mean, that'll go in within 10 minutes, right. And that's happened before people have suggested things that I just missed. So yeah, just to your point earlier, it's just a different audience. And you know, it has a different outcome. DevSecOps playbook is all about specific tasks for engineers to do.
CP: So over the last, I guess, few episodes or few seasons of the podcast, we've been starting to talk a lot more about supply chain security. And I'm really interested to talk about it from a software development perspective and hear your view because we know that third party risk can come from many different places. Tell me your thoughts around supply chain security when it comes to the software development side of things.
PMc: It's moving so fast, right? And I know we all say that, but like, the reality is that different attacks and vectors have popped up in the last couple of months that none of us saw coming. Like these weird dependency confusion attacks, and the use of unicode characters inside of GitHub repositories and all these things. I mean, we just, we couldn't have seen that stuff coming. The organisations really need to jump in now quickly, because we're all surrounded constantly by software. It binds our society together, we're not getting away from it. And one of the things that you're hearing a lot of people talk about right now is a potential panacea is this idea of Software Bill of Materials, or SBOMs, as they're typically called. I don't think first and foremost they're a panacea. But I think they can be a real benefit to organisations because ultimately, what SBOMs what it's trying to do is trying to represent an application in all its glory, or anti glory, in all its true form for a customer or for a group of engineers, right. And that's ultimately what it is. So as part of that, an SBOM, you shouldn't be creating it once a year, right? This is something that should be highly iterative, should be every time there's a material change the application, you should create an SBOM. It gives the software engineering teams visibility, but also gives the C-suite executives and the managers and InfoSec teams visibility into the application space. They have to be contextually accurate, comprehensive, and stored somewhere, they can search them right. Like when Log4J happened in December, thousands and thousands of people hours were wasted, well not wasted or spent looking for Log4J in all the places it was and one of the things that SBOM can provide is the ability for InfoSec teams and software engineering teams to centrally store the SBOMs and then search across those in a way that gives the teams the ability say, oh, we've got this new vulnerability, let's go and find that component, every single application where that component is, which versions are in that application, and then that tells us what the scope of what we need to work on, right, and then you can start mitigating and working on it. In December of 2021, we spent thousands and thousands of people hours looking for it because we didn't know where and it was in was in source code. It was in web apps. It was in hardware devices that we had bought, right. It was everywhere. And I think organisations after that realised we need a better way to address the software supply chain and SBOMs. Again, they're not a panacea, but they're part of the solution for sure.
CP: You mentioned that having a Software Bill of Materials helps the C suite. A lot of C-suite people I deal with feel concerned or put off by anything that looks vaguely technical. Can you talk a little bit more about how using something like a Software Bill of Materials with the C-suite can lift their confidence?
PMc: Ultimately, most SBOM are represented as JSON or XML. Neither one of those formats was built for humans to look at, right? Unfortunately, I look at JSON all day long and you know, it's probably why my eyesight's so bad. But reality is that we're working with US government and DHS on a project that's all about taking SBOM data, and representing it in a way that's usable by non technical people. And what does that involve? That involves things like, understanding how many applications you have? And how many different components are in those applications at a high level, or an aggregate across all of your application states. Understanding what percentage of your applications vulnerabilities are vulnerable components within them. And also understanding how quickly your teams are actually addressing those, that time to remediation. These are things that C-suite executives can consume, and probably want to without being scared off by that technical data. And many SBOMs are thousands and thousands and thousands of lines. So you don't, human beings shouldn't be looking at that. And you shouldn't be bringing that into a platform where it's giving you value from all those SBOMs. And being able to see the drift across SBOMs where somebody on September 19, they added that component and that's when this vulnerability was introduced. Having that granularity, I think those are the kind of things that that appeal to both technical and non technical consumers of SBOM data.
CP: And I think it talks to the fact that in security, understanding what code you've got, what assets you've got, what information you've got, who's got access to it. Any ability you have to mine that data and understand your positioning allows you to reduce risk in your organisation, that makes complete sense. And as you said, I think the lessons were learned during Log4J and I really hope this Christmas isn't as disrupted as the last one. But it's resource heavy for organisations to go through something like that, when they don't have things documented. And they don't have the infrastructure to allow them to move quickly through an issue like that.
PMc: Yeah, and that's part of the problem, too, is just like, you can't snap your fingers and create a bunch of SBOMs across this massive estate of applications that most organisations have, there's a whole lifecycle to it, you know. It's about asset discovery, identifying what applications you've got, whether those are things you've written, you bought, you're consuming, are they SAS based product, where are they, and then collecting data from those applications, and then creating this SBOM, storing that SBOM somewhere centrally, and being able to search across all those SBOMs, there's a whole life cycle to it. And you know, it takes work. And that's why we need solutions that are addressing that space. To your point, we don't want another Log4J like December 2021, right? All those people that missed their Christmas and holiday vacations because they were doing it, it was a crappy time, it's always a crappy time. But we don't want that again.
CP: No, and there's nothing sexy about governance or documentation. But you know, it can definitely save people's skin. So yeah, I think it's a good message to give around, putting that documentation together. And to your point, even more so lifting it to a level where it's consumable, and meaningful to people. And it's not just well, we documented it, and it's over there in that repository.
PMc: And making sure that it's created automatically. Automation is, you know, we all talk about automation and the power it can bring but you know, SBOMs and this kind of data should be automated. And it can be automated, right. We don't want teams manually doing this, right. We want this automated, going into this central repository, and you can search it.
CP: We've talked to a lot today about the different areas of the security community that you're involved in. And you do give a lot of your time and which is extremely generous. I'm wondering what makes you want to give these contributions and you covered a little bit earlier in our conversation, but also how other people get involved? Because I know lots of people that want to give to these types of causes. Is it your network? How do you how do you allow time, but also get the opportunities to get involved in in things like the minimum viable secure product and those types of activities?
PMc: Yeah, I'm sure my wife would not be stoked on the amount of time that I put into these things. I go to a lot of meetups and things that I think a lot of founders maybe don't do. I'm for better or for worst. I'm a sociopathic doer. Right, like I just I have to do. And the reality is that a lot of these projects I'm working on whether it's DevSecOps Playbook, or the Essential 8 SDLC, or MVSP, these are things that I see as having real value for everybody, right? There's no real commercial interest in it. For me, it's more about seeing the value that it can provide, fixing a problem. I'm absolutely compulsive at fixing problems. And so that's why I get involved in all these things and why I'm involved in so many meetups and what have you. But I think also that the outcome is that you know, I've got a great network, you know, I've got the CyRise network and people like Susie and Adam at Cynch and all the other friends that I made from from CyRise and, and my friends from the meetups and organisations I'm a part of and AISA with cyber con. I'm just a sociopathic doer!
CP: But I also think that probably going down a rabbit hole, it's on a bit of a tangent but I also think having been an expat myself and you know clearly from your accent my audience can tell that you're not from around these parts. As an expat I think you seek opportunities where you have things in common with people and you know if security people are your people, but you happen to be on a continent well away from home, it's a really great way for you to integrate into the society here as well.
PMc: Yeah, and I mean, I think I've only been here since 2016. But I'm a proud Queenslander and Marlins are my team. But the reality is that I see this is home now, right? I see the opportunity here to build a network and in a kind of grassroots community, and you asked earlier about how people get can get involved, I would love people to take a look at the DevSecOps Playbook, the MVSP, and the Essential 8 for SDLC and some of the other projects I'm working on. We're also working in the background and mapping all those security frameworks. We've talked today to SDLC kind of concepts and stages and that's a massive piece of work. So we're kind of 80% of the way through NIST 800 right now. But the reality is that reach out to me or you can search for many of these things on GitHub, DevSecOps Playbook will take you right to our project there. And mvsp.dev is the URL for the minimal viable secure product. But here's something else I wanted to say too, as well. And don't feel like if you're not a software engineer, or you don't have 20 years of InfoSec experience so you can't be involved in these projects. I've never been paid as a software engineer. And yet here I am, an evangelist for DevSecOps. Don't let your perceived outsider status stop you getting involved. I can't stress that enough. We need these different viewpoints to come into these projects. And help us understand. And you know, when we're talking today about the Essential 8 for SDLC, that was a different perspective on something that people typically see in a very different way, right, but it has power. So I really encourage people to to get involved in projects, even if you don't think that you're a subject matter expert, get involved.
CP: I talked a long time ago on the podcast back in one of the earlier episodes, with actually a fellow American woman who talks about the fact that volunteering is one of the best ways to uplift your knowledge and your literacy in a topic, but also to grow your network and to get other jobs. And yeah, I think if people volunteer their time, you don't have to be an expert, but it can actually provide you with skills and experience that add to your professional development.
PMc: 100%. I totally agree.[CP1]
CP: I'm going put all the links that we talked about in the show notes. And if people want to access DevSecOps Playbook and the pieces on the MVSP as well, all of the links for that for the audience to gain access to. And Paul, thank you so much for being on the podcast today. I've really, really enjoyed our chat. And we'd love to have you back.
PMc: Yeah, thank you so much. Thanks for having me, and I appreciate it.