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

Our guest today is Sunil Yu, the CISO and Head of Research at JupiterOne. Of course, when I think of Sunil, I think of Cyber Defense Matrix. To me, this is an amazing artifact that kind of helps our thinking about security. Sunil, welcome to the podcast.

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

Perfect. So it's a cloud security podcast, so I wanted to kind of 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?

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 2 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 5 functions of the NIST Cybersecurity Framework, so identify, protect, detect, respond, and recover. And so it provides this nice 5x5 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 we'll 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 in the cloud environment. But at the same time, it's different, just as much as we say cloud's 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.

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 2 overlap? And where do they not overlap, maybe is even more interesting. 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.

Hmm.

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're 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 it 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.

Basically, what we call the cloud that's a copy of a data center.

The lift and shift.

Yes, exactly. A lift and shift.

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 the cloudy cloud. You're doing the hosted data center.

That gets back to the conversation we had with Anna 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. 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 infrastructure with trusted deploy gates, integrity is almost taken care of for you by that. That's so fascinating.

Yeah. One of the key things we struggle with in security is what changed, right? And everything's changing all the time, which makes it super hard for us to find when something went wrong. So, the principle of immutability supports 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.

Yeah. And this comes up a lot in many conversations as kind of an ideal dream state where security is not just built in, but it's kind of like architected in before building even starts. But like, both you and me and Tim, I'm sure, would be kind of like retired, if not our children would be 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.

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

Yeah. So let's take an IAM 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 the 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?

Yeah.

And how many are we willing to absorb? So, let's take an IAM 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.

I like that. And I think that it also confirms my view that old and new would always coexist. Old and 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 would be elements that would stay like that forever. I think that, that I like that as a vision. It's actually kind of inspiring.

Well, you know, 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, okay, in the body, what cells are the longest-lived? They're your brain cells. Okay, what are the shortest-lived? Things like your skin cells. What do you call a skin cell that lives longer than it should?

That's a tumor.

A cancer, right? 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 mean, I think a lot of us would be super happy if we just got it down to 1%, let alone some microscopic percentage there.

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.

And that actually really kicks people who think that cloud is just somebody else's computer straight in the butt.

Yes.

I mean, this is really like the juiciest, crispest example about why they're wrong.

Yes.

Like, you know, I've done this survey on Twitter a few weeks ago.

It broke my heart.

And kind of 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 and where's my IP address.

Oh, God.

And it's like so head-scratching. Okay, let's switch to a more fun topic. So—

But one sec, Sunil, 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.

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.

Got it. Thank you.

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, Sunil, was, of course, the concept of resilience. Lately, I've observed a lot of people being like royally confused about what's resilience in the cyber domain. Opinions varied from it's about detection and 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 do you describe it?

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.

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

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

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

Yeah, and this is also another— so I use a couple 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 okay to feed cattle to your pets, but it's not okay to feed your pets to the cattle. So—

That's going— that's becoming really gruesome in a good way because—

Yeah, exactly right. It should evoke a, oh my God, you wouldn't want that to happen. That's not going 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? That's exactly what— and for all the companies who tried to do that and suffered the consequences of that, their pets got run over, right?

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.

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

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

These are great terms, and there are 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 principles standpoint? I think Dan Gear said it the best. He said that the best security has 2 characteristics. They're invisible and they're unavoidable.

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

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.

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

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.

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 like 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.

As a funny aside, for Sunil'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 kind of like at work operationally.

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

Now, along the lines of the notion of invisible security though, I think there are things that I've been thinking through this and would love 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 that 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, okay, 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.

I see where you're going. This is cool.

Yeah, right. Yeah, 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 there's, as you know, or as you may know, there's quite a bit of resistance on the cybersecurity review board side 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?

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

So in my Gartner days, Gartner did have a model that 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. 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.

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 in elevators and safety in airplanes and safety in food, they are actually around compliance.

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

All right. Okay. 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? I mean, think about even like, 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? Is it more safe? Okay. 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.

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/fraud space.

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

Right.

Right? Just because an airplane is compliant doesn't make it not susceptible to 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.

Yeah, 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 kind of cast aspersions on compliance and cloud security. This is fascinating.

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

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.

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

That's impressive.

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— okay, so, you know, 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 really— I still refer to frequently that has significant implications on security— there's 2. Well, okay. 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.

They're definitely security books. And you're not the first guest to recommend both of those.

Oh, you are not the first. But 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 kind of past our time, but Maybe you, Sunil, can give us one or two examples of existing antifragile systems in our domain.

That would be great.

Because we are really struggling. Save us. You're the last hope of the galaxy. Yeah.

Well, okay. 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.

Okay, 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 like, 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 like an engineering practice.

That's right.

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

Sunil, that's high praise from Anton, calling it a good answer.

That's funny.

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

Thank you for the compliment.

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

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

Oh, wow.

Oh, this is so happening. This is happening.

That's happening. Listeners, something to look forward to.

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 at Anton underscore Chuvakin and underscore Tim Pico. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.

Security.