(upbeat music) >> Hi, everybody. We're wrapping up day two of AWS Re:Inforce 2022. This is theCUBE, my name is Dave Vellante. And one of the folks that we featured, one of the companies that we featured in the AWS startup showcase season two, episode four, was Illumio. And of course their here at the security theme event. PJ Kerner is CTO and Co-Founder of Illumio. Great to see you, welcome back to theCUBE. >> Thanks for having me. >> I always like to ask co-founders, people with co-founder in their titles, like go back to why you started the company. Let's go back to 2013. Why'd you start the company? >> Absolutely. Because back in 2013, one of the things that we sort of saw as technology trends, and it was mostly AWS was, there were really three things. One was dynamic workloads. People were putting workloads into production faster and faster. You talk about auto scale groups and now you talk about containers. Like things were getting faster and faster in terms of compute. Second thing was applications were getting more connected, right? The Netflix architecture is one define that kind of extreme example of hyper connectivity, but applications were, we'd call it the API economy or whatever, they were getting more connected. And the third problem back in 2013 was the problems around lateral movement. And at that point it was more around nation state actors and APTs that were in those environments for a lot of those customers. So those three trends were kind of, what do we need to do in security differently? And that's how Illumio started. >> So, okay, you say nation state that's obviously changed in the ROI of for hackers has become pretty good. And I guess your job is to reduce the ROI, but so what's the relationship PJ between the API economy, you talked about in that lateral movement? Are they kind of go hand in hand? >> They do. I think one thing that we have as a mission is, and I think it's really important to understand is to prevent breaches from becoming cyber disasters, right? And I use this metaphor around kind the submarine. And if you think about how submarines are built, submarines are built with water tight compartments inside the submarine. So when there is a physical breach, right, what happens? Like you get a torpedo or whatever, and it comes through the hall, you close off that compartment, there are redundant systems in place, but you close off that compartment, that one small thing you've lost, but the whole ship hasn't gone down and you sort of have survived. That's physical kind of resiliency and those same kind of techniques in terms of segmentation, compartmentalization inside your environments, is what makes good cyber resiliency. So prevent it from becoming a disaster. >> So you bring that micro segmentation analogy, the submarine analogy with micro segmentation to logical security, correct? >> Absolutely, yes. >> So that was your idea in 2013. Now we fast forward to 2022. It's no longer just nation states, things like ransomware are top of mind. I mean, everybody's like worried about what happened with solar winds and Log4j and on and on and on. So what's the mindset of the CISO today? >> I think you said it right. So ransomware, because if you think about the CIA triangle, confidentiality, integrity, availability, what does ransomware really does? It really attacks the availability problem, right? If you lock up all your laptops and can't actually do business anymore, you have an availability problem, right. They might not have stole your data, but they locked it up, but you can't do business, maybe you restore from backups. So that availability problem has made it more visible to CEOs and board level, like people. And so they've been talking about ransomware as a problem. And so that has given the CISO either more dollars, more authority to sort of attack that problem. And lateral movement is the primary way that ransomware gets around and becomes a disaster, as opposed to just locking up one machine when you lock up your entire environment, and thus some of the fear around colonial pipeline came in, that's when the disaster comes into play and you want to be avoiding that. >> Describe in more detail what you mean by lateral movement. I think it's implied, but you enter into a point and then instead of going, you're saying necessarily directly for the asset that you're going after, you're traversing the network, you're traversing other assets. Maybe you could describe that. >> Yeah, I mean, so often what happens is there's an initial point of breach. Like someone has a password or somebody clicked on a phishing link or something, and you have compromise into that environment, right? And then you might be compromised into a low level place that doesn't have a lot of data or is not worthwhile. Then you have to get from that place to data that is actually valuable, and that's where lateral movement comes into place. But also, I mean, you bring up a good point is like lateral movement prevention tools. Like, one way we've done some research around if you like, segmentation is, imagine putting up a maze inside your data center or cloud, right. So that, like how the attacker has to get from that initial breach to the crown jewels takes a lot longer when you have, a segmented environment, as opposed to, if you have a very flat network, it is just go from there to go find that asset. >> Hence, you just increase the denominator in the ROI equation and that just lowers the value for the hacker. They go elsewhere. >> It is an economic, you're right, it's all about economics. It's a time to target is what some our research like. So if you're a quick time to target, you're much easier to sort of get that value for the hacker. If it's a long time, they're going to get frustrated, they're going to stop and might not be economically viable. It's like the, you only have to run faster than the-- >> The two people with the bear chasing you, right. (laughs) Let's talk about zero trust. So it's a topic that prior to the pandemic, I think a lot of people thought it was a buzzword. I have said actually, it's become a mandate. Having said that others, I mean, AWS in particular kind of rolled their eyes and said, ah, we've always been zero trust. They were sort of forced into the discussion. What's your point of view on zero trust? Is it a buzzword? Does it have meaning, what is that meaning to Illumio? >> Well, for me there's actually two, there's two really important concepts. I mean, zero trust is a security philosophy. And so one is the idea of least privilege. And that's not a new idea. So when AWS says they've done it, they have embraced these privileges, a lot of good systems that have been built from scratch do, but not everybody has least privilege kind of controls everywhere. Secondly, least privilege is not about a one time thing. It is about a continuously monitoring. If you sort of take, people leave the company, applications get shut down. Like you need to shut down that access to actually continuously achieve that kind of least privilege stance. The other part that I think is really important that has come more recently is the assume breach mentality, right? And assume breach is something where you assume the attacker is, they've already clicked on, like stop trying to prevent. Well, I mean, you always still should probably prevent the people from clicking on the bad links, but from a security practitioner point of view, assume this has already happened, right. They're already inside. And then what do you have to do? Like back to what I was saying about setting up that maze ahead of time, right. To increase that time to target, that's something you have to do if you kind of assume breach and don't think, oh, a harder shell on my submarine is going to be the way I'm going to survive, right. So that mentality is, I will say is new and really important part of a zero trust philosophy. >> Yeah, so this is interesting because I mean, you kind of the old days, I don't know, decade plus ago, failure meant you get fired, breach meant you get fired. So we want to talk about it. And then of course that mentality had to change 'cause everybody's getting breached and this idea of least privilege. So in other words, if someone's not explicitly or a machine is not explicitly authorized to access an asset, they are not allowed, it's denied. So it's like Frank Slootman would say, if there's doubt, there's no doubt. And so is that right? >> It is. I mean, and if you think about it back to the disaster versus the breach, imagine they did get into an application. I mean, lamps stacks will have vulnerabilities from now to the end of time and people will get in. But what if you got in through a low value asset, 'cause these are some of the stories, you got in through a low value asset and you were sort of contained and you had access to that low value data. Let's say you even locked it up or you stole it all. Like it's not that important to the customer. That's different than when you pivot from that low value asset now into high value assets where it becomes much more catastrophic for those customers. So that kind of prevention, it is important. >> What do you make of this... Couple things, we've heard a lot about encrypt everything. It seems like these days again, in the old days, you'd love to encrypt everything, but there was always a performance hit, but we're hearing encrypt everything, John asked me the day John Furrier is like, okay, we're hearing about encrypting data at rest. What about data in motion? Now you hear about confidential computing and nitro and they're actually encrypting data in the flow. What do you make of that whole confidential computing down at the semiconductor level that they're actually doing things like enclaves and the arm architecture, how much of the problem does that address? How much does it still leave open? >> That's a hard question to answer-- >> But you're a CTO. So that's why I can ask you these questions. >> But I think it's the age old adage of defense in depth. I mean, I do think equivalent to what we're kind of doing from the networking point of view to do network segmentation. This is another layer of that compartmentalization and we'll sort of provide similar containment of breach. And that's really what we're looking for now, rather than prevention of the breach and rather than just detection of the breach, containment of that breach. >> Well, so it's actually similar philosophy brought to the wider network. >> Absolutely. And it needs to be brought at all levels. I think that's the, no one level is going to solve the problem. It's across all those levels is where you have to. >> What are the organizational implications of, it feels like the cloud is now becoming... I don't want to say the first layer of defense because it is if you're all in the cloud, but it's not, if you're a hybrid, but it's still, it's becoming increasingly a more important layer of defense. And then I feel like the CISO and the development team is like the next layer maybe audit is the third layer of defense. How are you seeing organizations sort of respond to that? The organizational roles changing, the CISO role changing. >> Well there's two good questions in there. So one is, there's one interesting thing that we are seeing about people. Like a lot of our customers are hybrid in their environment. They have a cloud, they have an on-prem environment and these two things need to work together. And in that case, I mean, the massive compute that you can be doing in the AWS actually increases the attack surface on that hybrid environment. So there's some challenges there and yes, you're absolutely right. The cloud brings some new tools to play, to sort of decrease that. But it's an interesting place we see where there's a attack surface that occurs between different infrastructure types, between AWS and on-prem of our environment. Now, the second part of your question was really around how the developers play into this. And I'm a big proponent of, I mean, security is kind of a team sport. And one of the things that we've done in some of our products is help people... So we all know the developers, like they know they're part of the security story, right? But they're not security professionals. They don't have all of the tools and all of the experience. And all of the red teaming time to sort of know where some of their mistakes might be made. So I am optimistic. They do their best, right. But what the security team needs is a way to not just tell them, like slap on the knuckles, like developer you're doing the wrong thing, but they really need a way to sort of say, okay, yes, you could do better. And here's some concrete ways that you can do better. So a lot of our systems kind of look at data, understand the data, analyze the data, and provide concrete recommendations. And there's a virtual cycle there. As long as you play the team sport, right. It's not a us versus them. It's like, how can we both win there? >> So this is a really interesting conversation because the developer all of a sudden is increasingly responsible for security. They got to worry about they're using containers. Now they got to worry about containers security. They got to worry about the run time. They got to worry about the platform. And to your point, it's like, okay, this burden is now on them. Not only do they have to be productive and produce awesome code, they got to make sure it's secure. So that role is changing. So are they up for the task? I mean, I got to believe that a lot of developers are like, oh, something else I have to worry about. So how are your customers resolving that? >> So I think they're up for the task. I think what is needed though, is a CISO and a security team again, who knows it's a team sport. Like some technologies adopted from the top down, like the CIO can say, here's what we're doing and then everybody has to do it. Some technologies adopted from the bottom up, right. It's where this individual team says, oh, we're using this thing and we're using these tools. Oh yeah, we're using containers and we're using this flavor of containers. And this other group uses Lambda services and so on. And the security team has to react because they can't mandate. They have to sort of work with those teams. So I see the best groups of people is where you have security teams who know they have to enable the developers and the developers who actually want to work with the security team. So it's the right kind of person, the right kind of CISO, right kind of security teams. It doesn't treat it as adversarial. And it works when they both work together. And that's where, your question is, how ingrained is that in the industry, that I can't say, but I know that does work. And I know that's the direction people are going. >> And I understand it's a spectrum, but I hear what you're saying. That is the best practice, the right organizational model, I guess it's cultural. I mean, it's not like there's some magic tool to make it all, the security team and the dev team collaboration tool, maybe there is, I don't know, but I think the mindset and the culture has to really be the starting point. >> Well, there is. I just talk about this idea. So however you sort of feel about DevOps and DevSecOps and so on, one core principle I see is really kind of empathy between like the developers and the operations folks, so the developers and the security team. And one way I actually, and we act like this at Illumio but one thing we do is like, you have to truly have empathy. You kind have to do somebody else's job, right. Not just like, think about it or talk about it, like do it. So there are places where the security team gets embedded deep in the organization where some of the developers get embedded in the operations work and that empathy. I know whether they go back to do what they were doing, what they learned about how the other side has to work. Some of the challenges, what they see is really valuable in sort of building that collaboration. >> So it's not job swapping, but it's embedding, is maybe how they gain that empathy. >> Exactly. And they're not experts in all those things, but do them take on those summer responsibilities, be accountable for some of those things. Now, not just do it on the side and go over somebody's shoulder, but like be accountable for something. >> That's interesting, not just observational, but actually say, okay, this is on you for some period of time. >> That is where you actually feel the pain of the other person, which is what is valuable. And so that's how you can build one of those cultures. I mean, you do need support all the way from the top, right. To be able to do that. >> For sure. And of course there are lightweight versions of that. Maybe if you don't have the stomach for... Lena Smart was on this morning, CISO of Mongo. And she was saying, she pairs like the security pros that can walk on water with the regular employees and they get to ask all these Colombo questions of the experts and the experts get to hear it and say, oh, I have to now explain this like I'm explaining it to a 10 year old, or maybe not a 10 year old, but a teenager, actually teenager's probably well ahead of us, but you know what I'm saying? And so that kind of cross correlation, and then essentially the folks that aren't security experts, they absorb enough and they can pass it on throughout the organization. And that's how she was saying she emphasizes culture building. >> And I will say, I think, Steve Smith, the CISO of AWS, like I've heard him talk a number of times and like, they do that here at like, they have some of the spirit and they've built it in and it's all the way from the top, right. And that's where if you have security over and a little silo off to the side, you're never going to do that. When the CEO supports the security professionals as a part of the business, that's when you can do the right thing. >> So you remember around the time that you and you guys started Illumio, the conversation was, security must be a board level topic. Yes, it should be, is it really, it was becoming that way. It wasn't there yet. It clearly is now, there's no question about it. >> No, ransomware. >> Right, of course. >> Let's thank ransomware. >> Right. Thank you. Maybe that's a silver lining. Now, the conversation is around, is it a organizational wide issue? And it needs to be, it needs to be, but it really isn't fully. I mean, how many organizations actually do that type of training, certainly large organizations do. It's part of the onboarding process, but even small companies are starting to do that now saying, okay, as part of the onboarding process, you got to watch this training video and sure that you've done it. And maybe that's not enough, but it's a start. >> Well, and I do think that's where, if we get back to zero trust, I mean, zero trust being a philosophy that you can adopt. I mean, we apply that kind of least privilege model to everything. And when people know that people know that this is something we do, right. That you only get access to things 'cause least privileges, you get access to absolutely to the things you need to do your job, but nothing more. And that applies to everybody in the organization. And when people sort of know this is the culture and they sort of work by that, like zero trust being that philosophy sort of helps infuse it into the organization. >> I agree with that, but I think the hard part of that in terms of implementing it for organizations is, companies like AWS, they have the tools, the people, the practitioners that can bring that to bear, many organizations don't. So it becomes an important prioritization exercise. So they have to say, okay, where do we want to apply that least privilege and apply that technology? 'Cause we don't have the resources to do it across the entire portfolio. >> And I'll give you a simple example of where it'll fail. So let's say, oh, we're least privilege, right. And so you asked for something to do your job and it takes four weeks for you to get that access. Guess what? Zero trust out the door at that organization. If you don't have again, the tools, right. To be able to walk that walk. And so it is something where you can't just say it, right. You do have to do it. >> So I feel like it's pyramid. It's got to start. I think it's got to be top down. Maybe not, I mean certainly bottom up from the developer mindset. No question about that. But in terms of where you start. Whether it's financial data or other confidential data, great. We're going to apply that here and we're not going to necessarily, it's a balance, where's the risk? Go hard on those places where there's the biggest risk. Maybe not create organizational friction where there's less risk and then over time, bring that in. >> And I think, I'll say one of the failure modes that we sort of seen around zero trust, if you go too big, too early, right. You actually have to find small wins in your organization and you pointed out some good ones. So focus on like, if you know where critical assets are, that's a good place to sort of start. Building it into the business as usual. So for example, one thing we recommend is people start in the developing zero trust segmentation policy during the development, or at least the test phase of rolling out a new application as you sort of work your way into production, as opposed to having to retro segment everything. So get it into the culture, either high value assets or work like that, or just pick something small. We've actually seen customers use our software to sort of like lock down RDP like back to ransomware, loves RDP lateral movement. So why can we go everywhere to everywhere with RDP? Well, you need it to sort of solve some problems, but just focus on that one little slice of your environment, one application and lock that down. That's a way to get started and that sort of attacks the ransomware problem. So there's lots of ways, but you got to make some demonstrable first steps and build that momentum over time to sort of get to that ultimate end goal. >> PJ Illumio has always been a thought leader in security generally in this topic specifically. So thanks for coming back on theCUBE. It's always great to have you guys. >> All right. Thanks, been great. >> All right. And thank you for watching. Keep it right there. This is Dave Vellante for theCUBE's coverage of AWS re:Inforce 2022 from Boston. We'll be right back. (upbeat music)