DIE - A New paradigm for Cybersecurity [ML B-Side]

Transcription edited by Dick Curtis

[Ran Levi] Hi and welcome to Cybereason’s Malicious Life B-Sides, I’m Ran Levi.

Today we’ve got an especially interesting B-Side interview for you. Why is it especially interesting? Because it’s not every day that we have a guest who’s suggesting a new paradigm for cyber security. 

A paradigm is a set of ideas or thought patterns, a particular way of thinking with which we approach a problem. Consequently, it also determines the tools we’ll use to solve that problem. A great example would be 19th century physics, in which Newtonian physics was seen as the be-all-end-all explanation to all possible physical phenomena. A famous statement, usually attributed to William Thompson, better known as Lord Kelvin, is quote, “there is nothing new to be discovered in physics now. All that remains is more and more precise measurement.” But of course, there were quite a few physical phenomena that Newton’s laws could not explain, and it was only after Albert Einstein came up with his theory of relativity and physics as a whole underwent a paradigm shift that these phenomena could be truly explained.

This does not mean, of course, that every new paradigm is necessarily correct, far from it even, but at the very least, new paradigms, even when they turn out to be wrong, challenge our existing set of beliefs and assumptions and force us to re-evaluate our thought patterns.

Our guest today is Sounil Yu, CISO and head of research at Jupiter One and previously chief security scientist at Bank of America. Sounil spoke with Nate Nelson about a new framework for designing secure systems, a framework he calls D.I.E., acronym for Distributed, Immutable and Ephemeral. Sounil asks us to treat our precious data less like pets and more like cattle. Sounds confusing? New paradigms always are.

Enjoy the interview.

—–

[Nate Nelson] So cybersecurity is in a kind of state right now, right? SolarWinds, Colonial Pipeline, Log4j, yada, yada. Major attacks that seem like they maybe once occurred every decade or every year are coming on kind of a monthly basis now, and we don’t have any great answers for them either. Sounil, how did we get to this place? 

[Sounil Yu] Well, the type of attacks that you’re referring to are actually supply chain attacks, or at least a class of attacks that you mentioned are supply chain attacks. And I actually don’t think that those supply chain attacks are a problem. Now, you may wonder, are you crazy? Of course, they create all these challenges for us. But it’s not a problem because I think it’s actually a predicament. 

[Nate Nelson] What’s the difference? 

[Sounil Yu] Well, a problem is something that we can solve. There is a solution. The solution may not be simple. It may require a complicated set of steps. But we know how to address a problem because there is a corresponding solution.However, a predicament is something that we can only manage. A predicament isn’t something that we can directly solve because there’s so many interconnecting parts to the nature of the challenge, so many  interdependencies that unwinding it is a very complex endeavor.

So when I look at where are we today and how do we get ourselves out, well, there are fundamental forces at work here that make it very difficult for us to approach this as a problem. If we look at it as a predicament and say, look, we’re in the situation that we’re in today and at best, we can only manage the risks associated with it, then it actually provides a different way of thinking about this particular challenge. There’s only so much we can do to address the flaws that we see in a vendor product like SolarWinds. We’re never actually going to solve the problem because it’s not a problem to be solved until supply chain and how we do business today with this very diverse supply chain that many of us depend upon until that model of business goes away, which it probably won’t go away for some time.

[Nate Nelson] All right. Then we have this predicament. We are not going to stop running society and living the way that we live. So how do we even begin to start addressing this whole thing? 

[Sounil Yu] So let me actually go back real quickly and just give you a perspective of the predicaments that we faced.

So let’s go back to the 1980s when IT became really cheap. Businesses started buying tons of hardware and computers to run their business functions. The first predicament that we ran into was just understanding what did we just buy and what business function does technology support? Well, over time, over the course of really many years, we ended up with a solution to that and the solution manifested as a set of products that helped us do things like asset management and asset discovery and so on and so forth.

Let’s fast forward 10 more years to the next decade. In the 1990s, we encountered another predicament, which was that we had attackers take advantage of this equipment and this technology and they sent us, I love you messages and walked into our networks and took advantage of our insecure configurations to compromise many of the systems that we had. So again, it took time for the market to develop and eventually address this predicament and produce a set of products that allowed us to approach this as a problem and the type of solutions that we saw would be things like antivirus, firewalls and whatnot.

Fast forward 10 more years and what we saw was just we’re getting flooded with all these alerts. We believed that there were intrusions, but we had trouble finding those intrusions. So yet again, another predicament. Fast forward the clock and we eventually end up with solutions that look like IDSs and SIM products out there. The next decade, the 2010s, we end up with yet another predicament, which is where it seems like we’re compromised everywhere and we need solutions to help us quickly address and respond to those particular intrusions.

So yet another predicament and after time, after we understand some best practices and techniques and paths that we can follow, we end up with solutions like EDR and NDR and other tools that help us put out these fires that we’re facing on a regular basis. What I find interesting in these decades, in these eras, is that each of the decades, the 80s, the 90s, the 2000s, 2010s, each of those eras actually maps interestingly to the NIST Cybersecurity Framework.

[Nate Nelson] So for listeners unfamiliar, five functions, NIST framework, Identify, Protect, Detect, Respond, Recover. 

[Sounil Yu] So the 1980s, we had an identify problem. The 1990s, we had a protect problem. The 2000s, we had a detect problem. In the 2010s, we had a respond problem. So what do you think is next in the 2020s? 

[Nate Nelson] I assume you’re leading me to a Recover, step five.

[Sounil Yu] So the 2020s is I think going to be the age of recover where we’re going to face recover oriented predicaments. I think we’re already facing that today in the form of ransomware. We see ransomware being fairly pervasive as an attack mechanism. And fundamentally, ransomware is a recover oriented challenge that undermines really all the other solutions or the products that we’ve bought in the past. More antivirus isn’t going to help. More SIMs aren’t going to help. More EDR doesn’t help. 

[Nate Nelson] But what’s the implication here? Are you suggesting that we give up on the identifying and detecting and protecting or that they just don’t go far enough? 

[Sounil Yu] Right. I think there’s only so far that can go. There’s only so much emphasis that we should put on the approach of protecting, detecting, and responding to security issues. So some of this can be captured or codified in the notion of shifting left. Other people have talked about building security in. There’s all these concepts that we are pretty familiar with in terms of how do we avoidsecurity issues. But I would actually take a slightly different step back and say, how do we start building systems so that they don’t need security at all?

Now consider that for a moment. When we think about things that don’t need security at all, then what purpose is there in protecting that asset? 

[Nate Nelson] Yeah, but how could our assets not need security? 

[Sounil Yu] Well, maybe I don’t care about that answer. Maybe that asset has so little value or it’s such a limited time bound value that spending time to secure that asset just really doesn’t make any sense. 

[Nate Nelson] That sounds fine in theory to me, but I’m thinking about my most sensitive personal information. I‘m thinking about financial institutions, critical infrastructure. How can we begin to talk about any of this like it doesn’t need stringent security? 

[Sounil Yu] Yeah, so this is where we have to really rethink how we build systems or what sort of principles we want to abide by. So this is also where the whole movement towards cloud native, I think, is very, it helps us take advantage of some of these concepts. One of the key principles or one of the analogies that we oftentimes hear in the cloud native world is this difference between pets and cattle. So pets are things that we give it a name. When it gets sick, you take it to the vet. You like giving it hugs. Pets are things like, for example, that server under your desk. It’s your social security number. It’s those things that are long lived. Things that you are compelled to have to secure because, well, it’s a pet. On the other hand, you have this notion of cattle, and cattle are things that you brand it with some name you can’t even pronounce. And when it gets sick, well, you shoot it and you move on. And in the world of cloud native, we want to build, we build towards this model wheremore and more of the things that we build are more cattle-like and less pet-like.

Here and also when we think about the principles that we try to adhere to, I also like to use the CIA triad and a new triad that I created called D.I.E. 

[Nate Nelson] And these acronyms stand for what? 

[Sounil Yu] So CIA is Confidentiality, Integrity, and Availability. And when it comes to our pets, what we want to do is to maintain the confidentiality, integrity, and availability of our pets. Right? Makes sense. We want to secure our pets. However, when it comes to our cattle, we want to build them to be distributed, immutable, ephemeral, or D.I.E. And if I build towards D.I.E., then I offset my need for CIA. So in other words, if I can have something that’s, let’s say, more distributed, then why do I care about the availability of any one particular asset? If something is immutable, meaning unchanging, then do I need to care about the integrity of that asset?

And lastly, if something is highly ephemeral, very short-lived, let’s say, for example, like a one-time token, one-time passcode, it only lives for 30 seconds, how much do I need to worry about the confidentiality of that code? I don’t. Right? It’s only those things that are long-lived for which I need to make sure that I maintain the confidentiality of, let’s say, my social security number, which is as long-lived as I would be. Right? So this principle of D.I.E. and starting the design towards D.I.E. is how we can think differently about where to go in the future.

[Nate Nelson] You know, I could be on board with a lot of this, right? Distributed computing, not necessarily new, immutable, makes total sense. But right there, you just went from one-time 30-second codes to your social security number, which is what I keep thinking about. And that E part, right? How can a social security number ever be ephemeral in any respect?

[Sounil Yu] So once you have a social security number, once you have a piece of data, or we can call it data pets, for that matter, you really can’t get rid of them, right? They become effectively an encumbrance for you or for your organization, which is why I think we need to think about how do we not create new pets and add to that encumbrance? You know, that’s something that we want to think about in terms of, let’s say, pet control versus the standard security job of being a veterinarian, okay? Most of the security jobs that we can think of are more veterinarian-like. What can we do to instead be more like a pet control officer? Now for the data that we have, or at least the data that we think we want to design to be more cattle-like versus pet-like, there are actually a lot of new design patterns that we can start looking towards that help us avoid creating new data pets.

[Nate Nelson] And as an example? 

[Sounil Yu] So think about what privacy is trying to do. Privacy is trying to make information about you and, let’s say, make it very ephemeral, okay? Because if you send information to a marketer or if you, on your iPhone, associate to a Wi-Fi hotspot, what hapens is that you want to have that association be as ephemeral as possible so that you maintain control over what the receiving entity knows about you. And that can be something as simple as changing your MAC address on the Wi-Fi network card on your phone so that it changes every time and thus makes it really hard for someone on the receiving end to be able to associate these two connections, let’s say, to the same device. Or it could be, for example, your email address. So instead of your email address as a pet, which is your personal email address, whatever that might be, you instead have a bunch of disposable email addresses. Those email addresses become essentially the equivalent of cattle-like PII. 

[Nate Nelson] So we’re conceding that certain information is simply going to be pets, but the means by which an unwanted actor would otherwise get to them is the part that we’re trying to make ephemeral. 

[Sounil Yu] That’s right. So we will need to make some transformation, but it allows us to create a layer where we’re happy to expose all this ephemeral data because no one, I mean, if it gets compromised, who cares, right? And if it does get compromised, you kind of want to know, but it doesn’t really matter. You don’t care to do anything to secure that data. You just need to know that someone accessed it or someone did something that then gives you a hint that something is amiss, right? But that serves as a layer or a boundary that layer of data cattle becomes a layer that helps shield the rest of your more valuable assets. 

[Nate Nelson] Okay. So you already mentioned some privacy technologies. Are there any other technologies that we have available today that are pretty good at DIE already?

[Sounil Yu] Yeah. So on the data side, I mentioned the privacy. Actually, it’s kind of funny. It’s called privacy enhancing technologies, which has the acronym PET, but some of the privacy enhancing technologies will include, let’s say, multi-party computation or homomorphic encryption or trusted execution environments. These are all terms that may be either familiar or entirely unfamiliar to your audience. But when you hear those, you can essentially think of them as things that enable you to build systems to be more like data cattle instead of data pets.

I’ll give you a quick example of one with multi-party, secure multi-party computation, which is, let’s say I want to give you a loan. Okay. Well, if I’m asking you details about your life, a lot of those details are really only necessary for a decision around, do you have enough collateral for me to give you a loan of a certain size? Once I know that sufficient amount of information, I can toss the rest of it out and just say, here’s your loan or here’s a decision on whether you’re approved or not. Do I really need to have the burden of capturing all that data and storing it and having to protect that? Or can I use something like secure multi-party computation such that all that information resides with you and never leaves your environment and all you get, all I get is a  athematically verifiable number that tells me that everything that you put in on your side is valid and correct. Okay. And if that is, then all I need is that mathematical computation and we never have to ever exchange data pets in order for that transaction to occur. That’s using data as an example. 

Let me give you an example using other forms of technology. So serverless technology. Serverless technology is a great example because it’s a highly ephemeral type of resource. It’s also a very immutable. You basically push code and that serverless function runs in the cloud. And then also it’s very distributed. You can run these serverless functions wherever because of the fact that really can operate in this serverless context, you can run it in many different places and run it at scale. So serverless functions is actually a really good example of something that is D, I, and E. Okay. There are other things that are only D and I or D and E and so on and so forth. But the basic idea is that we want to find more of these design patterns that are distributed immutable and or ephemeral, ideally all three. But if you can get two out of the three, great. 

[Nate Nelson] Are you saying that two out of three is enough?

[Sounil Yu] Where you fall short. Okay. Let’s say I can’t make something as ephemeral as I like. Well, at that point, yes, we didn’t have a burden to have to essentially worry about the confidentiality, something that will live longer than it should or live longer than maybe we would like to. 

[Nate Nelson] So we mentioned some of the technologies that can get you towards achieving D.I.E. Are there any kind of industries or sectors or parts of the world that are doing D.I.E. already pretty well right now?

[Sounil Yu] One of those is I kind of mentioned at the beginning, which is this notion of cloud native. The cloud itself leans well towards building things that are D.I.E. There’s a lot of services that AWS, Azure, GCP offer that essentially map nicely to the D.I.E. principles. So for example, they have elastic load balancing or they have cloud front, which helps with the distributed aspect of things. We have things like cloud formation in AWS that makes things immutable. And I mentioned earlier AWS Lambda or serverless functions that makes things very ephemeral. That’s cloud infrastructure.

So let me offer another example. I’ll pick a buzzword that I’m sure many people are familiar with, which is blockchain. Why is blockchain so fascinating? Well, it actually embodies two aspects of the D.I.E. triad. It’s distributed and it’s immutable. It’s not very ephemeral. Okay. So we have to be very cautious about any, for example, if you have a smart contract and you’re committed to the blockchain, to like the Ethereum blockchain, you still got to make sure that you’re not putting confidential information into this smart contract. There’s other security issues that arise from putting something like a smart contract into a blockchain. So you still have to worry about the elements of D.I.E. that you can’t do, but you at least have covered the distributed and immutable piece.

Another example would be Docker containers. So Docker containers are immutable and ephemeral. You can deploy them to be distributed, but not necessarily by default, but they are designed to be immutable and to be ephemeral. You should, for example, instead of editing or modifying a Docker container, you should rebuild it, right? And start it over from scratch. And because you can do that, you can, in theory, make them very ephemeral.

[Nate Nelson] My last question, Sounil, is this, you know, you’re proposing a fundamentally different way of thinking about security. It’s a bit radical. Maybe some folks will like it. Maybe some won’t. Are you suggesting that this DIE approach would add to our existing CIA security? Or are you suggesting that the kind of security today will be rendered redundant, irrelevant if we can achieve the kind of security that you’re talking about? 

[Sounil Yu] I think the answer to that is using the same kind of concept that we have around security itself. We can’t have perfect security. We can’t have perfect CIA. So likewise, if you consider D.I.E. to be on the other end of the spectrum, I don’t think we can ever achieve perfect D.I.E. either. And there are places where we’re going to fall short in being able to adhere to the principles of D, I, and E, and where we fall short, I think we’re going to have to fall back on elements of CIA. And when we think about what we need to do for CIA, that is more of the protect, detect, and respond. We still need to secure that asset when we can’t sufficiently do enough of the D.I.E. that we would want to.

But this is really also part of a different mindset. We oftentimes say we want security first. We want people to think about security first and to have that sort of mindset. I would argue, and this may be quite controversial for some of your listeners, let’s actually take a DIE first approach and say, what can we do to make it more DIE first? And failing that, then we resort to having to CIA something. So as much as we practitioners want people to take a security mindset first, I would say, what can we do to design these systems so that they don’t need security at all?