 So in this session, Mark will focus on the Zero Trust Core Principles developed by the Zero Trust Architecture Project Workgroup in the Open Group Security Forum that we've been hearing about. So a warm welcome from the Open Group please for Mark Simos. Over to you, Mark. Thank you. So thank you very much. This is an honor to be here amongst some of the original Jericho Forum folks and great colleagues that have been working with in the Open Group. So I'm going to be sharing information about the core principles themselves specifically discussing them just as a quick recap for those that may have missed Nikhil's excellent session. You know, the world has really become much more complicated, very much recognized by the Jericho Forum and all those efforts there. But even more intensely today with with APIs and the ability to generate it. They're sort of this interesting dynamic that if it is not that costly or difficult to add another instance of something you're going to find it sprawling. And we see that with documents with files with USB sticks and SharePoint sites and now we're seeing it with apps and APIs as well. And so the world is at a scale now of, you know, the sort of virtual electronic entities that have to be secured on that are, you know, each important to the business in their own way. You know that it's a really, really challenging world, especially given the world changes and all the other things as Nikhil mentioned earlier. Of course, remote work is now normal. So blasted what was left of the confidence that we could keep ourselves secure under perimeter. Those partnerships competitors and communication patterns and national interests and regulations are also changing very quickly, which are challenging businesses as well. And this in this leads to, you know, when you take a look at through the lens of, you know, how do we modernize security, which is many ways, you know, kind of a kind of definition of zero trust. You know, is all the things that know we needed to modernize for a number of years that have all come together and now being organized. And you need things like automated policy enforcement so you don't have to worry about manually applying things when stuff changes because it's always changing adaptive identity management that can handle these role changes of the mentioned a person that becomes a vendor and then a supplier and then a contributor and then a competitor in a matter of short period of time. And then of course, you know, the way I like to think about zero trust that helps bring me a lot of clarity to it is we're not trying to pull the users and the assets into the realm of it and security and secure the way we want. We're actually going and taking the security to users and the assets and where they are. And those, you know, those are users, those are the data that's the applications that matter to the business and and the end users and the customers. And so it helps you better focus security resources and better monitor when you're living in that space as opposed to artificially trying to pull them into the IT and security paradigms of times past. So how do you actually manage this, you know, again, other similar to the field diagram, you have to have a consistent policy that applies across it and great for intelligence, whether and applies it to the data directly to the apps and the API access. And so you end up with this sort of, you know, two different kinds of preventive controls. One is sort of the expected sets of access and then the other is the sort of unexpected types of ways that it could possibly be used. You know, whether you're bringing security up to the data or the data value down to the efficient scale of the way that you can provide security costs. And then, of course, the visibility sandwich of the immediate moment by moment stuff that's happening in terms of the attack space and the project that are hunting, etc. Of the attackers and then the ongoing sort of longer term governance and continuous improvement. Again, both consuming real time data, etc. But with different objectives and wanting to get rid of immediate threats and risks and the others we continuously lowering the risk level of the organization and sustaining the gains that we know. So that then leads us to the principles themselves. We wrote these down into about five different categories. The first two are organizational value and organizational risk. The next one is governments. And then the last two are the technology and then the security controls. And so I'll be covering each of those and a little bit depth. And then talking a little bit about the, how we map to the Jericho forum. And Steve's been an amazing job of kind of describing some of the history I've learned in lunch in the last session. And so I wouldn't be able to do it nearly as much justice as he could, but I'll give a quick overview kind of how those. So the first one in organizational value size of the text is actually a little bit bigger because there's only one. This is extremely important. This is the, this is the business driver for zero trust in my mind, which is that. In order for security to enable the business next actually enable the business, which is getting out of the way so that users and devices can do what they do naturally and work where they need to work in a place where. You know, the end users feel creative and they're able to meet with the business partners and they're able to meet with customers. And they're able to do business without being better by all the security pain and inconvenience. And so really working in any network in any location with the same security insurances is the goal. Obviously, you have to take into context of this person just randomly drop into a country that they've never been to before. All those things need to be taken into consideration, but the answer is not no, because you're not on the corporate network. So organizational risk is very much about aligning to the organization. So making sure that all of the security efforts and elements that are being done are being done in the context and in the frameworks in the mechanisms, the processes, et cetera, of the organization itself. Now, sometimes organizations have a mature risk model and framework, something based on fair or or another framework. Sometimes they don't. So you have to kind of apply these as it makes sense and as you're able to. But ultimately you've got to align and support at a minimum the organizational goals and the risk launch and threshold, even if that's not formally defined, you know, in terms of dollars or specific numbers. The security goals and security itself has to align to what the organization is trying to accomplish as a business as a mission. And they have to be able to align to that risk launch and threshold. So that is very, very important. And then the second piece is really in support of that. If the organization does have that risk framework to be using that to be fitting the security within there. So that the things that these business leaders have gotten used to that they adapt to on a daily basis and it's part of their decision process in their conversation. They're going to Franka. That is what security should fit in security should not be operating outside. Yes, security has some challenges with finding things. There's really a massive step in the right direction for allowing that. But it's very difficult sometimes to get data security because you're dealing with the human variable that on the other end the attacker and what it costs them to attack it will be gained from it. Also, security is a little bit tricky to integrate in there, but it is well worth the effort to go ahead and put that in there. So you can get that in there. Number four there. You've got to look at it over the course of the lifetime. So when you look at the organizational risk, you've got to look at the data and consider what it would be during its entire lifetime. For the transaction, make sure it's not just a point in time, but it's actually covering the entire thing and all the players in it. And then the relationship that there's a business relationship between two organizations. The risk of the sound of transfer of data and whether or not we provide the files and sort of encrypted phone home for the key kind of way. You need to be looking at it through the entire life cycle of the data relationship transaction so that you're not just saying. Well, we have TLS of the session, but it's unencrypted on the rent. Or yeah, the data is encrypted on our devices, but then I got emailed out. Right, you have to look at that risk for an end view so that you're really thinking through that business risk. So the governance piece, there's quite a few here and the governance by the way is in the middle deliberately that was a specific choice, because in many ways it provides a bridge between the business and technology. It should not be a point of friction should be a conduit and a channel that enables better conversation and discussion and process and rigor and not losing things. But it is very much a bridge. So the first thing, this is a little bit on the bold side, but the governance needs to reduce complexity. It needs to help simplify a lot of governance. Sometimes something a lot of governance, but frequently governance can increase complexity and add process for the sake of process. And it's very important to make sure that governance is gold with simplifying things to make decisions easier for business folks that are making list decisions and in which decisions on which opportunities to pursue. Want to make that as simple as possible for them for the security folks for the IT people. So the more that governance can encourage the reduction of complexity better because complexity is truly the enemy of security with complexity creates confusion and confuse people do not make good decisions. And so governance must reduce complexity and of course the threat surface area and be continuously reducing that. Next one, six, the governance frameworks should be guiding people process and technology that languages lifted directly from the original director form. And with clear ownership of the decisions. The policy and the aspirational vision so governments should be helping guide people make them help them make good decisions clear decisions as fast as possible. So that they don't have to consider a whole bunch of factors that the more that you take it depends on the better. And you can do that through decision ownership of this person makes the call man. You can do that with policy. This is the way we do things. We made the decision enough times that we know this is how we want to do it from now until we change the policy. And then aspirational visions can also help with that guidance for bringing that. The more the governance brings that clarity the more to reduce complexity and making more secure. Policy some security. I have to not directly to the organizational mission and risk security for security. It's safe is points security must be done for the purpose of organizational risk. Without the business there is no security. It doesn't matter. So you have to make sure you're in line to that organizational mission risk. And as much as possible favor that automated reporting because the metrics that you measure. If you have to do it manually they're not going to get that they're not going to get measured and not going to measure. So you want to make sure that's as easy as possible. And that alignment is automated and connected to that organizational promise. Governance frameworks. You know, governance needs to support shifting security close to the asset trying to do this as a big bulk network does not work. You have to get it as close to the asset as possible. Now you're going to need to group your efficiency. So, you know, all things of a certain type all projects of a certain sensitivity. There's a lot of things you can do to create efficiencies and groups using that business lens using technical lenses. But doing it with a big network doesn't work. And we want to make sure it is as close to the asset as possible. And the groupings that we do are then born of that knowledge of the asset as opposed to knowledge of the technical environment. So you want to shift the toolbox, excuse me, shifts the technical stuff to toolbox to help and really focus on the assets themselves individually or as a comment. And then nine all symptoms of integrity and trust level must be explicitly validated to the great possible. And this is really where the name of zero trust comes in, which is you have zero trust in something that explicitly validated that trustfulness. And so the integrity of the trust level has to be explicitly validated. You cannot simply assume. Oh, it's on the internet as well. So, that's what I said. And then next we have technology and security controls. So security mechanisms must be simple, scalable, pervasive and easy to manage that may look familiar to some of that is exactly copy pasted from the original Jericho form. That principle has not changed one Iota. It was beautifully written as elegant simplicity is critical scalability. We cannot do something unless it's automated, etc. to be scalable, because it may not get done if it's not able to scale. If everything works here, but oh, we forgot scenario nine and 10, then you're really not as secure as you should be. And of course, easy to manage. Because if it's not easy for the IT guy, well, now they're going to work around it. If it's not easy for the security person, they're going to work around it. If it's not easy for the business, they're going to work around it. They have to get their job done. Their job is not necessarily to make all these other stakeholders happy that are within your job is to make money or get their job done. And so it has to be as easy as possible, simple as possible, scalable, pervasive, so that there's only one way to do it. And that way is easy. 11 access to systems and data must be granted only as required. This is another way of saying we switch. So you say least there is a pretty person gets it that explain a little bit for, etc. outside of security, but pretty much systems and data have to be granted only required. And that is not just the traditional element because we've the traditional view of that has been, hey, I only want to put you in the certain groups and we've heard on some of the previous sessions about the privileges of growing as some of the senior because they never did. It's not a group. So just out of the rules. And that is very true. And that is one very important element of this privilege, but we've also learned that there is sort of a one simple trick. There's, there's another approach that you can use to bring down your tax surface, which is to limit the time so moving to adjust in time such as a privilege identity management privilege access management. The more that you can provide the services and privileges rather on demand as needed, you know, throw a little workflow on there for the, especially for the super important things. But that the privileges come on demand at the time, even if they're a member of a lot of groups, and they potentially have a lot of access. You've, you've reduced it a lot if they have to ask for those permissions each time you use them, you know, within reason to get too much in their job and interrupt their job too much. But the more that you can do that, the more that you can keep those from being standing privileges and keep those from being standing risks, really. And attackers would essentially have to advertise their intentions in order to get the privileges they want. We can't just silently use this to learn that it's very important to look at these privilege through a number of different lenses, including which privileges you're entitled to at some point or potentially and then also a time value. So those two that combination of the two the just enough access just in time access tend to be a very powerful way of practically bringing you closer and closer to that least privilege your life. So next 12 all assumptions of integrity and trust must be explicitly validated to the degree possible. This sounds a little bit repetitive the previous one. We take this out and maybe one of those that's very competing. These are almost final. So these are getting really close. We'd love to have more participation. There are some discussion in the chat window of different folks that can participate. We'd love to get more folks and help finalize these. But in this case, this particular version of bears repeating that all assumptions and integrity and trust must be explicitly validated to the degree possible. There's, there's obviously this ongoing need to sort of instrument devices that are instrument users that will bring in more data sources. So it's easy for a normal user to do something is very hard to tackle to mimic. So we need to have that kind of that duality. And so that is going to be constantly improving to expect this line to move forward, but to the degree possible by the technology available. We want to make sure that we are making sure that the integrity and trust level are explicitly valid. Validated in all for all those different assets for all those different equestries and principles. So that they are so that they're proven. And that brings us down to the technology section. So reinforcement, we had this at the higher level, the risk level of looking at the lifetime. We also want to look at this to the technology lifetime. Confidential integrity must be maintained for the lifetime of the data, the transaction relationship. We want to make sure that again, we're not protecting just that moment in time or just that portion of the transaction. We're just that one type of communication partner that we're looking at this over all and at the full life cycle. You know what happens before what happens after look left look right is our softwares to say. And let's let's take a look at the full life cycle of those and make sure that we have the controls in place. You know, from the beginning through the middle, all of its iterations for mutations, all the way to its end of life that we are making sure that those assurances are there. And it's not just, oh, yeah, we forgot to protect that. So we want to make sure we're very intentional. 14 data centric app centric must replace network central. So network is not bad. It is not wrong, but it is it's necessary, but it's not sufficient. So you want to have network controls in place. You want to have firewalls in place, but you cannot rely on that your business on them, and you cannot make them the paradigm so much so that you interact business functionality. So data centric and application centric, those tend to be the stores of business value data is the intellectual property processes and pieces there. Appletations are often extremely valuable things and when they go down the business loses money. So those tend to be the technical instantiations of business stores of value. And so that must be the center. It's very much a business centric thinking, but in most cases it lands on data or ads to provide the business value and store. And so we need to make sure that we're looking at it through that lens as opposed to those network centric strategies. We have to look at the entire life cycle. The end user flight in US. And we need to reduce that threat service by reducing data rest. I mentioned tokenization specifically, and I think a little earlier I mentioned you either have to bring the data, bring the security up to meet the needs of the data or bring the data down to meet the security that is possible to provide. And of course, you know, the more that you can reduce problems, you have to solve the better. So if you can do value tokenize on that data and make it something that's easy to secure, life is good. Take the one copy of social security numbers or the other P and I, whatever it is, put it in a highly secure database and give everybody else a generic pointer to that. Then you're in a much, much, much better place because you have less databases, you have to bring up to that highest level standard. So the more that you can apply that kind of thinking with that. 15 asset centered approach based on the asset sensitivity. So this is very much recognizing that you need very much related to the previous one that the asset centered approach has to be driven there. And you got to look at the sensitivity of it and perform prioritization of what we focus on first, next and later by how much impact it has and what the sensitivity is to business. And then you got to get that controls harmonization in place. So with that, let's speak a little bit about the math things to the Jericho. So, broken down pretty much into two different slides because we ended up with about 14, 15 of these things. You'll see that they are very, very closely related to the original Jericho forum. One inspired quite a few. And quite a few can end up processing into one, which is very much a whole zero trust that no work in any location, any network in the same security services. And so the the linkages between these are quite extensive. The one that I will call out that note here and I think Steve mentioned earlier devices and applications must communicate using open secure protocols. So it's a little very much a truth, but it is not really a part of the zero trust solution or architecture per se. And so we chose to and quite frankly the open idea a lot. And those kind of things ended up that vote is pretty much sale as far as current generation technology. And so, you know, like to think and hope that the Jericho forums and we're working with the open group has influence that. But ultimately, those things are out there and running and it's not something that as an organization that is consuming this has a zero trust strategy is building it. It's not something that there's a huge amount of influence over so we decided to emphasize that one and in non included. So for the most part, you see that these things are very closely linked to the original Jericho forum commandments. Retro trust levels. You know, it has to work outside of your locust or a control very much related to one as well as a time piece because time changes. You can control. So your patient privileges. And then on the other page, we actually address us. We jump to the second page. And so, you know, again, here's that direct copy security mostly simple simple basis and easy to manage 100% direct copy based. And all of these things do the same. So you see 11 here. I was a little bit more of a technical controls control. So it has to be secured and when stored in transit use. And that may explain to several. So, ultimately, you will see that there's a lot of. And the zero principles are very much an evolution of the thinking. You know, again, for the modern day, a little bit more emphasis on business and governance. There's much more of a representation of what the security role is as of this moment and as we anticipate. So with that, I think I have used up my time and I thank you very much. I look forward to questions and access. Mark, thank you very much. Great job. And as you say, your questions are going to be in the panel session, but. Thank you for taking us through that through that project. And this, as you said, you know, these, these principles are not quite published, not quite final. But getting close to at this point, and it will be great to get get more people involved. So, random, virtual random, thank you for some mark sign us.