Bitdefender Completes Acquisition of Horangi Cyber Security


Products +

Services +

Customers +

Partners +

Resources +

The Cyber Defense Matrix

Sounil Yu, author of The Cyber Defense Matrix, joins host Jeremy Snyder this week to talk about his bestselling book, and what we could all learn from it. We also held our first-ever giveaway, a copy of Sounil's book. If you participated in it, tune in to find out if you've won!

About The Guest: Sounil Yu

Sounil Yu is the CISO and Head of Research at JupiterOne. 

He created the Cyber Defense Matrix and the DIE Triad, which are reshaping approaches to cybersecurity. 

He's a Board Member of the FAIR Institute; co-chairs Art into Science: A Conference on Defense; a visiting fellow at GMU Scalia Law School's National Security Institute, teaches at Yeshiva University; and advises many startups. 

Sounil previously served as the CISO-in-Residence at YL Ventures and Chief Security Scientist at Bank of America. 

Before Bank of America, he helped improve information security at several Fortune 100 companies and Federal Government agencies. 

Sounil has over 20 granted patents and was recognized as one of the most influential people in security in 2020 by Security Magazine, Influencer of the Year in 2021 by SC Awards, and one of 2021 Top 10 CISOs by Black Unicorn Awards. 

About The Host: Paul Hadjy

Paul Hadjy is co-founder and CEO of Horangi Cyber Security. 

Paul leads a team of cybersecurity specialists who create software to solve challenging cybersecurity problems. Horangi brings world-class solutions to provide clients in the Asian market with the right, actionable data to make critical cybersecurity decisions.

Prior to Horangi, Paul worked at Palantir Technologies, where he was instrumental in expanding Palantir’s footprint in the Asia Pacific. 

He worked across Singapore, Korea, and New Zealand to build Palantir's business in both the commercial and government space and grow its regional teams. 

He has over a decade of experience and expertise in Anti-Money Laundering, Insider Threats, Cyber Security, Government, and Commercial Banking. 




Welcome to another episode of the Ask A CISO podcast. My name is Jeremy Snyder. I'll be hosting today's episode.

And today we are joined by Sounil Yu. Now Sounil is a name that you probably know from the cybersecurity world, but just as a quick introduction, Sounil is the CISO and Head of Research at Jupiter One. He created the Cyber Defense Matrix and the DIE Triad, which are reshaping approaches to cybersecurity.

Sounil is a board member at the Fair Institute, co-chairs Art Into Science, a conference on defense, a visiting Fellow at the GMU Scalia Law School's National Security Institute, one of my alma maters teaches at Yeshiva University and advises many startups.

Sounil previously served as the CISO and residence at Y L Ventures and Chief Security Scientist at Bank of America. Before Bank of America, he helped improve Information Security at several Fortune 100 companies and federal government agencies. Sunil has over 20 granted patents, and was recognized as one of the most influential people in security in 2020 by Security Magazine.

Influencer of the Year in 2021 by SC Awards and one of the top 2021 Top 10 CISOs by Black Unicorn Awards.

Wow, that is quite a mouthful. Quite a track record.

Thank you so much for taking the time to join us today.


Thanks for inviting me, and that bio usually reminds me I need to cut a lot of it out.


Well, no worries.

I'm sure it's helpful for people who are joining us today to know a little bit about you and some of the great experience that you bring to this conversation. Along those lines, you know, you've spent decades in information security at this point.




And there are a lot of frameworks, compliance standards, and strategies.

What inspired you to either, I don't know if you would call this creating another one with a cyber defense matrix or maybe adapting one, but what was really the inspiration to even start that effort?


Sure. Uh, well, the inspiration is from my time at Bank of America when as the Chief Security Scientist, in case folks are wondering, what the heck does that function do?

Uh, it involves thinking six to 18 months out to forecast what are the needs that we might face, and to anticipate that, and then ultimately fill in those gaps through whatever means that we have.

So as a part of that, I had the responsibility or, or maybe the punishment of having to deal with hundreds of different security vendors that were coming to knock on Bank of America's door, trying to get a little bit of its very large budget, security budget.

And in the process, it was very difficult for me to understand what a lot of these companies did. Not just, not because I couldn't understand the technology, but rather because there were just so many. And as you may know, there's a lot of 'em that exaggerate a little bit in terms of their ...


For sure.


... capabilities.

And so trying to dissect that and to parse all the language and all the aspects of what they do. And also just to understand how do they relate to one another, and is there fundamentally a gap in the market? It's hard to do that when all you see is this massive pile of stuff and there's no organizational framework for it.

So my goal here wasn't necessarily to create a new framework, it's, it's anything. If anything, it's really to try to merge multiple things together, to take what we already have and put it into a certain context so that we could then make more sense of what we see. And so that's, that's how they, that was the original genesis of the Matrix.

What was the compelling need for it. And I think it's what I found particularly useful or, or rather a, a one test of utility, a one test of whether the framework is good or not is based on how useful it is beyond its original use case. And that's certainly something I've discovered as well.


Okay. And do you find it useful along those lines? You mentioned that, you know, vendors exaggerate, and I'm on the vendor side. I can a hundred percent say that that is true. We will all tell you that our products will solve these problems in ways that we believe them to, but don't necessarily stand the test of the real world where, you know, scenarios vary.

We can test in labs, et cetera. I tend to think that, you know, the companies I work for, we do test what we can, but you don't know every outcome. But particularly in the context of evaluating vendors, do you find that it's useful to kind of apply that Cyber Defense Matrix thinking to try to figure out where they would fit within your organization's security approach?


Yeah. Yeah. So for, first of all, for your listeners, let's, let's talk about what the Cyber Defense Matrix is.


Let's do that.


As I talk about it, it'll make more sense. So, essentially with the vendor use case problem, I relate it to shopping aisles for cybersecurity. And the shopping aisles consist of these two dimensions, things that we care about: Devices, networks, applications, data, and users. And on the other dimension, it is the five functions of the NIST cybersecurity framework. So identify, protect, detect, respond, recover.

You can think of them as nouns and verbs. So one dimension is nouns. The other dimension is verbs. And it becomes a nice framework to start organizing lots of information that we have or lots of things that we do in cybersecurity.

Now, as I mentioned, part of that could be just understanding where vendors fit, and I generally try to insist that vendors do not fit in all the boxes or many of the boxes. In fact, they generally fit only in one, maybe two of those boxes. But the claims go usually well beyond that, and using the grocery store analogy for a moment, it's like saying let's suppose you're a popsicle vendor, okay?

Well, most people would say, well, then you're probably in the frozen food aisle, right? But the vendor will claim also, well, a creative marketer may claim, well, this popsicle is also cold, so it might help with swelling. Therefore, we're also in first aid and you know, there's a wrapping of paper around it.

So we're also on paper products and it's sweet. So, you know, we should also be in the candy aisle too, right? If I found a popsicle in the paper products aisle, and tried to use that paper product to wipe up a spill, I will likely end up with a larger problem than I started with.

And while it's partly true that yes, there's paper in this product, it's not exactly what the consumer is expecting. So that's what the matrix helps us really process in a very systematic way.

Well, it also allows us to process what capabilities we have in our pantry. Or our cupboard. So we wanna understand what are the things that we have within our own environment as far as capabilities. And then if I, using the Cyber Defense Matrix, I can find other places where I might have gaps in my cupboard or my pantry, at which point then I will go out to the grocery store to go buy those products, right?

So it pairs very nicely with having an understanding of what you already have within your own environment.


Yeah, that makes a lot of sense. And you know, I've read the book, I've got a copy here, and in along the lines of that matrix, there was a couple interesting, let's say side matrices if you will, or things that I saw beyond the primary matrix as you just laid it out.

So, well, first of all, on the main matrix, the main cyber defense matrix, one of the things that I thought was interesting is you kind of also underline the matrix with what I think of as TTPs, you know, kind of techniques, procedures that people can use. And it's so funny because a lot of the times in cybersecurity, we think of those as applying to bad actors, not applying to ourselves.

But the truth is that we as organizations, we also have our tactics, and we have our technologies, and we have our procedures. And so I think it's really useful to think about, you know, kind of that spectrum as you go across the matrix for how it bleeds from one side to the other. Maybe talk for a minute about how you kind of conceived of that.


Sure. Yeah. So, I don't see it as much as TTPs as much as I see as PPT. So for those, who don't know about the matrix, it's people, process, and technology where on one end of the spectrum, specifically on the identify, protect side of the spectrum, we have a much heavier dependence on technology for performing those functions.

As we shift from identify, to protect, to detect, respond, and recover, it starts to have, we start to have a lesser dependence on technology and a greater dependence on people. Now, throughout all five functions, it appears that we have a consistent dependency on process throughout.

Now, it's a hypothesis, first of all, and with every hypothesis you want to test that to see whether or not that's actually true. And while I have a lot of anecdotal and in some cases actually empirical evidence to this effect, I think it's still being tested to see whether or not this is true.

Now, if it is true it has some significant repercussions. So first of all, it means, for example, on the function of identify, again, we should heavily depend on technology. We should depend as little as possible on people. We should have a healthy amount of process.

Well, what that means is if I'm performing a function in the identify column such as inventory, okay, then I should depend on technology to do that for me, to gather that inventory, and I think most of us really kind of understand that to be like intuitively obvious, right?

But let's consider what usually happens after an inventory. What usually happens after an inventory is either you scan that inventory for vulnerabilities, or in other cases you may wanna prioritize that vulnerability, not the vulnerabilities, but the inventory itself.

Okay? Which of these things that I've inventoried now are important to me? Let's do that for, let's say, applications. Which applications are critical? Which ones are not? Well, it turns out many organizations do that through people. They ask a whole bunch of surveys or they ask you, pull out, please fill out this form.

And that's a very people-driven activity as opposed to a technology-driven activity. So what the Matrix tells us is that's an inefficiency. We should depend a lot on technology to perform that function instead of people to perform that function of classifying what is important.

And we're, we're seeing this in, for example, the data space where you have companies emerging that help you classify information, but it seems like that capability is still lacking across the board in our industry for some of these other asset classes that we care about.


Yeah, and I actually heard another interview that you gave recently. Towards the right side of that table where we talk about the recovery function. And you point out kind of along the lines of what we were just discussing, that the recover function is almost entirely powered by people and there really is a gap of technology in that space.

Is that something that you wish you had?


I think so this is where the theory in the practice, we have to really validate whether it's correct. I'd make this assertion as you pointed out, that on the far right on recover, if it is not very technology dependent, then what about backup, and what about those things that we have to help us automatically restore, and so on, so forth.

Well, it's not clearly technology in, in the world. Are the people involved in that? And yes, while that's true, I think there are a couple other things to consider. Let's take any sort of BCDR activity. So in, in the recover stage, we've done a lot of tabletops and a lot of the tabletops usually say, Yes, press this button to restore from backup.

And voila! Done! Well, unfortunately, it's not really quite that. That's not the case for anybody who's gone through an actual business continuity disaster recovery activity. It's not as simple as it may seem to just restore from backup. There are so many different pieces that need to also be thought through by an engineer, by people who understand the business, by people who understand the applications that are being restored.

Restoring from backup isn't, isn't something that is as trivial. And actually one of the ways that I can, I, I can relate this for ourselves is: consider like you know, if you're using a Mac, for example, you have time machine. Consider what happens when you lose your laptop and you want to or actually maybe not losing a laptop, but you wanna restore back from time machine.

Now, what's, what you love to be able to do is hit go, and then it restores it all back. But I don't know about you. I actually spend a lot of time making sure what I'm recovering back is exactly where I need it again. And to ensure that, well there's a lot of craft that, you know, we oftentimes don't need anymore, but I actually spent a lot of time when I recover something to get it to a state where I actually wanted, where it works again the way I wanted it to work.

And then one other data point is there's this old paper called the Ironies of Automation, which is an academic paper that's been around for a long time that has yet to be disproven from what I can gather that basically say as we automate more, it turns out we have, we have a, we build in a greater and greater dependence on people.

Because there's a limit to the, what we can fully automate. And as we continue to automate more and more, we find that the things that we can't automate ultimately end up requiring lots of people to have to manage and govern and figure out how all those different things break. And so anyway, like I said, it's still, it's a theory.

And so far there's a lot of evidence to suggest that it's correct, but there's still counter-evidence that I have to process and figure out how to fit in.


Yeah. Fair enough. Fair enough.

There was one other matrix that I actually really appreciated in the book, and that was actually the matrix of what threat actors own, you know, what is their matrix for, you know, kind of their, the things that are in their possession. And I think it's a, it's such a great point. I mean, the matrix itself, you can examine for your own needs, but I think just the fact that it was there was what hit me because a lot of the times I think people in defense tend to focus on what they have.

What they control their defense and they don't actually think about the other side of the table. Right? So was that kind of why you wrote that or how did you even think about putting that together?


Yeah, so the reason why that came about was because I was trying to figure out where all these different capabilities fit into the matrix.

And when I came across threat intelligence, I couldn't figure it out. I couldn't figure out why it didn't have a nice fit within the matrix. In fact, actually, if anything, it seemed to fit all over the matrix. And when I see that sort of circumstance emerge, it causes me to say, Okay, something's wrong.

The model is broken. I need to figure out how to, how to fix this. And what came about with that is the realization that there's a descriptor in front of each of these different assets. And its a descriptor is really one wanted put to characterize that descriptor is to talk about it in the context of who owns that asset.

Is it an enterprise-owned device or is a threat actor-owned device? Well, if it's a threat-actor owned device, then as a defender, I'd like to know about it. I'd like to inventory it, or at least enumerate it, which is under the identify function. Now, I may not choose, or rather I don't really care to protect it, okay, so, the matrix here is seen from a defender's view of someone else's asset.

How do I deal with somebody else's asset? In this case, that which is owned by a threat actor. And fundamentally, all I wanna do is just know that it exists. I wanna know what malware they use, what application, you know, a threat actor application. I like to know what networks they're on. Botnets and whatnot. I like to know what data they have or what they're trying to steal. I like to know about the, the director themselves, the user, right, and be able to get a profile of who they are.

But I'm not gonna go beyond that from an enterprise standpoint. Or from a defender standpoint. Cuz all I need to know is just that they exist.

Now if I extend this concept further and say, well, there are other entities that also own these assets. Not just threat actors, but also my vendors, my customers, my employees. And if I were to characterize another matrix to, if I were to have another matrix that characterizes that ownership, now we start seeing places to put in things like, where do I put third party risk management or the companies that render assessments through like an outside-in scan and it turns out that now gives me a home this additional layer gives me on the home to put those things.

So anyway, it provides us extensibility without breaking the foundation of the model. It gives us extensibility to be able to help us understand how some of these other problems that we're facing, how they fit into the grand scheme of things.


Yeah. Yeah. It's interesting.

You know, last year I spent a couple months doing strategic analysis on threat intelligence as part of a role that I was in at the time. And I looked at any number of vendors in the space and their capabilities, and to your point, I think it was hard for us to understand what the ICP, the ideal customer profile of a threat intelligence customer was, and there were almost kind of two arguments that started to emerge.

You know, the only, as far as the only consistencies or the consistent patterns that we could see in the space.

One was that there's definitely a market of threat intelligence vendors selling that information to other cybersecurity vendors in terms of, you know, enhancing or enriching their products. So I think that's along the lines of the point where threat intelligence can be sprinkled really anywhere across the matrix as it applies to different technology vendors.

And the other is for, you know, very cyber mature, larger scale organizations that have big, you know, big defense teams, big cyber teams where they can really invest human resources into kind of digesting that threat intelligence. But otherwise, for me as well, it's a category I've struggled with to understand, you know, what is the right place of threat intelligence in the market?


Yeah. So there, let me unpack those two aspects real quickly. So first is, when it comes to how it fits into all these different parts of the enterprise-owned defenses, what that helps us to understand is that threat intelligence is a supporting function to help us network protect, let's say, or network detect as an example.

And, and that's the keyword. So the keyword here is it's a supporting function. It's a secondary function. Threat intelligence by itself does not protect your network. Threat intelligence by itself does not detect any intrusions, right? It pairs with some other thing.

And if that other thing doesn't exist, guess what? Threat intelligence is not gonna help you. Right?


Exactly. Yeah.


Okay. The second piece is a very fascinating aspect of organizational structure, okay? Where does threat intelligence fit in a organization that has threat intelligence as a function?

And oftentimes we find, well, actually I, I've, I've seen threat intelligence been in a lot of different parts of organization, whether it's under the SOC and in some cases under engineering. It's in various places, and I think it's because I have found that each of these layers that we talked about earlier with respect to assets owned by other entities, larger security functions have a function focused on, for example, threat intelligence.

They also have one focused on third-party risk management. They also have one focused on fraud. They also have one focused...

Anyway, there's all these different teams that have emerged that don't seem to have a really clear home within some larger enterprises. And there's a debate within many organizations around, well, how, how should that person, how should this function relate to the main part of the security organization?

Like, and a common question is like, how does security and fraud relate to one another? Well, it turns out we're struggling with the same basic pattern of you have some set of assets owned by some other entity. We believe it relates to security in some way, but we haven't figured out how to properly integrate it into security teams.

I think it turns out that the way that we integrate, for example, threat intelligence into a security team or the threat intelligence function into a security team, that pattern is a sim, is a similar pattern to how we have fit in third-party assessments. And it's a similar pattern to how we integrate fraud.

Anyway, it's something worth diving into further to investigate. But it's something that we, from an organizational structure standpoint, we've encountered many times in larger organizations. And I think this pattern matching that I'm sharing with you gives us a hint as to how do we make this organizational alignment better functioning across those different pieces.


Yeah, yeah, yeah. There's another section in the book where you talk about terminology, and I think it's actually really interesting because terminology is something that gets used and really abused. Let's say, you know, used by technologists and kind of abused by marketers is maybe a fair way to think about it.

But I think your point is that, you know, it's often terms get used interchangeably, you know, whether it's marketing, advertising, whether it's people trying to co-opt a term to mean one thing when it might technically mean another. But what do you, what are your biggest complaints here? Why did you, what kind of led you down the path of exploring this space and making the points that you make in the book about terminology?


Sure. So the main thing that led me to this path is the inherent inconsistencies that emerge if you aren't consistent in the terminology itself. So the model, the structure of the model, it's a matrix which meant, which means that if I use a certain term in one column, let's say, then it has to apply consistently across that entire column.

Likewise, if I use a certain term and, you know, in the horizontal, then I gotta use that term consistently. So the horizontals in, for those who are listening, is the asset class. So if I'm saying, for example, I wanna identify devices, well those devices have to be the same type of device when I protect those devices and when I detect. When I go into the detect function, those devices have to be the same type of device.

I can't all of a sudden change it from this type of device to a different something else or, or have a different, whole different meaning for device. And actually a good example of that would be like application. Well, if I identify applications, what do we mean by applications? Do we mean like Adobe Acrobat and, and Microsoft Word, or do we mean software code?

Okay? And I actually mean software code. So when I say identify applications, I'm looking at if I'm looking for vulnerability scanners, let's say, then I'm looking for things like SaaS and DAST and SCA and so on and so forth. Well, if I'm gonna protect those applications, I'm not now, I'm not now talking about how do I patch Adobe, okay?

So you see where that, the discrepancy shows up otherwise. And then on the function side, if I'm using the word protect, then I have to use the word protect consistently. Or if I use the word detect, I have to use it consistently. And one of the ways that I, I try to maintain that consistency is by have being this construct of left and right of boom.

Am I addressing challenges before something unexpected, undesirable happens, or am I just trying to do it afterward? And oftentimes, just that clear distinction helps me understand what part of the problem I'm dealing with or, anyway. Okay. So all that's it. You asked me like, what, what are, what were one of my frustrations that led to this.

It's actually, unfortunately the, this cybersecurity framework itself, because in this cybersecurity framework itself is actually very inconsistent in its own usage of terms. And unfortunately, that's gonna create some degree of challenges in, in our industry as a whole.

Because if the standard itself is unclear and just a simple example would be, there are many times when for ex, the word "identify" is defined using the word "detect", the word "detect" is defined using the word "identify" in the NIST cybersecurity framework. So you have those two words, which are almost being used synonymously, and yet they actually have very different distinct meanings, which gets lost because it's being used in that sort of way.


Yeah. Yeah, makes a lot of sense. I think it's really worth kind of taking some time to think about that and you know, that leads into kind of my next plan or my next question, which is really around like, okay, so you've got, you navigate that terminology, et cetera. You've got the matrix itself, and I know you and I had a previous conversation about the cyber defense matrix when you first laid it out to me, and one of the points you made to me was that we shouldn't think of the matrix as a goal of its own. And we shouldn't think of it as kind of, you know, blackout bingo where we try to check every box.

But how do you recommend that people take this and use it as a starting point for designing their defense strategies for their organization?


Sure. Yeah. So for the, those who haven't already figured it out, it is a five by-five.

And so it fits into this nice concept of, of a Bingo card. And so, yeah, our goal is not to check every box in the Bingo card. It's to understand what is the minimum set of things that you need to have to be able to declare bingo. And that declaration is also very dependent upon the nature of your business and various aspects of what you have in your environment.

And so in the book, I also talk about it in the context of the food analogy, extending the food analogy maybe too far. I, I talk about things like, you know, how do we deal with allergies and how do we deal with nutritional needs, and all these different things that we deal with in the order of food, we actually have to deal with in cybersecurity as well.

So, what are allergies? Allergies are business constraints or business impacts or things where the business will come back and say, you can't do that because it'll stop my ability to do work. Well, I, as a security person would love to remove local administrator rights from developer machines. Good luck doing that because the developers are just gonna riot and, and quit, right?

And then nutritional needs is a way to characterize the, the threats that we have to deal with: the attack surfaces and the things that may harm us, right? And so, fundamentally the cyber defense matrix is an organizing framework. It's an organizing tool that gives you a strategic view of all these different pieces that we have to struggle through, and we oftentimes struggle through them in isolation.

How do these threats and attack surfaces relate to my business impacts, which relate to the capabilities I have currently, which relate to the compliance requirements that I have. There's all these things that we have to somehow hold in our head and understand in, in this very complex fashion.

The matrix helps us organize all these very disparate things into their associated bucket, so that it reduces the amount of information you have to process to understand that problem space. I wanna just understand the data identify space, okay? Well then, I can now fit all those different things into just that, I can fit all the related things into the data identified bucket, the, the compliance requirements I had to fit, the capabilities in the market or my pantry, the threats against it, the ... whatever business impacts I might have, or exceptions I might have in that bucket.

Now, it's much easier the process than having to do this large, end by end sort of mapping to everything else in their whole, in their whole ecosystem.

Ask A Question. Win A Book.


Yeah. Yeah. Yeah. I think that's a great way to think about it.

So Sounil, we didn't tell you this in advance, but we actually decided to engage the audience and run a little book giveaway.

So I've got, you know, copies of the Cyber Defense Matrix here. One is mine and so sorry, readers and listeners, you can't have that one. But I do have copies to giveaway here. So we, we decided to get some questions from the audience and run them by you and let you pick your favorite of them and we'll, we'll give a book away to somebody from our audience.


Okay, Cool.


So, first question from the audience, and I'm sure you must have thought about this as you were writing the book. What makes this book different from the plethora of cybersecurity books out there?


Oh, wait. Am I supposed to answer and, and then figure out my favorite or ...




Okay. What makes it different?

Um, uh, well, hm...


Put you on the spot.


Yeah. Okay. So actually let's, let's talk about the plethora first. Because the plethora, a great resource is the Cybersecurity Canon. The cybersecurity Canon is something that Rick Howard and Helen Patton are helping manage and there's other, many other people involved, but, they're been the caretakers for the last couple years, and as I think through the books that are in the cybersecurity cannon, many of 'em are collections of stories from the path around here's, here's how cybersecurity has emerged as a practice or how the, the threat actors have emerged. So it's a, it's a recounting of What has been and what we should anticipate in the future.

Then there are other really great books that talk about how do we do this one particular practice better? So for example, risk management, how do we do risk management better? So I would say the one thing that this, it's, you kind of hit upon it earlier, this is establishing a basis, it's almost like a dictionary, maybe.

And that's, I don't know if that's making this sound exciting or not. No one really wants to read a dictionary. But effectively, in fact, it's a dictionary and then a guide, a follow-up guide that says, here's how to understand how to use a dictionary. It's also a map and a really quick explanation of how to use this map.

Which is not what I think I've seen anywhere in security. In a way that brings those two sort of things together. So, yeah. Anyway, it, at the end of the day, the Cyber Defense Matrix is a useful tool to understand how to think strategically about all that we see in cybersecurity and that way, I think that's why it's one, a dictionary. And then two, a map, and then just an explanation as to how to use it in that strategic way. If anyone else is seen a book that comes similar to that, I would love to hear about it cuz I'm not sure if I see one similar in the cybersecurity canon.


Yeah. Very cool. I think that's a great way to think about this book. And you know, along the lines we talked about, if you can kind of go through the matrix, figure out where it aligns to your organization and protects crown jewel assets, your most important data, et cetera, then it's a great starting point to navigate.

There's your map. Next question. How does cloud fit with the cyber defense matrix? I'm sure this must have played in your mind at least some, given the modern world that we're living in. So what do you think about cloud with the Cyber Defense Matrix? Is it a direct fit? Are there adaptations? Is it, does it map natively?


Yeah, so, that's a great question and one that I have struggled with and I continue to struggle with. So, you know, the cloud is somebody else's computer, one way to look at it, right? In which case you're saying, I'm deploying into a third party's device in a very simple, abstracted way.

You can say, I'm part and, and I'm pushing into a third-party device. And I earlier talked about the another layer for the cyber defense matrix. And so now I'm saying how do I identify my third-party devices?

Now, that's the simple definition of cloud: somebody else's computer. But as you know, there's much more to cloud today than just somebody else's computer. It, there's a whole bunch of APIs.

Well, are those APIs effectively an application in and of itself? Is AWS essentially an application that I'm trying to leverage? How do I understand how to identify, protect, detect, respond, recover to a third-party-owned application that we happen to call AWS?

So that's another way to potentially slice and dice it. Then there are tons of resources in the cloud, whether it's a VPC or an S3 bucket or, you know, storage blob or, all these different IAM roles that we have to deal with. Well, how do they manifest in the matrix? And so at the end of the day, I have found parallels to each of these different things in one instantiation.

So, for example, a compute resource, an EC2 node would be a device. A S3 bucket, of course, would be data and, you know, there's different parallels that we can put into that align to cloud-based resources. However, in some respects, again, a lot of it is really just a big application, and I'm trying to extend my controls into how do I configure this big application called AWS or GCP or Azure.

Anyway, that's a, that becomes a too large of a bucket if I think of it just that way. So I've tried to break it down into something that's a bit more, that gives me a bit more granularity. But that's said, all that's said, there is a mapping, but I think I still struggle to figure out if the mapping is useful enough?

Well, you know, all models are wrong, but some are useful. Can we adapt this model to make it useful at a strategic level? And if I can, then let's keep using the Cyber Defense Matrix. If it can't, then we should absolutely get, look at a different model, one that perhaps works more tactically at a more granular level for the cloud.


Yeah. Well, The lines of tactics are actually where the final audience question comes from. So, the question is basically there are a lot of musts that a program must have, and these are things that we talk about frequently, but most organizations have finite resources.

What are some of the most commonly discussed things that you're hearing about nowadays that in your view, most organizations can actually wait, you know, they can kind of postpone those in order to get the fundamentals down. And we didn't spend a lot of time talking about it today, but on previous podcasts, we've talked a lot about the importance of fundamentals. Things like hygiene, things like backup being super important as part of your, you know, as part of your defense strategy.

And then follow up to kind of how do we figure out if we can wait? And then when do we know that the time is right to start investing in a new technology or in a new capability?


Sure. Lots of things to unpack there. So, first is, on the musts part of it, the Cyber Defense Matrix is a double-edged sword in a particular way.

One is, if you didn't realize you had a particular problem, now you do. It's saying this matrix provides this more comprehensive view of our entire landscape of things that we have to deal with in cybersecurity. It's meant to be a broad framing perspective that helps you know there are things, there are things that you may not have been aware of previously, but now you are made aware, and because now you're aware of it, you have to make a decision on whether or not you deal with it, Okay?

So if you weren't already previously aware that there was a need for application detection and response as an example, well now you do because the matrix shows that. Now you may wonder, well, how important is that to me?

Do I, should I pay attention to that? And this also hearkens back to an old adage. I, I seem to keep buying more things but not feeling more secure. Or when is this madness gonna stop when we, when the number of things that we have to deal with slow down. Well, I, again, the unfortunate news is the Cyber Defense Matrix just reveals a whole bunch of new stuff that we might have to deal with, but it also gives us the perspective to say what's more important.

Cuz I now can see the bigger picture and say, you know what, there are things that are far more important to me in these particular boxes than all these other things. And I'm gonna make a risk management decision to say I'm gonna not worry about these because maybe I don't have a nutritional need for those things right now.

I don't have a threat or an active attack surface or things that I'm, have to be, paying attention to. But there are definitely hotspots in other places where I'm gonna focus my attention. I can't cover every aspect of the matrix. I just don't have enough resources. All right. That's, that's one way to look at it.

The other aspect of what you mentioned in terms of things like, well, what about the foundationals or basics or the hygienes or whatever, the basic hygiene kind of stuff, should I at least take care of that? And the answer is still yes. However, I oftentimes relate this notion of hygiene to a new term that I've been trying to parse through in my mind, which is distinguishing between safety and security, right?

So, hygiene is really tied to safety. And the easiest way to understand why that's the case is think about the term, food safety versus food security. When we talk about food safety, it's a lot about proper handling, hygiene, compliance, checklists.

Food security would be, where's the baby formula in the US? Or what do I do about Ukrainian and weed? Well, actually, you can't do anything about Ukrainian weed or what baby formula; you as an individual can. It's a much larger, complex ecosystem that you have to deal with. But that's it. The whole notion of hygiene is a useful or relating it to food safety is actually a useful construct because I can insist, for example, that you wipe the table clean every time a speck of dust falls on it.

Or I can say there's a minimum amount of dirt that I'm willing to allow for it to persist before I clean it up or, as long as certain contaminants are not part of this environment or within certain degree of contaminants or mixing of contaminants, I may choose to block those things off, right?

So, you know, chicken versus beef and so on and so forth. What I'm trying to articulate here is, It's okay for your, you to have a dirty prep area up to a certain point. It's okay for you to have vulnerabilities persist in your environment up to a certain point. Do you need to eradicate all those?

If you try to do that, you would never be able to prepare any food because you're always wiping down the table and understanding what that must. It's a degree of understanding what that must is. Yes. You must wipe down this. No, you don't. You, you shouldn't, you, you must not wipe it down every second of the day because you just won't get anything done.

So I think it's more of a question of degrees and how much attention you pay to it is gonna be depending upon the circumstances and the matrix just gives us a bigger picture view to understand where I'm gonna focus my attention on and have greater scrutiny of, and others where I'm gonna say, You know what?

It's okay if it only gets wiped down the floor in a restaurant. It's okay they wipe it down once a day.


Yeah, yeah, yeah. Makes a lot of sense. Well, out of those three, who's our lucky winner?


Um, well, that last question is interesting, but I think I'm gonna go with the second one because it's the one that still throws me off.

And if anything, I would love to hear from the winner, how they would map things to the cloud and. Anyway, that's ... I will pick that one.


All right, well we will get in contact with Anand who was the person who submitted that question, and we'll get a copy of the book out to Anand.

Thanks to everybody for taking the time, and Sounil, thank you so much for taking your time to join us today. I think that's a great place to end today's episode.

Sounil Yu is the author of the Cyber Defense Matrix, you can pick up a copy on or probably other bookstores as well, although Amazon is where I've found it the most easily, of course.

And Sounil, thank you so much for taking the time, first, for writing the book, and for taking the time to come on and talk about it with our audience today.


Thanks for having me.


It's been a real pleasure. We'll talk to you next time on the next episode of the Ask A CISO podcast.

Jeremy Snyder

Jeremy serves on the Horangi advisory board. Jeremy Snyder has over 20 years of experience in IT and cybersecurity, with deep industry exposure in the M&A space. Some of his previous employers include Amazon Web Services, DivvyCloud and Rapid7. Jeremy has lived in 5 countries and speaks several languages. He is currently the Founder and CEO of, a leader in API security.

Subscribe to the Horangi Newsletter.

Be the first to hear about Horangi's upcoming webinars and events, up-and-coming cyber threats, new solutions, and the future of cybersecurity from our tech experts.