Videos

Jon: To me, in order to outpace and outmaneuver the adversary, they can't be doing things with machines and we're doing things with humans. Like, we'll never win that. Even just from a cost perspective, even if we could throw lots of humans at it and do it faster, it's not going to work.

And so, we have to get to a point where we're doing things that have more software capability than we have in the past. In the whole security life cycle, all pieces of it, in every pillar, in a tax surface reduction, threat management, vulnerability management, incident response, penetration testing, the reason we throw software at it is because we need to get quicker and we need to get to scale.

Christina: Okay. I totally agree. I'm totally on board. And we're not there yet, right? I mean, what I see...

Jon: We're not.

Christina: ...is that software creates its own vulnerabilities, the way we develop it, right?

Jon: Yeah.

Christina: So, that's another layer that we have to defend against. I see that software-defined is not being taken up as I'd like to see it taken up. It's not really changing the architecture of the enterprise. And I also see that we still need humans in great abundance. So, when are we going to get there? How are we going to get there?

Jon: Well, I think the very technologies that are driving this immense human progress are the same technologies that we could use to drive progress in the security space. So, software-defined data centers, if you look inside of what Dell's doing, they're doing a lot of work on software-defined data center. They actually have more software engineers than hardware engineers.

Christina: Really?

Jon: Yeah.

Christina: So, you would know because you're part of the Dell family.

Jon: That's right. That's right.

Christina: So, they're your cousins, step-siblings.

Jon: They are. They are. Yeah. So, I'm advantaged because I get to see what they're doing and then I have to think about how to defend that. And so, that software-defined data center is really important. It gives security people two things that we traditionally haven't had. The first thing is the ability to just ask the network what it looks like.

So, you see an attack and you ask the question, "Is there a route to the target? Is there a way to get that attack to get to that target?" You ask the network and the network will tell you yes or no. It's pretty cool.

Christina: And how does the network tell you that in a software-defined environment?

Jon: Because it is software-defined.

Christina: Because software is everywhere and it is giving you the sense-making, if you will, right?

Jon: Yeah.

Christina: So, reporting back what it is, where it is, and what it's seeing.

Jon: Exactly. Exactly. It's the traffic cops. It sees where everything is going and knows where everything is. So, they...and like, we've always wanted to do microsegmentation. Now we can get to a point where we can actually implement microsegmentation if we knew what the segments were. That's the hard part.

So, we have to use software to be able to say, "Well, this environment and this environment never communicate," or "These two services communicate, and they communicate what I think is confidential data, so not only going to communicate, but we're going to make them communicate in an encrypted way.

Christina: Right. Or is it also looking at segmentation in terms of who has access to what where?

Jon: Definitely. Definitely. Definitely. But it's not just software-defined networking. It's software-defined compute. You see things like containers being used and workloads being moved all over the place and it's software-defined storage, too, where you store things and what the storage look like.

Christina: So, how far are we from that world in reality? Where are we today and where might we get to in three years, five years?

Jon: In the software-defined data center?

Christina: All of what you just described.

Jon: I think there's, in this industry, there's SOAPA or, like, a lot of orchestration going on. You guys have done amazing work around that space.

Christina: Thank you. Yeah.

Jon: And the reality is that's the first foray, as I see it, into being able to do automation. The problem is is if you look at who's using automation and what they're using it for, there's still not confidence that we're going to automate something and not break something. And so, for example, if you just look at incident response, the first step of the process is enrichment.

So, go out and collect all the information you need to assess this event or alert that you have to determine if it's really an incident. And that is very easily automated but it's also read-only and doesn't touch anything. When, then, you want to react or respond to an incident and you look at it and you go, "You know, I need to contain that machine," that's an opportunity for automation but we don't see a lot of people doing containment with automation.

Christina: They'll do detection and alerting with automation but they don't quite trust the detection yet to be able to block.

Jon: Yeah. Right. Or they just don't know. So, like, at that point, you know, if there's multiple objectives that need to be considered, like does this block actually mitigate the threat, does this block take something down or introduce an issue to the business and cause more problems. So, in that process, effectively, what needs to be done is...we talk a lot about analytics for detection.

Well, I think we'll also be talking about analytics for response. Like, things that will be multi-objective optimizers and go, "Okay. I know all the things that are important.This is the action that either piece of software is going to take." And that's the difference between software-defined and software-driven.