Videos

Jon: There's an important difference between automation and autonomy. And autonomy is software-driven where software is making the decisions on how to do containment.

Christina: So, is that based then in an AI world or a machine learning world and do we have to get to the singularity or do we have to get to a certain level of AI before we can do that?

Jon: I think it will certainly help. Being able to take actions over and over and over again and then learning from the results of those actions to drive confidence in the action so that, then, when a decision is made you can take a little bit more risk on actions that have a higher confidence that it will not create some unintended consequences. So, I think machine learning will absolutely help in that space.

The technology specific to that is, like, self-driving cars, like, they're multi-objective optimizers, you know, life safety, fuel efficiency, time to destination, they have all these things to think about when they decide, do I accelerate, do I decelerate. It's the same exact problem only it's, does the system stay up, does it keep the bad guy out of the network, is it a resiliency thing.

To be resilient, we have to take responses that mitigate the threat and keep the system up.

Christina: So, who's doing that today? Any of it? The detection, the automated detection, I'm hearing some folks doing. So, that's starting. The response? I am hearing a little bit about setting policy that if X happens, take Y action. It's in lower criticality of assets.

It's where you know that there's no PII or PHI kind of data, right? Who's doing it that you know of?

Jon: Not many people. Not many people. I mean, this is the age-old problem of why we don't patch because we don't know if the patch is going to cause more harm than good, right? Like, if you just look at what's going on in New York City right now with the traffic lights, you know? There was some patch that caused issues and they just didn't know. But if you knew that when you take an action, it didn't cause an issue, then you're comfortable taking that action.

And by the way, these actions have to take place, not just in production environments but in preproduction environments so that if we see something in a preproduction environment that is a vulnerability and we can figure out how to shield the exposure to that vulnerability in a production environment, then that's an action we could take and still ship the code.

Christina: And we do see that starting to occur more and more. We are seeing the SAST and DAST dynamic of testing during run-time, testing in code review, testing before code, you know, while you're coding, we're seeing more and more of that, but it's still not really trusted and I think there's a huge cultural impact where it has to be a top-down initiative that the executives are bringing to the company and say we are going to be in a DevSecOps world.

We are going to make it easy for you. We're going to give you bite-sized chunks, you know, to start playing with this until you trust the process.

Jon: I think that's spot on. But why do you think IT and the DevOps world is so resistant to security?

Christina: Because security slows them down.

Jon: Exactly.

Christina: Right. It's an obstacle. It's a big stop sign instead of saying, "Keep going.You can develop and deliver your whatever it is you're making out of code. You can deliver it on time. No, wait. Stop. We want to put security in here." And they feel like it's an obstacle. Now that we have tools, we are starting to see some of that automation.

Jon: Absolutely. And that's terrific. When the IT guy says or the executive says, "Security people don't care about time," that's totally not true. I mean, look at the metrics, mean time to detect, mean time to patch, mean time to contain, like, every key performance indicator we have is a time-based metric.

Christina: It's a cultural disconnect.