Securing Software Supply Chains – Mark Stamford, OccamSec

This is Textron TV. Hey guys. Thanks for the throw.

We're here with Mark Stanford. Who is CEO for Occam SEC and we're going to be talking about the impact the executive order from the Biden Administration is having on cybersecurity for better and For Worse Mark. Welcome to the show.

Hey Mike. Thanks for having me happy to be here today. Now the executive order applies to federal agencies, but do you think that enterprises are starting to look at the same issues outlined in the executive order and start in the move accordingly and are they gonna be in lockstep with federal agencies on this stuff or is it a little bit more hit and miss than that?

I suspect that's the Hope because I mean everyone is pretty much facing the same issues. Right? So the security issues that critical infrastructure faces at the same critical issues that everyone in the private sector faces.

So I think that there will be this this inclination to go in lockstep. although I suspect ultimately it won't work quite as to that degree. What do you perceive to be the actual problem at hand?

I mean we all agree conceptually at least that we should have more secure software Supply chains, but between the theory and the practice, what do you see as the issue that people are getting hung up on our trip. So, you know fundamentally, what's the challenge that needs to be dealt with? I mean having fundamentally it's it's really hard.

Right and this is a conversation I've had with cisos and CEOs and everyone across the board and Cyber, security is is just really difficult. Right? There are so many components that can be impacted.

I mean, even if you take like a really simple software program, there are multiple developers working on that. There's multiple code there's multiple inputs. And then as you just grow that out you end up with this more and more complicated issue and then you throw human beings into the mix with all the stuff they bring so you end up with weak passwords or badly rare in code and it's just it's just really complicated and I think there's a there's a tendency to try and simplify everything which is good if you stand it, but when it comes to actually sold in their problem, we have to sort of go away from simplification realize there's a lot going on here.

What's gonna give us the biggest bang for the buck what car we control and so on and we just seem to have a hard time doing that. It seems like some of the simpler things that people could focus on is they the attacks are targeting the credentials of developers and then they're just hacking in their system and going wherever they want. So, you know, it's great to have and maybe an immutable blockchain database to tracks every software component in the world, but maybe we just need to focus on some of the simple stuff early.

Is that kind of where we are? Yeah, I agree. Right?

I mean there's there's a concept really at work in that you know bad guys will always go off to the lowest hanging fruit, right? I'm gonna go the quickest way. I can to achieve a talking right?

And I mean, we do lots of penetration tests and lots of security assessment and as much as it's really good to find some really fantastic exploit. It gets me in Nobody seen before if I can just find a password online. It gets me in.

I'm going to go that route. So you're right. We should focus on those simple things right using Using strong passwords.

I mean as much as everyone debates passwords, they should go away passwords aren't going anywhere anytime soon. So let's stop debating about the merits of our passwords good and just focus on how do we make passwords secure right? And if you look at sort of the the common thought process around this is that your password should be, you know, 12 characters long a combination of Africa special practice.

That's complete waste of time. Right firstly people won't remember it. Secondly, it's really easy for computers to actually crack those passwords.

So instead just have people choose four random words that they can use as a password and go from there. Right? I'm patching is the other one, right?

The patches are released on a fairly regular schedule by all software vendors. So Microsoft doing every second Tuesday of the month, for instance, then Infamous past Tuesday apply those patches because those patches security halls, but then when you look up more complex environments patching even become problematic as well, so I think there are these simple things that we can do. But we still have to put them in context and work out are they really simple or not?

And I think the cloud has made this problem somewhat worse in a way because people have now started to develop this mindset that security is somebody else's problem. So I'm using AWS or zoo or any SAS solution. They're going to run my security for me.

So I don't have to do anything. Right which is completely wrong. And that's that's making that problem worse.

So we think we've made it simpler by pushing it to someone else. But we've just moved the risk somewhere else and the risk is actually got bigger. What is your sense of the actual threat to our software Supply chains?

Is it severe and I asked the question because a lot of this got traced back to the log4j Shell vulnerability, but I'm not sure I'm seeing a lot of exploits for that. But then again you might not see them. So exactly you know how vulnerable are these software Supply chains in reality versus the theory?

I think solar winds is the is the sort of gold standard. That's the right word all of a supply chain attack. Right?

So we have so much software. That's that's developed all over the place that's deployed over in place that nobody really knows what's going on. So, I think those Supply chains are extremely vulnerable and I think that the way this is developed in terms of like I'm Outsourcing my code to someone far away.

I'm Outsourcing my design to someone everything is out. Here's all those points potentially are easy to talk in and if you look at the way software is typically deployed into environments. There's no real security assessment that goes on in a lot of organizations.

So if I'm blind and you agent to put on my computer to you some security function even right no one's really looked at what's going on with that code and there are so many places along the way that code could be interdicted and messed with that. Yeah. Just we just don't know what's going on.

And that problem is only going to get worse because we're only going to Outsource more development. And a lot of that Outsourcing quote unquote takes the form of Open Source components that people are importing into their application from various directories. And you know Linux is one thing when there's thousands of people doing peer reviews, but log4j turned out there was a handful of people working on that.

I didn't really have a lot of time for the security aspect of this thing. So do we need some sort of raining system or assessment capability of these modules that people are using to say, hey the level of security in this thing is this, you know, behave accordingly. Yeah, I think that's a good idea.

I mean there's the concept of s form right the software below materials that's starting to fly around now, I think having a way to assess all the components you're using quickly and say okay, this is secure. This is not secure. I think that's a really good idea.

I think that we should we should forward to make that as much as we can write. So this analysis of code should be done by our automation because that way we can scoop everything up and then have human expertise look at so like the high in this issues. Yeah.

No, I think that's a really good idea. I suspect there will be some if she's around that. I mean the other thing as well is that that code is changing so frequently, right?

So we do a lot of website security assessments, right and lots of web applications use various job of script libraries. Every single job in the script library is is being updated on a regular basis and there are lots of vulnerabilities out there for it right. Now.

A lot of those vulnerabilities can't really be used to achieve very much right now, but you've got this constant development of code with new features being built into it. So we've got to think about how do we keep up with that? Because software just isn't static.

So I think you're right we do need to do it. But again we need to do in a smart way, which means that we really have to technically assess this code say this is what we've assessed it for. This is what we know is bad is what I know, it's good and also this is what we don't know and we're working out how we're going to assess that at some point.

You mentioned s bombs one of the challenges in my mind at least is that the applications themselves are more Dynamic than ever. They are made up of containers and microservices and the environment is changing faster and faster can the S bombs actually keep Pace with that. And if so on the back end of this am I going to have kind of a red light green light system somewhere that says, oh wait.

I see this components in the s bomb and so we're not going to use this application. Show my honest opinion. Yeah, I I don't think as formal keep up right.

I think that I think sbom is a it's a it's a reasonably good idea. Right? I think that when you actually peel it back again, like so many ideas that that we run into inside security.

The implicate the implementation is going to be really difficult. Right? I mean, that's not even think about all the all the clothes software.

I mean, there's loads of Open Source stuff, but all the kind of then the produce stuff that's locked down. I can't see the source code. I don't know what live reason Microsoft Windows for instance.

They may have come from somewhere else, right? So I think that the s-pong concept is is nice. I think the Practical implementation is going to be really yeah, there's a few of these libraries that I use a lot that we've done work on so we know they're secure but then there's this whole population of other stuff that we just can't get because it's just it's just so complicated.

Do we have a problem that is so large that people can't contemplate it because there are billions and billions of lines of code for applications already installed most of which was used. Um, involving components that nobody tested to your earlier point of view. So it would take us decades to replace all that stuff.

So is this an issue that's going to go away anytime soon or is there something to be done about the security technical debt that we've recruit over the last three decades of not paying attention to this. graphical install whatever again but in reality We're not gonna do that, right so I mean things that It's interesting right because cyber security so I've been inside security Now. Unofficially for 37 years, right which makes me far too old and you see these waves come through right?

So back in the day we were just about you know, nobody really knew about cyber security, right? So we break into stock. It was cool.

You know, we're great. It's cool. And then as time went by you saw these waves of ideas and then a few years ago, you got to this concept of of assumed reach, right?

So I'm gonna assume someone's in my network assume they're in there and they're causing Havoc. How do I capture them? And I think that that's so evolves into that that we've stopped trying to be proactive to use that terrible term about this.

So really, we're not going to fix all the technical debt. Right? What we need to do is focus on testing the stuff we've deployed to find these holes and fix them and at the same time develop technologies that are actually able to join these thoughts because if I'm using the vulnerable JavaScript library, but you can't get anywhere I shouldn't have to worry about that.

Right like I can deal with that tomorrow. What we need is is technology that again it's testing out software to find holes testing environments testing them in terms of how they're actually deploying and also giving people who have fixed this stuff the information they need to prioritize and I think that's the biggest thing right? I think when you look at Concepts like as form when you look at one of these again and right when you look at all those things, You end up with these giant lists of problems and you landed on some scissors desk?

And you see those like, okay. Well, I have two people working in my security where stretched as it is and you've just given me 10,000 new problems. So I think that working on automation to find issues testing stuff.

That's good. So don't don't assume reach assume that you stop them as soon as you can but also more importantly is providing context to people who have to fix these issues so they can really focus on what's important. So s form is nice.

I mean it will show up and you give me this whole list of things and I'm gonna go reference all the security ratings around those and I'm gonna find I've got 10,000 one software like in my environment. No one I mean, okay. So what now?

What do you do? Do you pull that out and say what actually no marketing department. We can't launch our platform today because we have 10 vulnerable libraries because that's not going to work.

You're going to end up unemployed, right? So I think that we that we have to change the way we're approaching is realize there is a lot of tech and that there is a lot of vulnerable software out there but realize that you don't need to fix everything today. You need to work out what's important to me and realize that what's important to me may not be important to you and then figure out okay, that's why I'm gonna focus on that's what we need to do.

What's your sense of the relationship between security teams and developers? Is that improving? Everybody talks about shifting security left towards developers most developer design know security was an elective that they never took and they don't really have a whole lot of experience and most developers are trying to figure out how to get past the security guys so they can get their app into production and sometimes they just ignore them around them.

So, you know, what should we do? Do I put them all in a room and lock the door and hope for the best or is there some way they can bring these folks together? Well, the development team in my company is really good at security.

So they're cool. Yeah, I mean that that Rift is still there, right? I mean having been around this for a long time.

I've been through lots of I mean, I remember the the cowboy hat books back in the day on application security and there was discussion of okay, we'll get developers to know about stlc and how it should be and there's a lot of talk about that that didn't really work and then we've had like, you know devops insect devops and all these things and I think there's still this there's still this Gap and I think fundamentally it comes back to why I was just talking about right if I'm in develop. I'm usually producing a product that my company wants to go down right Honest. It's open source, in this case that's different, but I'm producing this thing and I'm under the gun still to do it as fast as possible.

So I am going to shortcut the security controls. I'm going to try and bypass it because just go get the code out the door because my boss is breathing down my neck because someone's breathing down there. And so on and so forth.

So I think that again coming up with I mean, it's very grandiose. Right but I mean if code is secure by default if if we're using development environments that you know, the chance of introducing and security vulnerability is really hard to begin with and everyone's just using that and we go automated testing going on to make sure these things are secure. That's what we need to do because I don't think you're ever going to get every software developer to drink the cyber security Cooney because they just have competing goals right this I mean I've been on phone calls still right where CEOs of companies want to bypass the security controls so they can read their email on their iPad while they're on vacation, right?

So if you start from there. As that permeates down everyone is under the gun to get things done quickly and security is just a secondary thought and that's not going to change. I don't see that change and I've spoken to lots of development shops.

I been around lots of application Development. I've seen lots of the end State and we still find loads of security. We find Security money really is in everything right and it's not the full of the developers, right?

It's full of the construct that they're working in. All right guys, but you heard it here we are unsafe at any speed. So hopefully we can all come together and figure this out, but just like the automotive industry way back in the 60s.

It took them about a decade and a half to build safe cars and we may be on the same trajectory Mark. Thanks for being on the show. Thank you very much.

Thanks. Have a good day. All right guys back to you in the studio.