EP67 Cyber Defense Matrix and Does Cloud Security Have to DIE to Win?

ANTON: Our guest today is Sounil Yu, the CSO and head of research at Jupiter One. Of course, when I think of Sounil, I think of Cyber Defense Matrix. To me, this is an amazing artifact that helps our thinking about security. Sounil, welcome to the podcast.

SOUNIL: Thanks for having me. It's great to be here.

ANTON: Perfect. So it's a cloud security podcast. So I wanted to explore your thinking around CDM, Cyber Defense Matrix, and how it applies to cloud security. Are things generally easier or harder? Are they different? Where are they different? Care to elaborate on this?

SOUNIL: Yeah, sure. So first of all, let me explain what the Cyber Defense Matrix is, and I think there will be links available for anyone who wants to see it. But the Cyber Defense Matrix is a simple mental model that consists of two dimensions.

On one dimension, it's things that we care about, things like devices, applications, networks, data, and users. And the other dimension is the five functions of NIST Cybersecurity Framework. So identify, protect, detect, respond, and recover.

And so it provides this nice five-by-five bingo card, effectively, that helps describe the various activities that we do in security. Now, how does it apply to cloud? Well, it's an interesting question because it requires a little bit of further explanation in terms of how we think about how we should use cloud, which will go, I think, later into the conversation.

But fundamentally, in the cloud, we have hosts, devices. We have applications, APIs, microservices, lambda functions, whatever. We have networks. We have data. And of course, we have users. And sometimes we may consider users identity, but I think actually all these types of assets have identities.

And what we want to do to each of those different types of assets is know that we have them. That's identify. Understand what sort of vulnerabilities or misconfigurations we might have. Those are the functions of identify. We want to make sure that they're protected. We want to know if something bad happens and see any exploitation against vulnerabilities. That's the detect function. Respond, and then subsequently recover from those.

So I think it applies across the board when it comes to the cloud security and the cloud environment. But at the same time, it's different. Just as much as we say cloud is different than just somebody else's computer, it's different because of the operating model when we think about the cloud. And this gets into another framework that I created called the DIE Triad.

So DIE stands for Distributed, Immutable, and Ephemeral. And I think there's a fundamental shift that happens when we think about the cloud that aligns nicely with the DIE Triad as well.

TIMOTHY: Say more about that because the cloud definitely sounds distributed. It definitely sounds like immutable infrastructure. And it's definitely ephemeral. I have lots of issues related to that. So how do those two overlap? And where do they not overlap, maybe is even more interesting?

SOUNIL: Yeah, in fact, to the notion of overlap, let me propose something that is very radical, which is this notion that the DIE Triad is actually the opposite of the CIA Triad.

TIMOTHY: Hmm.

SOUNIL: So consider that for a moment. And this is why I was saying cloud security and the Cyber Defense Matrix, in some respects, is actually at odds with each other. And the reason why they are at odds with each other is the Cyber Defense Matrix helps us understand how we should secure and protect our assets, those devices, applications, networks, data, and users, using the principles of confidentiality, integrity, and availability.

However, the DIE Triad-- Distributed, Immutable, and Ephemeral-- is arguing for building things that basically offset the need for CIA. The more ephemeral something is, the less I need to worry about confidentiality. The more immutable something is, the less I need to worry about the integrity of something. The more distributed something is, the less I need to worry about the availability of any one service.

So if I'm going to be building in the cloud, could I actually build in such a way that I have less to protect, detect, and respond to, right? And so the first question that you started off with, which is how does the Cyber Defense Matrix align with the cloud and cloud security, in some respects, I could say, well, it aligns pretty well. But I would say, if you're building it wrong in the cloud.

ANTON: Hmm. Basically, what you call the cloud that's a copy of a data center.

TIMOTHY: The lift-and-shift.

SOUNIL: Yes, exactly, a lift-and-shift.

ANTON: Yeah, lift-and-shift cloud. It goes towards the original view and away from distributed, immutable, ephemeral. So if your cloud is localized, people SSH into instances, and everything stays for days, then you're really not doing a cloud to cloud. You're doing the hosted data center.

TIMOTHY: That gets back to the conversation we had with Anne of people doing Kubernetes wrong as well. If you bring your problematic practices to a new place, you're still a miserable couple on a vacation in Hawaii. It doesn't fix your problems.

SOUNIL: [LAUGHS]

TIMOTHY: So this is really interesting, though, because this immutable and integrity thing, this gets back to the binary authorization conversation of how, if you have immutable structure with trusted deploy gates, integrity is almost taken care of for you by that. That's so fascinating.

SOUNIL: Yeah, one of the key things we struggle with in security is what changed, right? And everything is changing all the time, which makes it super hard for us to find when something went wrong. So the principle of immutability is support security, if we actually want to build things in such a way that we have to apply some security principle to it.

But ultimately, yeah, if we build things to be more DIE-like, which happens to align nicely with how you should really build things in the cloud to begin with, then the job of security is actually much easier, in fact, to the point where, again, we offset the need for security because we've built things that ultimately don't require security at all.

ANTON: Yeah, and this comes up a lot in many conversations as an ideal dream state where security is not just built in, but it's architected in before building even starts. But both you and me and Tim, I'm sure, would be retired, if not our children would be retired, by the time that state is achieved, right?

SOUNIL: Yeah, so just as much as we don't have perfect CIA, we don't have perfect security, we won't also have perfect DIE either. But the goal here is, should I take a step towards-- let's again suppose that they are at diametric opposite ends. Should I try to secure everything first? Or should I try to build towards DIE first? And my argument is, you could try to build towards DIE first, and, failing that, you then have to secure whatever you can't DIE.

TIMOTHY: So there are definitely parts of cloud in practice, though, that you can't have be ephemeral or distributed or immutable, things like an IM policy. So there's still places where you need to have integrity and confidentiality in your cloud, right?

SOUNIL: Yeah, so let's take an IM policy but one that you can grant in a just-in-time sort of fashion. So first of all, not everything can be DIE, absolutely. In the cloud native world, we use the analogy of pets and cattle. So pets you have to CIA. Cattle you design to DIE.

We're always going to have pets, no doubt about it. Every organization has some number of pets. The question is, how many do we want, and how many are we willing to absorb? So let's take an IM policy. Let's consider that to be a pet, sure. But we can still do things around it that make it more just-in-time, more ephemeral, more-- things that enable us to still adhere to some of those principles of DIE.

ANTON: I like that, and I think that it also confirms my view that all the new would always co-exist. All the new would always coexist. It's just the percentage would change. Today, we may be a little bit DIE and a lot CIA. But in the future, we may be built to these standards, but there will be elements that would stay like that forever. I like that as a vision. It's actually kind of inspiring.

SOUNIL: Well, a great template to follow is a biological system. One of the parameters of the DIE triad is the ephemerality, which is really easy to measure. Ephemerality is how long lived something might be. And we can say, OK, in the body, what cells are the longest lived? They're your brain cells. What are the shortest lived? Things like your skin cells. What do you call a skin cell that lives longer than it should?

TIMOTHY: That's a tumor.

SOUNIL: A cancer, right? So now, what is the percentage of long-lived cells to short-lived cells? Well, it turns out it's actually-- it's like 0.0001%. So could we have in our corporate environments the distribution of assets between pets and cattle be something as small as 0.0001%? I think a lot of us would be super happy if we just got it down to 1%, let alone some microscopic percentage there.

TIMOTHY: This is such an awesome and compelling example of how cloud is so fundamentally different. You could never do this on prem. You can't have laptops that get rebuilt every day from scratch.

ANTON: And that actually really kicks people who think that cloud is just somebody else's computer straight in the butt. This is really the juiciest, crispest example about why they're wrong.

TIMOTHY: Yes.

ANTON: I've done this survey on Twitter a few weeks ago--

TIMOTHY: It broke my heart.

ANTON: --and the majority was voting for, yeah, cloud is just somebody else's computer. And to me, this was kind of depressing because this means my fellow security professionals pretty much still think in terms of servers and locations, in other words, my IP address.

TIMOTHY: Oh god.

ANTON: And it's so head scratching. OK, let's switch to a more fun topic.

TIMOTHY: But one sec, Sounil, you said cattle and pets. We have a lot of listeners who join the show who don't know a lot about security. Could you real briefly explain what you meant by cattle and pets? I just want to make sure we don't lose anybody on that.

SOUNIL: Yeah, so conceptually, pets are things you care about. You can give a name to a pet. You know it by name. When it gets sick, you take it to the vet. You like giving it hugs. So again, we have a machine or some application even or some service, and we can name it by a name. When it has a vulnerability, we go patch it. Those are pets. They're your legacy systems, things that are long lived.

Cattle, on the other hand, are branded with some obscure string of characters that you can't even pronounce. And when it gets sick, well, you cull it from the herd, and you move on. And the more DIE-like something is, the more cattle like it is. The more CIA something is, the more pet-like it tends to be.

TIMOTHY: Got it. Thank you.

ANTON: And we will have a link to a definitional reference. It's a classic modern ops concept, I guess, that we should really remind people of. Yeah, that makes sense.

So another concept that you mentioned a few times, Sounil, was of course the concept of resilience. And lately I've observed a lot of people being royally confused about what's resilience in the cyber domain. Opinions varied from it's about detection response. It's about recovery. It's about just the same as cybersecurity.

So given that you are doing a lot of very crisp thinking in security concepts, how do you define cyber resilience? How do you define it, and how would you describe it?

SOUNIL: Yeah, so this is also another area where I'm going to offer a somewhat radical view, which is that we oftentimes conflate security and resilience together, that we can be more resilient by being more secure. And I'm actually offering the opposite, which is, if you build systems to be more DIE, you're going to be more resilient. And as I mentioned earlier, DIE is the opposite or is offsetting the need for security.

So if I have more cattle instead of pets, I will actually be more resilient. The fewer pets I have, the quicker I can bounce back from any sort of potential damage. Now, of course, I will have one pet that I need to put a lot of energy into securing. But you roll the dice and something gets hit, more than likely you're going to hit a cattle. And even if you hit many cattle, I'm going to be able to bounce back from that really quickly. I'm going to be able to bounce back from that really quickly and recover.

So this whole notion of resiliency as a concept, which today a lot of people, again, conflate with security, I think is causing us to say, well, to be more resilient, we need more protect, detect, and respond. Whereas, I'm arguing, no, actually, to be more resilient, you need to design systems so that they don't even need protect, detect, and respond.

ANTON: But that means that cloud is inherently much more resilient, right?

SOUNIL: If you use it the right way. If you're building systems in the cloud that adhere to the principles of DIE, then yes, you get resiliency along with it. But if it is a lift-and-shift model, then no, you don't.

TIMOTHY: So you have to do it right for cloud to matter.

SOUNIL: Yeah, and this is also another-- sorry, I use a couple of analogies here. So I have this adage, which is pets on prem, cattle on the cloud. Pets on prem, cattle on the cloud. And also, it's OK to feed cattle to your pets, but it's not OK to feed your pets to the cattle.

TIMOTHY: [SNORTS]

ANTON: [LAUGHS] that's going-- that's becoming really gruesome in a good way because--

TIMOTHY: Yeah.

SOUNIL: Exactly, right. It should evoke a oh my god. You wouldn't want that to happen, of course, right? But what is a lift-and-shift model except it's putting your pets and giving it to the cattle, right?

ANTON: That's right, yeah.

TIMOTHY: That's exactly what-- and for all the companies who try to do that and suffer the consequences of that, their pets got run over, right?

TIMOTHY: Their pets got run over. Oh, gosh. All right, I want to shift gears and get us away from, hopefully, this analogy and maybe to one that's better. I'd be surprised if we found one that's worse. What's invisible security? Is that a thing? I hear a lot about invisible security. Can we have invisible security? I'd like something invisible after these altogether too visible pet analogies.

ANTON: But you'll probably hear about it from your boss's boss's boss team, right?

TIMOTHY: Actually, from them, I hear about autonomic security, Anton, and I'm still trying to figure out what that might be.

SOUNIL: These are great terms, and they're biological examples for autonomic, which I think is worth thinking through. And when it comes to invisible security, I also, in all these cases, whether it's the DIE Triad, the Cyber Defense Matrix, which I compare to food all the time-- there's ways to understand these concepts by relating them to other physical examples that we see in the real world.

So first of all, invisible security, what do we mean by that? What is it that we are trying to achieve from a first principle standpoint? I think Dan Geer said it the best. He said that the best security has two characteristics. They're invisible, and they're unavoidable.

TIMOTHY: It's obvious why unavoidable is good. Why is invisible good?

SOUNIL: So that it doesn't create a business impact, or the business isn't encumbered by it. At the same time, it's unavoidable because the business can't but adhere to whatever security provisions that we have in place. So ultimately, something that doesn't hinder the business but also ensures that the business remains secure.

ANTON: So invisible is the far edge case of easy. It's so easy you don't even see it. I see the spectrum, easy, even easier, even easier, invisible, right? That's what you're talking about.

SOUNIL: Yeah, I guess easy is-- well, I guess easy or unencumbered. I don't know if there's necessarily-- they're not exactly the same thing, but that's one way to look at it.

TIMOTHY: Unencumbering is pretty interesting, and this is reminding me a lot of some of the stuff I've done to build threat detection in cloud. I almost never talk about my stuff on the show. But when I think about what makes VMTD so cool, it's exactly those things. You can't avoid it if your security team has turned it on, and it has no impact to what you're doing with your workload. It really fits that bill, and I love that.

ANTON: As a final aside, for Sounil's benefit, it was a technology that basically was just killing crypto miners. Somebody was trying to run crypto miners in a honeypot, and GCP and crypto miners kept dying. And they were like, why are my crypto miners dying?

And it turns out that, actually, VMTD was killing them because it's a system that inherently blocks and destroys certain types of badness without any interaction, without any impact on anything. So it was really fascinating. And it's a great example of invisible security at work operationally.

TIMOTHY: Yeah, we baked security into the hypervisor that underpins all of the GC instances in the fleet. And if you're in one of the reputation tiers where we have the legal authorization scan you, we protect the system against malicious activity.

SOUNIL: Now, along the lines of the notion of invisible security, though, I think there are things that-- I've been thinking to this-- and we'll have to just quickly talk about this as part of the podcast-- but this notion of we have invisible security. Unfortunately, many of the things that we do is visible, unfortunately. A great example is TSA. TSA is probably not the epitome of really great security. It's quite visible and, unfortunately, somewhat avoidable.

But that said, there are things that I think we do in the name of security that we actually want to make visible, which makes me wonder, is that actually security? And I would say, one of the things that I've been trying to think through is we've bandied this term safety and security together and have equated them to be synonymous.

But I think, when it comes to safety, we actually want those things to be visible. We want safety mechanisms to be known, for people to be cognizant that there is-- that this elevator that you're riding has been inspected by somebody, that the restaurant that you're going to, the health inspectors have come in and checked it out, that the airplane that you're about to go into-- that there's some entity that's going around and making sure that the safety of that airplane is being taken care of.

And so we want those to be as-- we want them to be visible. Not everyone may necessarily care to look at those certificates, but nonetheless, we will generally ask for them. Or we will have the expectation that they're there. And a lot of this is done in the name of transparency as well. We want to be transparent when it comes to safety. However, what about security, right?

Let's go back to this notion of if we want security to be invisible, if that is actually a goal-- which I think is actually a good goal-- there are things that we do in safety that we don't actually want to make invisible. We want to make visible.

So there's this distinction that I want to create here between things that we choose and want to make visible, things that we actually want to make invisible. We don't really understand the concept of security and safety in cyber. We conflate them together. But could that actually be a distinguishing concept? Let me walk through another quick example.

We have the Cybersecurity Review Board, Cybersecurity Review Board, and it was modeled after the National Safety Transportation Review Board.

TIMOTHY: Ah, I see where you're going. This is cool.

ANTON: Yeah.

SOUNIL: Right.

ANTON: Yeah.

SOUNIL: One, we absolutely want the results of them to be quite public. In fact, they want them to make the safety findings to be public and adopted everywhere. But as you know, or as you may know, there's quite a bit of resistance on the Cybersecurity Review Board, sorry to say. Hey, let me tell you all the security incidents and issues that we've come up with, right?

Anyway, I think the naming of the boards is important, and I think we've started to make it more confusing in terms of, what do we really mean by safety and security? But could we actually use the principle of how much we want to make something visible be a distinguishing characteristic between the two?

TIMOTHY: That's fascinating. I love this. I'm just sitting here feeling amazed by this distinction that I'd never considered but is so interesting to think about.

ANTON: So in my Gartner days, Gartner did have a model that kind of enhanced CIA confidentiality, enhanced integrity, and availability with privacy, safety, and reliability. We called it internally CIA PSR. But safety was always understood to be very, obviously, very different from security because safety was about, guess what? People dying.

TIMOTHY: Right.

ANTON: Health and safety. It was literally safety from a dictionary. So I don't really understand what's cyber safety, if it's not about, frankly, people being harmed.

SOUNIL: Yeah, this is where it gets really interesting and confusing because we're locked into our models of thinking around what security is. And when we think about safety and elevators, and safety and airplanes, and safety and food, they are actually around compliance.

TIMOTHY: Ah, that's what I was going to bring up next. I'm glad you did it for me.

SOUNIL: All right, OK, we in cybersecurity think of compliance as a security thing, not a safety thing. But could it actually be a safety thing? Could it be more safety? Think about even, for example, SOC 2. What do we do in SOC 2 or SOC 3, which is we present a certificate of some sort saying that we are cyber secure. But is it really actually secure, or is it more safe?

And again, because we're trying to make it visible, if we were trying to make something more visible, then does it actually lean more towards safety than security? Again, just a concept to think through.

TIMOTHY: No, I love this. So what you just said there, we think about compliance as security. I actually don't. I think compliance is often-- and this comes from my days doing fraud and trying to explain fraud at a payments company to payments incumbents. I often thought of compliance as counterproductive to security. But I clearly see how it's productive towards safety. And so this distinction actually helps me feel a lot better about compliance in the computer security slash fraud space.

SOUNIL: Yeah, and a lot of us say, just because you're compliant doesn't make you secure.

TIMOTHY: Right.

SOUNIL: Right? Just because an airplane is compliant doesn't make it not susceptible to a hijack. So it's a different mindset of how we think about, what are we trying to achieve when it comes to safety? And if compliance is really more of a safety argument, it makes sense why compliance doesn't equal security.

TIMOTHY: Yeah, yeah, although, I want to be fair to my friends in compliance and say, airplanes fall out of the sky way less often than computer systems get hacked. So they must be doing something right, even if we can cast aspersions on compliance and cloud security. This is fascinating.

SOUNIL: Food for thought.

ANTON: So we are getting close to the time, and I think it's time to start thinking about our closing questions, Tim.

TIMOTHY: Yeah, I think that's fair. I'm just sitting here. Listeners, I'm gobsmacked. My face is just-- so much thought is happening, I can barely speak. So I want to wrap up and ask our traditional closing questions, recommended reading and then one weird tip for our audience.

SOUNIL: OK, recommended reading. So I love reading books. I'm generally tracking at one book a week.

TIMOTHY: That's impressive.

SOUNIL: Yeah, and well, it's great, right? It's an investment in yourself. What's the best investment? It's yourself, right? So reading books is certainly one of those. I would say for-- OK, so I wrote a book, so just in a very self-serving fashion, I'll say, hey, "Cyber Defense Matrix." You can find the book on Amazon. Check it out.

My company and I, we just released a report called The State of Cyber Assets Report. So check that out if you want. Outside of books that I have direct input into, I think the one book that I still refer to frequently that has significant implications on security-- there's two. Well, anyway, one is "Antifragile" by Nassim Taleb. And it was actually after having read "Antifragile" that I came up with the DIE Triad. So that was a real inspiration behind it.

A second, very close second, if not really equivalent to that, is "Thinking, Fast and Slow" by Daniel Kahneman. Both have extremely valuable insights for security. So they may not seem like security, but they're extremely valuable from a security standpoint.

TIMOTHY: They're definitely security books, and you're not the first guest to recommend both of those.

ANTON: Yeah, not the first. And do you remember who we grilled about examples for antifragile security systems deployed today? That's a really hard one, and I know we are past our time. But maybe you, Sounil, can give us one or two examples of existing antifragile systems in our domain.

TIMOTHY: That would be great.

ANTON: Because we were really struggling. Save us. You are the last hope of the galaxy.

TIMOTHY: [LAUGHS]

SOUNIL: Yeah, well, OK, so I actually make the argument that building something to be DIE doesn't make it antifragile. Hammering a DIE system to find those elements of a DIE system that has more pet-like elements of it and getting rid of those pets makes it more antifragile.

So this hammering is oftentimes known as chaos engineering. So applying chaos engineering to a system that you believe to already be DIE so that you can find those elements that are not DIE makes it more antifragile.

TIMOTHY: OK, I would accept that, if we drive our systems to be DIE in that they self-deploy and self-heal and auto-scale, chaos engineering is a reasonable way of identifying the parts that don't do that. That's I think the closest to an antifragile thing we've heard yet. But I wouldn't say that's a security system. I'd say that's an engineering practice.

SOUNIL: That's right.

ANTON: But there's a book on using chaos eng for security, which I'm going to add to resources. So there may be that we are actually getting a good answer, not just the best possible answer.

TIMOTHY: Sounil, that's high praise from Anton, calling it a good answer.

SOUNIL: [LAUGHS]

ANTON: [LAUGHS]

SOUNIL: That's funny.

TIMOTHY: Sometimes I have to be the occasional Russian translator here. That was quite a compliment.

SOUNIL: [LAUGHS] Thank you for the compliment.

TIMOTHY: Well, Sounil, this has been a terrifically fun episode. I'm so glad we were all able to get on to this call today and make it happen. Thank you for joining us.

SOUNIL: I appreciate having that opportunity. And if you want to be back, I'm happy to talk about autonomic security at some point too.

TIMOTHY: Oh, wow.

ANTON: Oh, this is so happening. This is happening.

TIMOTHY: That's happening. Well, listeners, something to look forward to.

ANTON: And now we are at time. Thank you very much for listening and, of course, for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts.

Also you can find us at our website cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes.

You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter @Anton_Chuvakin and _TimPeacock. Tweet at us, email us, argue with us, and if you like or hate what you hear, we can invite you to the next episode. See you on the next "Cloud Security" podcast episode.

[MUSIC PLAYING]

PERSON: [INAUDIBLE] running.