 Welcome to the Zero Trust Commandments section. My name is Mark Simas. I'm co-chair of the Zero Trust Architecture Working Group within the Open Group. And I'm also Cybersecurity Architect at Microsoft. So today we're gonna be talking about what we're doing within the Open Group on the Zero Trust Commandments. And this is really part of a series of guidance, first starting with Zero Trust Landscape, which is an ongoing annual kind of survey and information gathering and then providing publications on that once a year as well. And then the core principles, which really was that first stage of defining Zero Trust from an Open Group perspective and leveraging all of the knowledge and information and context from the members and then laying out these are the principles, which we did map quite closely to the original Zero Trust Commandments, which has influenced our current work that we're working on here or working several of these in parallel. So we'll be talking today about the Zero Trust Commandments and very much in the spirit of the original Jericho Form Commandments, but updated for the modern day and the cloud technologies and the current kind of challenges that we're seeing today in the real world or in today's world rather. And then there's also work going on around Zero Trust Reference Architectures, Zero Trust Business Guide and Practitioner's Guide that will also help make this real and make it much more actionable as well. So the Zero Trust Commandments, let's walk through those and we're gonna be starting with the purpose of them and kind of why we're doing it. Then we'll talk a little bit about the assumptions. These commandments are really brought under and then we'll list each of the commandments and kind of talk through each one and the current state this is in drafts. So again, part of the call to action is for y'all to participate. So if you feel really passionate, we'd love to have you involved and kind of influencing and bringing your perspective to it but the list as it stands today is the next piece that we'll cover and then we'll zoom into one of the examples, the first commandment and kind of how we're structuring those and why we're thinking about it that way to help them become as clear as possible for guidance. This is, we found this particularly important to have these commandments and this clarity because Zero Trust is very popular. It's something that we're seeing a lot of uptake on. We're seeing a lot of interest and adoption of but there's not a lot of clarity. There's a lot of different perspectives. So we really wanted to drive clarity and actionability. So organizations could take advantage of the modern approaches to security that Zero Trust brings as quickly as possible without having to kind of work out a lot of conclusions on their own. So really shooting for that clear guidance. And then of course the call to action at the end to have y'all get involved and review, read or join some of the different forms of working groups. So the purpose of these commandments as I alluded to earlier is the overall purpose is we want organizations to become more resilient to the cyber attacks that we're seeing ransomware or something that is essentially built a business model, a very sophisticated, straightforward but sophisticated business model on extortion that is starting to take advantage of a lot of the security weaknesses that most of us in the security industry have been aware of for quite some time. It's now really becoming real as these extortion-based attacks make it real. And so there's an urgency to this that hasn't been there before, that's sort of the underlying theme. But what the purpose is really here is to get organizations resilient by giving clear guidance. And that's really what these commandments are designed for is we wanna make sure that there's a full lifecycle approach which is actually one of the commandments. But ultimately we wanna prevent as many attacks of these as we can. Of course you can't prevent everything, there's no such thing as perfect. We wanna limit the impact and the likelihood of the attacks that we do have both ahead of time and in real time as they're happening. We wanna rapidly recover from attacks because ultimately the business has to keep going. The organization's mission has to keep going regardless of where the computer system state is at or the computer data is. And so it's really about making sure you're getting back to full operations as soon as possible. And then of course learning lessons because these attackers will try the same thing over again and will try something that worked at a different target or a different organization. So it's really important to have that full lifecycle view. So the benefits of following these commandments is really to get rid of that ambiguity, to really allow organizations to focus on what's important and what to start from and where to start and what to do first. And they're really intended and driven towards accelerating that ability to adopt Zero Trust and unblock the business value that oftentimes security is holding up using those classic pre-Zero Trust techniques. And then also helps to track progress in the long journey because this is a transformation when you talk about Zero Trust, much like it's a transformation, much like digital transformation, much like a cloud transformation. It's really moving to a dynamic state of security where you're constantly trying to improve but you're also dealing with constant changes from the external environment. And so by being able to look and say, these are the clear things that we are going after, how well are we doing on number one, number seven, number two, number four? How is that something we broadly applied well? And so it really kind of helps with that. And of course we're working to build metrics that also allow you to be much more quantitative on that. And then this sounds a little funny coming from me, from my other role that I'm also working for a company that does as a security vendor. But ultimately one of the things that we've seen that's actually harming a lot of organizations is really trying to sort through all the different vendor claims. Zero Trust this, Zero Trust that. And it's really, really confusing and difficult for organizations to understand, okay. So how does this fit in? What does this help with? And so we expect that these commandments will also help rationalize a vendor claim. It's like, okay, you say this is helping, but in what way, which Zero Trust commandment does this actually help me achieve? And how does it do it? And so really it kind of helps setting up that North Star. So the assumptions here, we were realizing as we were going through it and defining these commandments that in the core principles themselves as well, as the commandments are in effect a maturation or an evolution of the original core principles to be very specific, very actionable. And we realized that there was a couple of underlying assumptions that we wanted to call out here. And we put a little yin-yang in there because it kind of illustrates the sort of interesting duality of security. First of all, we have to assume failure. And sometimes you see this as assumed breach or assumed compromise. Microsoft principles call out assumed breach. I believe the NSA Zero Trust principles also called them out in a few others. Breach tends to mean it has a very specific legal meaning and a lot of different jurisdictions. So we tend to say assume compromise more now. But that assumption of failure is really the underlying piece. You're gonna assume that the attackers are gonna be successful sometimes. You have to assume that your people are gonna make mistakes sometimes. We've all clicked on a phishing email, et cetera. So it's really important to have that assumption that things will go wrong built in. And this has been recognized for a long time in the engineering space through sort of the fail safe design principle that the system may fail some or it will fail eventually. And it has to fail in a safe state. And then there's another side to it as well that we don't see a lot of traction on. That we wanna make sure is there for completeness which is assumed success. Despite the darkest night and all the things that could go wrong, things will go back again. We've seen this with some of the worst case scenarios that hit various different organizations with ransomware and not patchy and some of the other high profile attacks and others that didn't get reported or weren't widely known publicly that life goes on, business goes on. And it's really important to sort of have that assumption in there as well that you're there to enable a business. And even after a security attack, it's there to enable a business afterwards and to get back to that as quickly as possible. So we found this duality is really important to call out and highlight. So the commandments themselves, right now the way that they're drafted is we've really broken down to four categories. This is, if I recall correctly, a slight simplification of how they were represented in the core principles. The first one, which we'll cover in details really about modern work enablement that ties into that assumed success underlying assumption that ultimately security isn't there to make something secure. It's there to enable an organization. The way that it enables the organization is keep it secure against attackers. But ultimately security isn't the goal. Security doesn't create value. The actual business and the mission completion, whether it's an NGO government or a for-profit company. Ultimately that mission, that business has to succeed and security just helps them do it safely. And so it's really important to have that very first beginning one with the immediate follow-ons of aligning to the organizational goals and the risk management framework and the way that risk is managed within the organization. So that's really the key parts of that first piece is to really set that north star of the purpose of security. The next section there, the guardrails and governance, is really about kind of setting, governance, sometimes people like the term, sometimes people don't like the term. So we put guardrails in there as a way to sort of make it clear to everyone that ultimately this is really how you keep things on track. And so the first part is people guidance and inspiration. Everybody's got to be on the same page while you need a page that architecture policy standards that help everybody understand within the security organization and elsewhere within the organization on how to work together. That risk and complexity reduction, keeping it as simple as possible. Alignment and automation, keeping all the different pieces perhaps working together instead of operating inside of those. Security for the full life cycle. Oftentimes we see blind spots in security where people are worried only about, we're gonna secure this session. Well, what about the server or the client on either side of it? So it's really important to have that sort of full cycle view. And we see that applied in a lot of different ways where there's sort of just a narrow particular specialized focus. The technology piece, this is a very, very important shift in the technology or the way that technology folks think who've been very, very technology centric for their security as opposed to asset centric. It's really important to define what is valuable to the business? What are the assets that need to be protected or that are being developed that need to be safe as they're incubated? And then translate those into technology and protect it as opposed to saying, we're gonna keep this network safe. You know, with a technology centric view that's really blind to the business value of any asset on it. So it's really important to make that very subtle but very important shift to asset centric security, focusing on the data, focusing on the applications that create value, the data that stores value. Amendment nine is the least privilege. And so this is a key principle that, you know, it can be as simple as don't have any more admins with control of everything than you need to. But it also goes into the world of, you know, just in time privilege, so limiting privilege by time. Because the more privilege someone has, the more time that they have that, you know, that creates essentially an attack surface and a risk to the organization. I like to think of it as, you know, a lot of people treat admin accounts like, ooh, I want that. Like it's a little gold nugget. But in fact, it's actually more of like a nugget of plutonium that brings its own danger that you don't necessarily want that power. You want to reduce that as much as possible so you can reduce the potential damage. You know, again, without a soon failure or soon breach in case something goes wrong. And the last piece is really around that security controls. So 10 there, the simple and pervasive. Again, that similar theme from that simplicity that reducing the complexity. But, you know, the key is that these security controls should be really hidden, right? They should just be a part of the background. They should be a part of the fabric. People don't think about them. They don't have to have any more friction on it than they have to. For example, going to the cloud and Azure or AWS or what have you. When a developer creates an environment, the security should be just built in, right? They shouldn't have to worry about it. They shouldn't have to think about it. They shouldn't have all those points of work. So it's really important when those security controls are built is you want to be simple as possible, you know, as invisible as possible and also just pervasive. And that's just the way things work. This is the background. This is not the actual main characters. So that's a very important piece. And then the commandment 11 there, the explicit trust validation. You know, ultimately we had, you know, without really intending to. I think it wasn't a design goal when we had a perimeter-centric approach. You know, we essentially assumed that anything on that network was trustworthy as long as it had a physical connection to that network or a Wi-Fi connection to that network, we're gonna trust it more. And that's no longer a reliable assumption. So we have to explicitly validate trust. We have to bring as much data sources and as much input and as much telemetry that helps us essentially filter the poison out of the water. So, you know, we want to have the legitimate stuff, just be simple and work and, you know, legitimate user, email, productivity, application access. But we want to take the impersonators. You want to take the malware. We want to take all of the bad stuff out of it. And the way we do that is we have to have as much telemetry and data to figure out what is normal versus what is anomalous. And then the gray areas in between, that need a human to check it out. But, you know, that explicit trust validation really relies on having those data sources and then actually using that to filter out, like, hey, this is an impersonator for sure. This is an attacker that's stolen a credential. No, this is something that's in the gray area that's sent it over to security operations and have them investigated, et cetera. But that explicit trust validation rather than just saying, oh, they're on the networks and they're fine. Yeah, so we got to get out of that mode as well. So let's dive into an example here real quick. So this is a quick summary and I'll show you a screenshot of the current draft in a moment. But on commandant one, on work enablement, we've got a what, why, and a how for each. And we know it's different cultures sort of center on the why and the theory behind it in order to really sort of understand and appreciate and agree with something. We know some other cultures tend to value the how and the details, show me how it works. And then I'll believe it's a good idea. So we really wanted to have all of that to make sure it was as clear as possible across as many organizations and cultures as possible. So what, very simple, straightforward, one, maybe two sentences. People must be able to work on any network in any location with appropriate security assurance and access restrictions. Very clear, very straightforward. The why explains why and why this would be different than anything you may expect or anything that had come before. So really providing that reasoning behind it and then the how. And this is obviously a shorter version of each of those. We'll show you the screenshot in just a moment, but ultimately showing how this works and how do you apply this? Now, it sounds like a great idea about what do I change? What documents do I affect? What technology do I reconfigure in a different way? So we really wanna lay that out there with some examples and such to help people with it. Again, these are commandments. So they're gonna be broadly applied in a lot of different circumstances, but we wanted to make sure that we had a really clear center to start from. And then this is kind of long form. We're trying to keep these around a half a page to a page. So they're easy to read, but they still have a couple of really good, clear examples. Any caveats are noted. And there's the why has a couple of extra sub bullets that we didn't cover in the previous slide and the how does as well. So really trying to make this as clear as possible in the least amount of reading, because we don't wanna put out a 20 or 30 or 50 page document that nobody reads. So really meant to mimic the original Jericho commandments and the successes of that. And so with that, the call to action here, we'd love to have you involved more in the security form in the Zero Trust Architectural Working Group. So if you're interested in that and you've got the time and cycles and experience to contribute, we'd love to have you there. The core principles by paper itself is available. So there's a link for that there. There's a LinkedIn Working Group, a LinkedIn for the Zero Trust Architectural Working Group that you can join. And if you have any other questions, feel free to contact our security form director, John Lindford. And with that, I thank you very much. These, this has been an introduction to the Zero Trust Commandments. Thank you.