Automatically Patching to Remediate Vulnerabilities – Jeffrey Martin, Mend

This is Textron TV. Hey guys. Thanks from the throne.

We're here with Jeffrey Martin who's BP products for men and we're talking about fear and loathing of automation as it relates to threat remediation and patching seems to be a growing concern out there Jeffrey. Welcome the show. Hey, oh, it's nice to see you.

Thanks for having me Mike. So the perception is is that people need to get a patch built. They wait for it to come along they tested and then they install it and they hope that things don't break and the end result is we don't seem to patch things very aggressively and frankly.

There's just a lot of software out there that needs patching that doesn't get patch. So what is your sense of what drives this issue? And is there something to be done about so I think there's a few different vectors of concerning here one is simple fact that whenever you update anything you're introducing the chance that it might stop critical things from working or even on critical things just are pain to fix in short.

Sometimes fixing a security problem can introduce a functional problem. The other one is a little bit more mental, you know people tend to not want to change things unless think it's worth it. You know, some people do that little risk calculation in their head.

Like I do other people just have a general reluctance to update or change unless there's something very important driving that change. That's one of the reasons I think that well, there's two big Solutions driving this as a more standard practice one is actually getting measurements of the functional risk. Right in front of you when you're looking to remediate and looking to upgrade so, you know, how risky is this isn't going to introduce a breaking change.

Is it going to quickly infrastructure? If I update this in the name fixing a security problem? And then the other one is the prioritization of the problems that solves.

Great if I introduce this. And my fixing a problem that actually matters to me or am I fixing a problem that is of mediocre importance and frankly. I shouldn't really be too concerned about it because the attack chain is 13 steps.

Why and I have some mitigation. um the open SSL Zero Dave on the just dropped yesterday. Although we had some advanced notice of it actually is a good example of this where there's most of the time.

It's the high vulnerability. It's important. It's a critical problem.

but honestly, most people have open SSL deployed already have Mitigation in place buffer overflow Protections in the OS things like that that makes it very unlikely to be a real Attack chain. but there's about zero risk and updating. So why not?

And I think those factors are what's really necessary. All that information is necessary for people to make informed quick decisions about what the update and how hmm and how much this is also just related to simple inertia because a lot of times developers are handed this list of vulnerabilities weeks months after they wrote the code and they're off on another project and they don't have any context and they're kind of looking at it going. I have a choice between writing new code or passion this thing and I don't remember exactly what the issue was.

So I'm just gonna get Yeah, I mean look legacy codes always an issue. Legacy can be in some some companies a few months and other companies that can be a decade. Fundamentally, there is this calculation that has to happen about context switching, right?

The inertia you kind of referring to is people don't want to go dive into something. Until they know what's there if is it worth it, um, silly analogy, but you know, I'm a homeowner. I have a huge reluctance to opening up any wall because I never know what's gonna find in there.

So right that inertia that blockage of actually going and looking is because It's unknown. I don't know what's behind that wall as soon as I open it up. I'm gonna know that's not good.

the solution to that Is being able to have a continual running visibility of code? Whether it's New or Old I'm gonna beat this analogy to death see through walls would make it. So I'd have no problem opening up the wall that the unknown that fear of what am I getting into can be Saul through things like automated inventory generation and you know source code now assist to actually know what your vulnerabilities are Etc.

It's sort of a sunlight problem right once if I can see it. I'm not afraid of it. So as people go down this path do they need to make a calculation that kind of feels like this.

It's like well, what is the probability that this patch is going to break something versus what is the probability that this vulnerability is going to be exploited. And is this just basically an algorithm or something that somebody can run in a program and just kind of show me the graph that says, you know, here's what you're kind of wager or not. acting likelihood And impact of other risk, look I think we tend to paint developers a little bit too analytical sometimes just in general.

Yes. Absolutely. I mean I make security software.

There is a huge amount of value in being able to say okay. This vulnerability is on this Library. It's a public exploit is known.

I'm touching the vulnerable code and it's in Credit card processing software so I really care about the impact. But the fact of the matter is most people actually don't do the calculations like that. Most people say I'm gonna fix everything that's critical and high.

And the reason they do that is because they don't want to go through all the steps. It to them. It's not worth it.

They just say great. I'm just gonna update the stuff in a blanket way. This causes a lot of issues.

That could be solved through more analysis. I think the biggest piece is making sure that you know that functional risk. That you're introducing because frankly upgrading a library.

Isn't that big of a deal? It's not much work. It's just a question of what are you gonna introduce now?

What do you breaking? What are you? causing to happen next or Worse your upgrading into more vulnerabilities, which is never good.

Um, so I think the real key is that one piece of information if you boil it all down. Yes, big complex algorithms help specially at a big scale. But if you can boil it down just one piece.

It's if I fix this problem am I making more problems? Do you think we'll ever get to the point where the security teams will just go ahead and Patch stuff themselves and then they'll call people when it breaks, but basically they're gonna bet on the patch side of that equation and then they're just gonna be like, you know, wait for somebody starting yelling if something breaks. Yeah, I mean short answer is yes, but I do think you know, look there are things that are more risky than others, right if I'm gonna update something three versions.

That's a lot more risky than if I'm updating it a point version. 2. 2.

It's probably breaking. Something somewhere. So there's some room for reasonableness there, but I think eventually look the way everything's trending automatic dependency updates are going to be the norm.

Keeping up the date using latest tags in your you know, package manager always trying to keep up to date is really the only real way to keep update on the security. If you have to do everything as I've identified it now, I'm gonna go take us an evaluation step and then I'm gonna patch it. It takes too long.

It's too much pain and frankly people don't do it. I'm just keep everything up to date. It's a good strategy that will eventually bubble out everywhere.

But there has to be that sanity in there to say especially on Legacy code. Hey, wait a minute. We're jumping four versions.

This probably isn't a good idea. Let's at least take a look at this first. What is your real sense of what's going on here between developers and security teams every time you turn around.

Somebody's singing a little devsecops come by and my question is is that what we're really working towards are we just trying to get out of each other's way and let people go do what they need to do in a way that works for both sides of this equation, but we're kind of really not looking to have a moment where we're all joined the hip and everything we want to do has to be checked with the other team. I always love that. Look, I'm a product guy at heart.

Right? I love my Dev teams. I want to make sure we're aligned on things.

I don't want to have to discuss every single item. I don't need all the details. I need to say something like where we're going.

I have my role they have theirs and we don't necessarily have to know everything about everything. It's a matter of fact, it's kind of a waste of time. It's a little inefficient.

I've never been one to really say oh deaf secops means everybody should be there together and security should be in the Sprint planning and look the fact that matters. We all have different jobs. We should do them and we should try to not block each other from doing your jobs.

Because we're all working towards the same goal. So if you have that goal alignment. a lot of these other pieces fall into place where it causes conflict in the conflicts that I see most is when the goals aren't aligned.

So for example, if you were a goal security only on removing vulnerabilities. Well, then they're gonna only care about removing vulnerabilities. if you go Security on removing vulnerabilities but not breaking anything.

Then they're gonna focus on that so incentives and Alignment matter and I think that I love you, but at the Kumbaya of everybody, you know sitting around the campfire there that's not necessary and it's not realistic. What's actually necessary is having somebody point the way set the rules and then everybody executes their roles. Sounds very boring, but the fact that matter is sometimes good business processes or a little boring.

So the fact remains though that we have massive numbers of applications and whatever else is out there that is unpatched. So do we have some sort of massive technical security debt that we're all ignoring because you know, it's just too Pleasant in conversation and you know, but at some point this stuff's all going to come home the roost that some someday Yeah. That's sort of things.

I think everybody sort of turns a blind eye to its expression ignores the elephant in the room. most software's old most software is unsupported either officially or by not focusing on it, you know resource allocations. The fact of the matter is as we've grown our economies to be increasingly software based more of everything is based in software.

cars of easy example, but literally everything there are not enough. Dollars around to keep everything up to date. A lot of these things were built insecure by Design.

And the cost to replace them does is not. sufficient I'll rephrase that the cost to fix them is greater than the risk of hoping they don't fail and yeah, there's a ticking time bomb out there. But I think that what is we're really going to see is it's kind of focus on certain areas.

Because if I'm a bad actor, I don't necessarily care about bringing some random website down. I want personal data. I want, you know financial data.

I want to be able to influence geopolitics. There's certain goals. I have those areas should have higher investment.

We don't need to worry about every piece of Legacy software out there, but the critical ones Yeah, some day someday soon. I assume there's gonna be a nice big breach. Everybody's gonna wake up and go wait a minute what we're doing.

Why did we not do this and it'll be like but seat belts on cars. We're all getting the Wonder wait a minute. There was a time.

We all didn't have seat belts. That seems silly. He's dated myself on that one Jesus.

I seen you remember bouncing around the back of a station wagon in my youth. Yeah. to that end It was like we're never gonna make it cool and sexy for developers to patch applications.

They're just gonna be like, nobody wants to be on the digital maintenance Squad, right? They all want to go build the next cool thing and you can hardly blame them. So in the absence of that should everybody just at this point kind of go look we acknowledge the fact that we need to automate all this stuff because no one else is actually ever gonna manually do it anyway, so it's crazy for us to stand here and say, oh do that because we might break some Like it's the Windows update right?

I don't know about you but update myself again, you know, I remember Windows 3 You'd get nothing. How often do you ever update it? Pretty much never right even Windows 2000 or XP you weren't click on the update button and applying it and all that.

No. So nobody was ever up to date. But then one day Windows comes out and says Hey, where's auto update in the background and just don't worry about it and suddenly everybody's up to date.

That's what will happen. It'll be automated it will be. Vetted to a degree to make sure it doesn't introduce risks.

And there's a lot of Trends supporting that one is the reducing complexity of software. Which you know, it's one of those weird things because we're all going to Cloud but actually software is getting simpler. It's getting more easy to compose it instead of coding it from scratch and that means you can do things like automatically update patches with a little less risk and that risk keeps coming down every time.

Ah, you know, I'll use the open SSL one again just because it's in my mind because it was the news story this week. I am 100% sure. That there is no functional risk going from any of the open ssl3 versions to the latest one because I know that group tested the heck out of it.

Um, so why not keep it up to date? Yeah, I think you heard it here folks. You're either damned if you do and you're damned if you don't better to be damned for doing rather than doing.

Jeffrey thanks for being on the show. Thank you. It's always fun.

All right back to you guys in the studio.