So now the D.I.E. or DIE Triad may sound like a murderous gang of some kind, a crime syndicate, but in this context I'm sure you'll be pleased to know it's, I've discovered that it is a cyber security framework that's aimed at enhancing cyber resilience which is what we're talking about and here to tell us more about it is literally the man who wrote the book. Please welcome Chief AI Safety Officer at Knostic, Sounil Yu. Thanks very much. So I think the words, the word D.I.E.
means something completely different in German so you'll have to pardon me for using the word here or appropriating a German word and putting a new meaning to it. Now this presentation from Alina was wonderful. It's almost like we should actually reverse order here because what I'm going to share with you is a way of thinking about resiliency that matches really closely to what a lot of what Alina said but what I'm going to give you is a much hopefully simpler principle that will help you communicate a lot of the same concepts but in a way that hopefully resonates with a lot of stakeholders.
So now let me give you a perspective of my journey in resilience. Like how did I arrive at this and to help you understand how I arrived at this I have to first show you a model that I created called the cyber defense matrix. Some of you may already be familiar with it. My first use case in using this matrix, it's a simple matrix, it's a simple mental model but my use case was just mapping vendors. I wanted to understand where different vendors fit in this matrix and as it fills out I'm sure you can notice a pattern that you may be asking yourself as well.
We look at this pattern of vendors out there and the first question I asked myself was why are there so few companies or vendors on the right side, right? Why does it seem so empty on the right side of the matrix? And I had a couple different hypotheses.
One hypothesis is represented on the bottom here, this degree of dependency between people, process, and technology and what I observed was we just generally speaking had a higher dependence on technology on the left functions like the identify and protect functions whereas on the right we seem to have a greater dependency on people and so maybe there's just fewer technologies on the right, okay?
That was my first hypothesis but then I observed something else that was remarkable that helped me really understand why we might be missing technologies on the right and to help you understand that I have to walk you through a little bit of history. So let's go back, 1980s. Companies like Dell and Gateway make computers cheap. We buy lots of those computers. First problem we run into was what did I just buy and what business function does it support? We're still struggling with this question, okay? But that was the first problem that we had and we came up with solutions to address that.
At this point I'm going to also characterize the tension between the IT team and the security team. In the 80s there was no tension well because there was no security team, easy.
Okay, fast forward 10 years we start seeing people send us I love you messages or people who walk into our networks and so what do we do? We come up with solutions to address that. We come up with firewalls. We come up with AV and the tension between the IT team and security team starts to grow because we now have a small hobby shop of mostly from IT but they're pointing out these vulnerabilities saying go turn this off, go patch this and what happens is it starts to destabilize our environment and as a result we start seeing tension.
You fast forward 10 more years we start seeing all these alerts and we need to be able to manage those alerts so we come up with IDS and SIM and more tension between the two organizations because we now have we just you know continue to have more eyes on these vulnerabilities. We have a 24-7 SOC because we need to now have eyes on these alerts as well and we're also threat management focused. You fast forward 10 more years we now have fires everywhere we assume breach. We need firefighters and firefighting tools.
Many organizations that have gone through this journey we split off our business we split off the security team from the IT team and we become a dedicated business unit and we become risk management focused. So if you've been in security for a long time this may generally sound familiar to you. What I observed in this pattern was that each decade maps nicely to the NIST cybersecurity framework. 80s was an identified problem, 90s we had a protect problem, 2000s we had a detect problem, 2010s we had a respond problem.
So naturally if those who know what the cybersecurity framework looks like the 2020s will be a recover problem. So maybe again the reason why we didn't have technologies in the 2010s or the recover column is maybe we haven't gotten there yet. So now we're in the 2020s and we're in the age of recover or the age of resiliency. If you've wondered why there's all this talk about resiliency maybe it's because we're in that era now. So what are the attacks that we're going to see? We've seen challenges in each of the eras. We have a new era of the of the recover era.
What's the challenge that we're going to see? And if I look at it from the standpoint of our traditional CIA triad, confidentiality, integrity, and availability, what undermines all three of these things? I think people know the answer which is ransomware. So ransomware is the scourge of the 2020s and it's causing a challenge, a recover-oriented challenge. So naturally we need a solution. So what are the solutions that are out there? So if I go outside and ask the vendors, hey, what do you have for me for recover? Typically what we get is something like this. And this is from an actual vendor.
I won't tell you who it is. They are actually out there. But they had an advertising campaign where they basically said, hey, come back to the 1990s, okay? Join the prevention age, which, by the way, was the 1990s, right? In other words, come back and do more protect, detect, and respond. Come back and do the 90s, 2000s, and 2010s. And my answer to them is, I have a 2020 problem. I need a 2020 solution. And while the solutions from the past will mitigate those concerns or mitigate the number of occurrences, if I have a recover problem, none of those will help me.
So ultimately, I need a recover solution for a recover problem. I need a 2020 solution for a 2020 problem. And the solution from the past is not appropriate for this era. All right. So hopefully you're with me so far.
So now, of course, the question is, what is the solution out there? And as I looked at a lot of different technologies and solutions, I came up with I saw many things that were very recoverable, very resilient. Things like content delivery networks or design patterns like copy and write, and many of the design patterns that you heard from Alina as well. Copy and write, by the way, you never delete anything. You just keep appending, okay? Or Docker containers or serverless architectures, all things cloudy cloud, even buzz words like blockchain.
These all tended to be very resilient for one reason or another. And as I looked at all the different solutions out there, I found a common pattern across all of them. And the common pattern is what I call the DIE triad. And that stands for distributed, immutable, and ephemeral. And what's nice about this is each of these attributes is they do help us address some of the challenges that we have in security. For example, if I'm trying to ward off a distributed attack, I should have a distributed service, okay? Or if I'm trying to find anomalies, well, if it's immutable, then any change is bad.
And attackers typically want to establish persistence, so if things are ephemeral, very short lived, then it's really hard to establish persistence. But what I observed that was even more interesting than that is that each of these attributes offsets the need for CIA. The more distributed something is, the less I have to worry about availability. That was actually what Elena said at the very end, right? What about availability? Why do I care? Because now I have all these distributed nodes. Why do I have to worry about integrity if the goal is to have no changes at all?
So, any change, it doesn't matter what the change is, is considered bad. And ephemerality, in case you're not sure what that means or how to apply that, again, if it's very short lived, like, for example, my two-factor tokens, which I'm broadcasting, anyone can take a look and, you know, take a photo, why do I care about the confidentiality of this if it's going to disappear in about 30 seconds?
So, the perspective here is the more DIE something is, the less CIA I need to worry about. Okay? And that's a this concept is going to be really hard for it took me a while to grasp the implications of that. But let me kind of walk you through that again just to help you understand what I'm saying.
So, first of all, DIE is my argument for resiliency. The more DIE you are, the more resilient you are. The more DIE you are, the less security you need. The more resilient you are, the less security you need. Let's not flip that around. The more secure you are, the less resilient you are. Hmm. What do you think about that? I'm not sure.
Well, I have thought about it a lot. But I'll let you ponder that for a moment. Okay? But let's talk through ways to think through this a bit more systematically.
So, we have a traditional risk analysis equation. It consists of two major factors, likelihood and impact. And when we look at likelihood, it's usually made up of two major components. Vulnerabilities and threats.
Well, the problem with vulnerabilities is that they age like milk. Okay? They get worse with time. And by the way, you can patch everything out there in the world, and guess what? Tomorrow you'll have a lot more vulnerabilities. And threats. Threats age like wine.
So, they get better with time. Vulnerabilities get worse with time. Threats get better with time. That means likelihood just continues to increase with time. And this is largely out of our control.
Consider, though, the other side of the equation is impact. And that is fully within our control. The way that we can reduce impact, or the goal, if we can reduce impact, then of course we can reduce risk as well using this equation. And when we think about how we look at reducing likelihood, that's traditionally through all the things that we do with CIA.
But again, that's largely out of our control. What is directly within our control? Impact. How do we reduce impact? The D-I-E triad. Let me give you another metaphor, another analogy or mental model to think about the challenges that we're how do we think about this space. And this is using I'm borrowing an analogy from the cloud native world. And it's this notion of pets and cattle.
So, what are pets? Pets are things that you have a name for. And when it gets sick, you patch it, you take it to the vet. And you like giving it hugs.
So, these are things like your national ID, your server under your desk, your personal laptop. Okay?
Cattle, on the other hand, are things that you cannot even pronounce the name of. You put a brand and it's a bunch of letters and characters. And when it gets sick, well, you just shoot it and you move on. Okay?
So, these are things like Docker containers, serverless architectures, credit card numbers that constantly change. When it comes to pets, you have to CIA them. Okay? You don't have a choice. You must protect those pets. These are not COVID pets. You can't just, you know, hope that someone else takes care of them. This is a pet that you will own. These are also called legacy systems. Okay?
Cattle, on the other hand, you design them to D-I-E. And so, now you have this sort of dichotomy between pets and cattle. And you can use this sort of concept in a lot of different scenarios. Not just in IT, but let's say, for example, let's take a non-IT example. What are pets?
Think of, like, pilots versus drones. Okay? F-16s versus drones. F-16s are pets. Drones are cattle. Water treatment plants versus water life straws. Life straws are these little straws that you can just use to drink clean water. Nuclear power plants, localized solar generation. You get the idea. There's different ways to look at this, not just in IT, but in all different types of physical infrastructure or other types of environments. And you can see where we would want to invest in the types of things on the right side, but it doesn't mean that we don't have Air Force pilots.
It doesn't mean that we don't have nuclear power plants. We will always have pets. We will always have pets. We will always have pets. The question is, how many pets do we want? Okay? And I think what we want is to have more of the things on the right and less of the things on the left.
But in IT, what exactly are pets and what are cattle? I have all these different assets in my environment. Which one is which? How do I know which ones are pets, which ones are cattle?
Now, you and your organization probably have asked the business and said, hey, what are your critical assets? And they'll tell you what they think are your critical assets. But what's really actually kind of interesting about the D-I-E triad is that it's very measurable. D-I-E is much more measurable than C-I-A. And I'll give you an example. What is the unit of measure for confidentiality? Anybody?
Good luck, right? What is the unit of measure for ephemerality? Time. Okay? Easy to measure. Super easy to measure. So it's a proxy for measuring confidentiality. I was showing you earlier my two-factor tokens. How much confidentiality do I need to give it? Very little because it's very short-lived. But if something's very long-lived, then I need to increase my confidentiality. So I'll just use something as simple as time. And guess what? We have that as a measure. Most of you already have that as a measure for many of your systems.
So I took, for example, the up time. And it's a simple proxy value. Okay? It's not a perfect value, but it's a value that I can guarantee you many of your organizations already have captured. And this up time, I then look at all my systems, and I put it on a chart like this.
Now, what defines a pet? What defines cattle? That's up to you. I put an arbitrary value. I said anything above this time frame, that's a pet. Anything below that is cattle. And now I have a way to think about different types of policies and incentives.
I can say, how do I move this curve down and to the left? Because if I can move this curve down and to the left, I would argue that this is a more resilient type of environment than one where my curve is more to the up and to the right. Okay?
Again, conceptually, it should be clear. A curve that looks like an L shape is going to be far more resilient, because anything that gets blown up on the bottom here, I don't really care. It doesn't really matter.
Whereas, if it looks like a 7, then any one of these pets runs into the street and gets hit by a car, and I have a bad day. Okay? So the goal here is, how do we shape this curve to be more like an L shape?
Now, that said, that's the goal, right? That's the goal. But there's also another perspective, which is getting it more and more like an L shape ends up being, can be very hard. There's a lot of orchestration that needs to happen, and sometimes that can be very costly. But what's really interesting is, again, this is all based on actual numbers, actual math, if you will, which means that it's also very calculable around what the actual shape is. And that's what I did.
I said, okay, let's take all these points and put that on a curve, and there's a certain value. It's called the beta value. It's a logarithmic graph, and there's an exponential value. It's called the beta value, and the beta value is significant, because if it's between 1.8 and 2.5, there's a lot of research that's been done around how resilient, how robust, actually, is your environment against different types of attacks. And it turns out, if you're between 1.8 and 2.5, you're considered pretty good. If you're lower than 1.8, like 1.3, then it means that you're actually really good.
If you're greater than 2.5, it means that you've got some work to do. What's interesting about this is, if you're less than 1.8, your maintenance costs go up. It becomes more expensive, and it becomes more expensive because, guess what? You have to get another IDP. You may have heard that earlier, right? Or you need to have a lot more orchestration, you need to have a lot more coordination, but it becomes more expensive. And there's a certain sort of balance that we have to have. As much as I would like to have that L-shape curve that you saw earlier, that may just be too expensive, okay?
And so, if I'm looking at a regulator, and the regulator—if I'm critical infrastructure, and my regulator says, hey, I need for you to be more resilient because you're a critical infrastructure, guess what I have now? I can say I have this value that is better than what the academics have said is good, but it's going to cost me more, okay? Maybe you can give me some tax breaks or something, right?
So, the perspective here is that I have a very calculable measurement to be able to show you how resilient I actually am, or how resilient I am relative to my peers, okay? Now, with this said, there are a couple other things that I want to throw out as principles to consider. When we think about controls or when we think about these incentives that we put in, one of the things that we really want to do is try to minimize the number of pets. We want to discourage or disincentivize the creation of pets. We would love to also get rid of pets, right? How do we get rid of pets?
Okay, I'm curious. Who here has successfully decommissioned a legacy system?
Okay, wow, that's a lot more than I thought. But how many of those?
How many, like, anyone's decommissioned, like, more than 10 legacy systems? Okay, smaller handfuls. But the point is, it's a, and that journey, I'm sure, was easy, right?
No, it was painful. It is like putting down your pet, and nobody, that's, there's a very strong emotional attachment to that. And so getting rid of pets is really hard. As much as we love to be able to do that, it is not easy to do. So the other alternative we have is essentially control how many new pets we have. So what happens here is that any cattle you start with, if you don't take action on removing that cattle, it becomes an elective pet. You've chosen to let it become a pet. So one of the controls I've put in is simply a system that says, hey, you're about to adopt a pet.
Are you sure you want to do that? Because guess what?
If you do, you need to give this pet a lifetime, lifetime of love, care, and attention. You better come with veterinary care budget. You need to make sure it has its shots.
And oh, I really need to know who the owner is, because I am not walking this dog. I'm not taking care of this pet. This is your job to take care of this pet, not my job. I'm the vet, but the day-to-day care and feeding, that's somebody else's job. But unfortunately, you do this, you don't do this, and guess what? You end up adopting all these pets without realizing that you've done that. And this is something that you want to try to avoid.
Oh, you know what? I forgot a really important point. Let me go back a second. When it comes to this concept here, let me give you another perspective that may be helpful, okay? Let's suppose I'm from Mars, and I have no idea how your human body works. And I don't know which cells in your body are important, which ones are not important. So consider, let's suppose I just arrayed all your cells in your body from the shortest-lived to the longest-lived, okay? What do you think falls into the very shortest-lived cells? What are the kind of cells that are very short-lived? Anyone?
Skin, blood cells. And what are the cells that are very, very long-lived? Teeth. Stem cells.
No, keep going up higher. Brain. Brain cells. Okay.
So now, on the right side here are brain cells. On the left side here are skin cells.
Again, I'm a Martian. I don't know what skin cells are or brain cells are, but I'm just going to array this out, and I'm going to say, you know what? I think that these cells are very important. And it turns out, what are they? They're your brain cells, your heart cells, your major organs. And what are over here? It's your skin cells. Your skin cells are exposed to the outside world. They fall off.
They die, and you don't really care. They turn into dust.
Here, we have all these sort of protections, right? And we have to secure those things over here, but we don't really care about the things over here.
Now, let me ask you one other question. What do you call a skin cell that lives too long? Cancer. And what do you do with cancer? You cut it out, right? But the decision to cut it out is a business decision, okay? The business makes a decision of what they choose to adopt as a pet and what they choose not to adopt as a pet. Because in the U.S., we have this model. Her name is Cindy Crawford, and she has this cancerous thing on her face called a beauty mark. And for whatever reason, that's really important to her.
She's made a business decision to not remove that beauty mark, even though it's essentially a cancerous skin cell, right? And she said, nope, don't remove it.
So, as her doctor, we would say, you know what, that's your business decision, but we're going to keep a very close eye on that in case it metastasizes and spreads, okay? But that's ultimately a business decision, and that's, again, we will always have pets, and the business has a choice to make that, choose to declare something to be a pet. But what we also don't want is for the business to just accidentally adopt a pet and not realize it. Okay.
So, one of the things that I did, one of my metrics that I look for is just basically how many cattle do I get rid of on a regular basis? This is actually one of my best measurements, because it tells me how actively I'm removing things that might become pets. This also allows me to concentrate my security resources on those things that matter, right? Because at the end of the day, we have an opportunity to shift our role.
Today, most of us are veterinarians, but I'm spending a lot more time trying to become a pet control officer. We've talked earlier in other sessions about the workforce challenge. Do we have a workforce challenge that is severe because we have too few veterinarians or because we have too many pets? Which is worse? What's causing the problem more? I would argue the problem is worsened because we have too many pets and we haven't practiced pet control. All right.
So, these concepts hopefully make sense when it comes to, like, systems and applications. But what about something that seems very much like a pet all the time, and that's data? Data seems to be a pet and only pets, right?
Well, it turns out it's interesting. In the shared responsibility model for AWS, you see this whole spectrum of resources. At the very top, they have customer data. And customer data seems to be very pet-like, and the things on the bottom, they're very cattle-like. And there are various technologies that we've seen that help us shift this balance more to become cattle-like.
So, you've heard of cloud security posture management or cloud workload protection platforms, all these different technologies that help us shift this to become more cattle-like. But at the very top, it's still very much pets, okay?
So, I was looking around to figure out, what is it that turns even data into cattle and not pets? And it turns out it's privacy. It's privacy-enhancing technologies, which happens to have the acronym PET as well. But the notion is privacy is actually our way of making data pets and avoiding data pets instead of having them as cattle.
So, you may have heard all these privacy-enhancing technology buzzwords, but if I start aligning them to the D.I.E. triad, what I have found is that they actually do help us do things either like pet control, for example, minimizing, you know, data minimization as a concept or, again, doing things that will make the data that we have distributed, immutable, or ephemeral. And in this process, we can avoid, again, turning having data, having to retain more data pets instead of data cattle. What's really also interesting about this is this principle of privacy by design.
So, privacy by design is all about D.I.E. And I mentioned earlier, D.I.E. offsets the need for CIA.
So, consider the term security by design versus privacy by design. If I'm designing things to be private by design, it means that I don't have data I need to secure. If I have data I have to secure, then that means that you're not really designing it to be, you know, to have privacy by design. It's essentially like opposites of each other. The more you do privacy by design, the less burden you have to have to secure that data at all. Let me now also apply this, the D.I.E. concept to another concept called the OODA loop. You may already be familiar with this, Observe, Orient, Decide, Act.
So, the OODA loop, the goal of the OODA loop is to, so you have the attacker OODA loop, and as a defender, what we're trying to do is get inside the attacker OODA loop. But as a defender, we always have second mover advantage, which means that we're always outside the attacker OODA loop. We as defenders. But if our goal was to get inside the attacker OODA loop, it turns out there is an entity that's already inside the attacker OODA loop, and that's the business. The business always actually has first mover advantage in that they're creating new things.
The problem is that when we apply security on the business, it causes the OODA loop of the business to get much bigger, meaning the cycle time for how the business moves lengthens, which causes us to lose the advantage against the attackers. The opportunity that we have with the D.I.E. triad is to restore that natural business, the business OODA loop, and the design patterns that allow businesses to move faster essentially allows us to have a much shorter OODA loop, and that's kind of what you heard from Elena as well.
The business is highly incentivized to move fast, and a lot of the design patterns that they're already adopting are resilient by design, and what is it that slows them down sometimes? It's security, okay? So we have to be cautious about how we apply those security principles in this context. So now let me go ahead and complete the rest of the stages that we saw here. So 2020 is the age of recover. We're going to see destructive attacks that undermine our ability to recover. What's the solution? In my view, it's D.I.E. as a general principle, and we have an option.
So I think it's going to converge. I think we see the split between I.T. and security, and I think in the 2020s, we're going to start seeing it converge, and I think we have three options for how it's going to converge. I'll talk about those three, but one is to converge into where the security team wins, and we design everything to be secure by design and shift left and all these other sort of things that we know all about in security, and by the way, just to be clear, I'm a security person. I've been in security for 30-plus years.
I still wear a security hat, and I'm telling you this being a security person, okay? I'm going to bash security a lot, but just know I'm bashing myself in the process. So one is where the security team wins. The other one is where the CIO wins, and then a third state. So let's talk about what those three states are. The first one is when security wins, and if the security wins, meaning we secure everything by design and everything has all these CIA principles in there, then I think we end up with a fragile environment, and what I mean by fragile here is when you harm a system, it breaks, okay?
It gets weaker. Then you have D.I.E., where if the CIO wins or basically the function of D.I.E.
wins, then we become a resilient environment, but essentially it bounces back to what it was before. But then there's this other concept called anti-fragile, and this was popularized by a guy named Nassim Taleb. He wrote many books. If you want to read the book, I wouldn't suggest you read the whole thing. Just read the first 100 pages, otherwise he rants a lot. But anyway, it's an interesting concept. The concept is, again, fragile, you add harm, and it weakens the system. Anti-fragile, you add harm, and it strengthens the system, okay?
And so the concept here is what we want to do is when it comes to complex adaptive systems, we don't always know what our pets and cattle might be. We can remove as many pets as we can and ensure that we think we have as much, we hope that it's as cattle-like as possible, but unfortunately we don't know if complex adaptive systems. So what we need to do is shake our system, and that's what we hear with things like chaos engineering. Chaos engineering, in this sort of way, in this sort of view, is trying to find those pets that you didn't realize were pets. So how do you know?
You shake the system, and you find out, oh, here was a pet-like system. Then there's this process called creative destruction. It was a term coined by Joseph Schumpeter, and he talks about these cycles of creativity where you start replacing things, and the view I would take on that is it's our opportunity to take those pets that we just discovered and replace them with things that are more cattle-like, and through that process, we become more anti-fragile, and I think that's where we really want to be. So to summarize, we have the D.I.E. triad.
Hopefully, again, this is a simple way to communicate with others about what is our goal for resiliency, and this goal for resiliency turns out to be perhaps opposite of our goals for security. Okay? Maybe are they potentially on opposite ends of the spectrum? And what I'm trying to argue here is this. As much as I'm a security person, and as much as I would love to make sure that everything is secure, maybe actually that's not the right decision. Maybe that's not the right first step. Maybe our first step is actually to make systems more D.I.E. Make it more distributed, immutable, and first.
And if I can't do that, then I have to fall back on C.I.A. And so when I consider the balance between security and resiliency, if they are considered opposites, if they're considered in a different end of the spectrum, making something more D.I.E. is something that allows us to reduce the need for C.I.A. to begin with. Okay? The fewer pets you have, or the more cattle you have, the fewer pets you'll have, and thus, I can focus my resources, my limited security resources on a fewer number of pets and ensure that they're more secure. But all the rest, I don't really care.
So that's the main, again, some of these things I'm still struggling with to really grasp the implications of this, but this notion of C.I.A. being the opposite of D.I.E., the notion of security being the potential opposite of resiliency, it's not something that we all embrace yet. But what if they are opposites? And if they are opposites, then something like security resilience should not make any sense to you. You're like, what does that mean? But hopefully now you can understand why potentially security and resilience are two different concepts that may be at odds with one another.
And as much as we'd like to try to do both, within the overall system, as Elena, her diagrams were amazing, there are different parts of your, different levels where some things are going to be pets, but as much as possible, you want everything else to be cattle. And with that in mind, I hope this makes sense, and if you have any questions, let me know. Fascinating presentation, Sunil. Great analogies. I'm going to look at things in a whole new, different way now, because of pets and cattle and so on. Are there any quick questions in the room?
I realize, yes, go for it. Yeah, thanks. First of all, maybe you need to update your slide back, Sunil, because now NIST has a sixth pillar, the governing pillar. I'm just thinking, obviously the companies have different maturity levels. So if this DIH right is easily applicable for all companies, or maybe it's rather to start maybe for, if the maturity level is less, let's say, start with CIA, then the main aim is going to DIA. What do you think?
So, in my view, I think the younger companies have a better shot of building systems to be more DIA to begin with, because they have fewer legacy systems to begin with as well. Furthermore, newer companies are already building in the cloud, and cloud, again, is very naturally aligned to cattle-like systems.
In fact, I forgot to mention this. I have this paradigm, which is pets on prem, cattle in the cloud. Pets on prem, cattle in the cloud. It's okay to feed your pets. It's okay to feed cattle to your pets. It's not okay to feed your pets to your cattle. Okay. So lift and shift is taking your pets and feeding it to cattle. Okay. And if that doesn't horrify you, well, that would be a concern, but that should horrify you.
Yeah, I'm taking my pets and feeding it to cattle. Like, what are we doing? Okay. Many older companies have a lot more pets. Younger companies have fewer pets, and they have an opportunity to apply these principles early on, as opposed to, you know, those who have to retrofit them. So like a flash forward, they can achieve this. I think it's easier for smaller companies to achieve it, because they just have fewer pets to deal with. I see.
Yeah, thanks. Just looking at it, might it be a fair statement?
Well, not quite fair, but might it also be a statement to say CIA is more an information-driven framework, and D.I.E. is a more infrastructure-driven framework? So I've been wrestling with that as well, which is why I showed the data, applying D.I.E. to data as well, and as well as applying it to non-IT-related examples that you saw earlier. So it's a general principle that hopefully is easy to communicate, because as much as I love Atlantis content, it may be hard to absorb right away, and it will take me a while, even though I really I've tried to understand everything.
I understood a lot of what she said, but it will take me a while to absorb it. I hope that you can leave away the simple principle of trying to make things to be D.I.E., and of course, in the English language, that means something different than in German, but the concept of getting rid of things on a regular basis is the principle here, and whether that's data, or servers, or workloads, or the Workers' Council may have issues with users, but you get the idea. The principles of D.I.E. can be applied across all five of those asset classes that we mentioned at the very beginning.
We have another question there. Thank you very much. That was once again a very, very amazing presentation with lots of food for thought. We were just wondering, is there any way to apply these two processes?
So, okay, so going back to the people, process, and technology part of it, processes, I think the idea of long-lived processes are useful in certain contexts when it's, for example, pet-like systems, but short-lived processes for things that are very dynamic. So when the business needs to run very fast, you need processes that you review on a regular basis to say, do we really still need this process? Because old processes slow you down, right?
It's not adapted to the current business needs, and so I think my view of processes is tied back to what is the business process that you're trying to achieve? And if the business process involves something that is more pet-like, you may want to have that business process actually live longer, but if it's tied to something that is more cattle-like, then that business process may end up being much shorter-lived. It's the same concepts, and the idea of aligning something like D.I.E. to processes is what I've been thinking through.
The only thing I can think about processes, though, is the time aspect of it. I couldn't figure out how to make it distributed, per se, right? Thank you.
Okay, we'll take one more question because we're slightly over time, but at least we haven't got another presenter waiting in the wings, so... And it's lunch. It's just lunchtime, so yeah.
Okay, thanks. Don't you have, I would say, the limbo problem? It's like when a lot of systems are waiting in the limbo to be declared pets or cattle, and they're like potential pets, but at some point you should say, okay, you're actually cattle. And what I see as a challenge that this waiting in the limbo can be infinite because nobody says, okay, I'm bold enough to declare you as a cattle.
Yeah, so the threshold that I set earlier, one of the thresholds you can set is your patching time frame. So let's say you have a 30-day patch window or 90-day patch window. You have a 90-day patch window, but then as everyone knows, there's exceptions, right? And so the exception usually says, okay, we have another 30 days or another 90 days. That time frame, so first of all, I would create a cutoff that says if it's a 90-day patch window, anything under 90 days, 89 days or younger that's going to be a cattle.
If you start going past that, meaning you don't have to patch that system or now that system is no longer immutable, okay, you're now in this place where in limbo where it's starting to look like a pet. Are you really sure you want this to be a pet? And if you do, then we're going to start going through the processes of adopting that pet. But if you really don't want that pet, let's get rid of it. Why even bother patching something you can get rid of, right?
And so that becomes that limbo opportunity to say you have 90 days to really get your act together to adopt this pet, otherwise let's get rid of it. Okay, thanks.
Yeah, are we done or any more for any more? Okay, food for thought and now time for food. Thank you so much, Sunil.
