Zero-Day Vulnerabilities, Steve Wilson – Contrast Security

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

We're here with Steve Wilson is cheap product officer for contrast security. We're going to be talking about zero day vulnerabilities and how much fun they are lately Steve. Welcome the show.

Hey, thanks a lot. Mike happy to be here. These things are in the news these days.

It seems like every I don't know two months or so, maybe three somebody's waking up in the morning and discovering that there's some new zero day vulnerability most infamous being logged for Jay shell that a lot of people are still out there looking for I guess the question is is there some way to get in front of all this stuff or some way to respond faster because it looks like right now, you know, we're tearing our hair up. Yeah, absolutely. And I think part of the reason that we're all tearing our hair out is this is accelerating.

I mean there have been zero days happening for a long time. But you know, especially in this open source space and around these large ecosystems like Java. It used to be once every few years and now it feels like it's once every few weeks.

So it's just rapidly accelerating. So maybe the strategies that people have developed the last few years. Aren't enough and you know when you think about the strategies people are using their their inherently reactive.

So, you know, you think about running a set of composition analysis tools on your source code for your application that tell you when a zero day has been discovered. And so now you're in a race with every hacker in the world to patch up your systems. There are a bunch of ways though to look at really getting ahead of these things and these include doing really deep inspection on your applications using things like interactive application security testing that can actually help you find those vulnerabilities before their publicly announced and then ways to build defenses into your applications things like runtime protection where you can actually protect yourself from these exploits even before the vulnerabilities are known in and out.

How quickly are the bad guys exploiting those zero day vulnerabilities? Do I have days weeks months or is it more like hours and minutes before somebody starts pounding on these things? So the bad news is it's worse than that when log4j happened last December.

We have a set of Technologies to do runtime protection on applications where um, we didn't have to see we didn't have to know about the log for J exploit because we protect against generic exploits for things like log injection. And so what we were able to do was rewind back in time through our Telemetry on our customer's applications and see that hackers. Were already trying to exploit that vulnerability more than two weeks before it was announced.

You know, these are open source communities full of lots of different characters. And while there's a lot of care putting into trying to manage these things from the time that they might be exposed from an ethical hacker till the time that they're patched. There can be a lot of exposure there.

And so really if you wait for the for the zero day announcement you're already way behind the curve. All right. Well, there's nothing quite like being the last to know.

How much therefore should security be shifting left because there seems to be a debate as to whether or not it should go all the way the developer or she go just to the devops team and lean left because the developers are never going to figure out the security issues fully so or is this one of those situations where the correct answer is All the Above? Of the above because it's some level it's true. but I think the classic app second approach that's been dominated and driven by a security team that's separate from development is known to not work.

That's a that the system where you're doing scans, maybe once a quarter. So not only do you not find out about it on Day Zero. You might not find out about a problem until day 90 and then you're way behind the curve and you know, when you think about us being more than six months past log per day and people still finding that they're exposed for it that that's part of the reason.

so you certainly have to shift left you have to get earlier in the dev cycle developers need to start to understand these security issues and how they can really get involved in finding them and fixing them and You know this term SecOps. I'm not sure that term is durable because I think at some point it just folds into being part of devops, but it's the same kind of evolution that we had between Devon Ops before we're just throwing it over a wall to another group and hoping they'll manage the application correctly. Um, it's just as naive to think you can throw your app over a wall and someone else will take care of the security.

We've been talking about SecOps for a while and I think everybody kind of snods their head when the sermon is given but somehow or other I feel like you know the minute they exit the proverbial Church they forget all about it. So when are we gonna do to make Dev sake Ops kind of stick? It's been interesting.

You know, I've been at contrast for almost two years now and I've seen a lot of movement in the space in that two years, you know, we work with hundreds of the world. Largest corporations governments on helping secure their applications and there's been a real meaningful shift during that time in terms of how people are looking at this life cycle. I'd say when I got here.

Developers really weren't conscious of this. It was it was only a fringe that was thinking about it. Now.

It's really becoming mainstream the trends are we see more and more we see the development teams getting involved in selecting security tools getting involved in operating them. There's still a long way to go. But but there's been a tremendous shift in the last one to two years.

What should the ideal relationship between those teams be because we all know there's a cultural divide there and you know for years people were throwing spreadsheets over the wall with a bunch of vulnerabilities that were routinely ignored. So, how do we kind of make this better? Yeah, look at my job before I came to contrast I lived through this leading a large development organization.

Where I had the head of engineering come to me one day and say hey Steve, I got to cancel the roadmap next quarter and then explained to me that the security team had run a scan and filed a thousand bug tickets on the code base. Um, we're there a thousand real vulnerabilities there. Absolutely not.

there weren't more than a handful, but it was incredibly disruptive to everything involved schedules deliverables and just personal tension and strife within the company so that throw it over the wall attitude has to change. So I think it's got to come from both sides first off the security team needs to and I think they're starting to acknowledge. The delivering software is what drives the business it is the most directly correlated thing to your company being successful is that you're able to deliver better software faster.

That's what most companies in the world compete on. So you can't take the attitude that you're a blocker and the Securities more important than everything else. other hand The security sorry the development teams have been just as guilty of this saying the security stuff.

It's all a bunch of Holcomb. I don't need to worry about that. I just need to get my code out and you know, I'm willing to throw it over the wall to you guys and you guys do something about it.

Um, it's really about a spirit of cooperation and it's really about being one team and you may have specialists in different areas and you're going to have some Specialists on your team. Who have deep application security knowledge we're going to help you understand a new class of vulnerability that your tools have helped you find or help you find the best tools or the best ways to integrate that into your Pipelines. Um, but much the same way that you know today there's there's virtually no wall between QA and development.

I remember when I started developing we wrote code. We threw it over a wall to another team called QA then weeks later. They would send us back bugs that that doesn't That doesn't work that hasn't worked in a long time and securities going through that same transformation.

Do you think as we go along that? I don't know maybe we'll AI save us from ourselves or their advances in technology that we can look forward to here that might solve some of these issues. You know, the the funny thing about things like security is you would hope there's gonna be a magic Silver Bullet From a technology point of view.

But things like AI are an arms race you can develop more and more sophisticated mechanisms for detection and protection using machine learning techniques. But you have to know that the bad guys are doing the same thing. And in fact the the bad guys who are very well funded nation state actors and everything else.

You better believe. That they're deeply invested in things like AI so I do think that the industry needs to be looking really hard at how to bring more and more Advanced Techniques to Bear the standard. You know static code scan is just outdated or at least it's only one tool in Your Arsenal you need a much more sophisticated set of tools that have deep hooks into the application that don't just look at the source code, but can also look at how it's performing.

Well, it's running you don't need just application security testing you need application protection built into the app so that it can you know, and sort of the spirit of zero trust that that app doesn't have to depend on some other Firewall or something like that to keep it safe. It's got to be built in. Are there best practices for scanning because you talk to some folks and they're like well, I just wrote a small amount of code.

So I won't scan that and then I'll just keep being adding more and more small amounts of code. And then suddenly it's the end of the week and there's this massive ball of code that hasn't been scanned. So, is there a better way to thinking about scanning?

Well, so the funny thing is is developers. Sometimes view these things as a bird and look there's a lot of cognitive overload when you're developer. There's so many things shifting you're trying to move to the cloud.

You're trying to move to Agile. You're trying to adopt all these new practices and learn a new programming language. So you have to acknowledge that But I remember those those early days as a developer where we'd code and then somebody would do a big test Blitz two months later and send back bugs.

And your development teams looking at these bugs going? Well, what what could have changed? Why did this regress and you have two months worth of code to sift through to try and figure out what could have changed.

Now when we have modern integration testing, you're gonna find out most of those things. If if not within hours at least within a day when you made the changes, so you're like wow. Well, I know what I worked on yesterday.

I know what broke let me go. Look at fixing that. Security can be the same way.

So when you build security into your pipeline in a deep way, so first off you want it in your, you know at the latest in your integration test pipeline so that you're getting your security test results the same time that you're getting your quality test results. It can't be any less frequent than that. The other thing that developers really like is being able to have for example a scanner that they can run on their laptop before they commit their code because the last thing a developer wants is to get called out by somebody else that they just created a bad bug that they got to go backtrack and fix and so their tools now contrast has a tool called codec.

It's totally free developers can download it. They can scan their applications in you know, seconds or minutes getting instant set of results and then you can actually build that into the front end of your pipeline so that when you do A pull request to integrate your code back into the source base. It gets scanned really quickly get your set of results instantly and those security bugs never even get back into the code base.

Yeah, so let me ask you can we make our applications more secure without slowing down the rate at which they are being built or is that just an impossible goal? You absolutely can and I think not only can you make it? Can you make it not hurt you can make it better.

That's the key thing. Is that by really making security part of the agile process and not something from the outside? You don't wind up with these?

In frequent large disruptions, you don't wind up with these crisis management situations where somebody filed a thousand tickets on you or you wind up with a zero day that you're not prepared for by integrating this in and early and having the right Tools in place and having everyone on the team from development through the security team be working together. You can make the security part of this really transparent where it's not today today. It's a big drag on productivity for a lot of organizations.

So don't think of sort of moving to security as something that's going to be a big burden in the long term. It's something that's gonna lift the burden off your developers. It's going to empower them.

It's going to accelerate them and and really be net net a huge uplift on productivity while reducing the risk for the organization. All right, folks. You heard it here first.

There's not much we can do about the bad guys, but we're certainly making it a little too easy for him right now. Hey, Steve. Thanks for being on the show.

Hey, thanks a lot. Mike. All right back to you guys in the studio.