 Now time for our panel and all our speakers so far this morning are joining us. I can see you, John Linford, you're there already. Welcome back. If our other panelists are able to go on video, it makes it more personal. If not, then let's shout out that you're with us at least. So, Mike, are you there? And also, if we can just ask Mark, if you could do, I don't think your audio is connected. But if all you could go on video, that would be great. That's great. So, Nick, you're there. Wonderful. And, and Mike, great to see you both. Thank you for your. Thank you for your videos and we're nicely on time too. So. While Mark gets his audio connected, got a couple of related questions that came in early. So, first one. And I think I'll, I'll put it to you, John, because you did actually make a reference to it. John Linford. How does the work that we're doing in the ZTA work group at the open group compared to the NIST work on ZTA? And if you can take that as the 1st part of the question and the 2nd 1 was more generically about what other standards organizations might we be working with in the working group? Both really good questions. The work with NIST, and we actually submitted feedback on, and gosh, the document numbers have escaped me right now. But NIST has put out a couple of the different documents around zero trust, zero trust architecture is a working group. We actually submitted some comments on that document, which after their initial draft, it was good to see they took some of our feedback. But we felt that their initial approach was still very network centric and we were focused much more on an asset data centric approach. So potentially differences in just how it's being expressed. Yes, SP 800 207 I just saw that come through the chat. Thank you. Potentially just different ways of expressing the same concept. Or the same emphasis the same goal, which is really where that landscape guide is going to hopefully help remedy that. NIST are of course, silver members of the security forum. I know that mark you've got a really close relationship with a couple of individuals at NIST. I'm definitely still keeping in touch and tracking what NIST is doing in this realm, especially since they had a pretty big burden placed on them with the the May 12th executive order. Other organizations that we're figuring out collaborating with include the IEEE UK has a national cybersecurity center. You know, in a keel, you're in communication with an organization in India. So definitely trying to make sure this stays global. Great. As we usually do at the, at the opening it be our approaches to collaborate with others rather than rather than reinvent the wheel or work on competing standards. So, thank you for kicking yourself on that. A specific standards related question before we get to some more general ones and that's, are you considering reference to IEC 61131 or ISA 84, which are safety standards as a basis for failsafe principles? Maybe if maybe that's a good one for Mark to hit if he's on audio yet, if not. I'm not specifically familiar with those particular standards, but it is something that we can definitely look into, especially as IT and OT and IoT come together. So really appreciate the pointer on that one. Okay, so that will be in the, that's in, in the chat and I'm sure you'll pick that up, John. To look at. So, let's move to, to more, more less other standard specific questions. So, question came in very early, should I read too much into the different expressions of zero trust as in zero trust, zero trust architecture, zero trust network architecture. And related activities with names like software defined networking software defined perimeter. So, any, any comments on the, on the various, I've heard them myself, the various versions of zero trust with something after it or on its own. Anyone want to want to take that one. This is Mike, I can take this one, you know, as a practitioner out in the field, myself, I've gone through this journey as well. Right. And at the base of it is all zero trust. Right. So that's, that's what's in common across all of those terms. I think that's what we're really focused on with the work here with with the open group. I think the various deviations there of that there's certainly something to, you know, when you talk about a zero trust network architecture, right, you're, you're kind of assuming you're specifically focused on the network side of things. Um, with the others, you know, zero trust architecture versus just zero trust. Again, you, it depends who's using the term and where to, to, you know, delineate between a zero trust architecture. Are they really focusing on the, the, the architecture of it, the, the building blocks and so forth, or are they really talking, you know, sometimes you'll hear zero trust architecture where they're really referring more to the mindset. Because McHeal just presented, you know, zero trust is, is more of a mindset than anything. So all in all, I would say my personal opinion is not to read too much and do it, you know, different vendors and different organizations and to, you know, use one term to kind of rally around, but they're all driving at the same concept of zero trust. And if I can add to that, the thing that I found is that when you look at zero trust, ultimately it's a transformation that goes all the way up to the board level and the way security interacts with that. The business leaders, the technical leaders like CIOs and CSOs all the way down through practitioners, directors, managers. So, you know, ultimately zero trust is going to look a little different for each, each role in the organization, each stakeholder. So it's really important to recognize that it's not just one magical thing that everybody looks at and says, oh, that two by two by two square is a cube and we're done. It's really going to look differently when you manage a business strategy, when you manage a technical or security strategy, or when you're actually, you know, responding to incidents all day or patching vulnerability. So it really does look different. Okay, great. Thank you. Next question. Does ZTA follow a sovereign identity based approach? That one that to you, Nikhil, or anyone who wants to take that? Does it follow a sovereign identity based approach? I'll grab it. Can you hear me, Steve? Yes, we can hear you Nikhil. Okay, so a couple of things actually I wanted to answer two things. One was the last question and then I'll come back to this one for some reason my audio was out. So it's trying to speak anyway. Long story short is the main significant difference between what zero trust is and our traditional perimeter centric models of security is that zero trust is really a data and asset centric model. So you're protected at a very granular and modular level so you can adapt to change. And the other major thing is it's data centric so you can have the flexibility. That's kind of what I talked in that example in ACME Corporation. You can have the flexibility for data or for organizations to operate in an environment of assumed breach to be able to share that information across trading partners and organizational entities. So just to clarify then thirdly, because of it's larger than just securing a device or an API or an application. So it's because of the difference in the mindset. Traditionally, we've been very parameter network centric to this kind of an approach. Which is driven by market drivers by the environment we work in. Because of that difference it's more in practice. It's really there's a strategic aspect to it. And there is a framework aspect to it. There are many different moving parts to what Mark called out in a moment ago. So I just want to clarify that and speak a little bit to that last question because I keep hearing is it another kind of network. It's not. Speak to that for a moment now. Secondly, with regard to self sovereign identity. The short answer is, yes, we talked about it and Mike talked about it in the concept of in the reference architecture. We have the concept of digital identity. Digital identity. I refer to it as a party person organization model kind of viewpoint. It's closely tied in with self service. I mean, with the self sovereign identity and the concepts of the things which with the Fido. A forum and organization are coming out with and so on and so forth. And we are definitely going to be incorporating it incorporating it. In our reference architecture initiative and I don't remember the name of the gentleman to put us out. But if you're a member of the open group, we'd love to have your engagement because this is these are things. Which are going to drive what we do. Great. Thank you. So we've got a few questions coming in about the about the principles and the and the, the, the commandments reference. So one from a name I'm very familiar with Craig Heath. Welcome Craig. I've been around our security forum for a long time. So he says the scope of zero trust architecture seems similar to the scope of the Jericho forum had, especially considering the access to data section of the Jericho forum commandments. Could the panel please compare and contrast these two initiatives. I think the best way to say it is the Jericho forum was decades ahead of their time and their thinking. They were also a little bit more focused on that that breakdown of the perimeter. So maybe a little bit of a narrower scope zero trust is sort of this much broader kind of entire organization. That really complete granular shift to securing the assets, securing the data. Mark, you want to pick up from there. Yeah, I agree with that completely. And I just add that I. Well, the Jericho forum really was sort of that that first initial recognition, the transformation, trying to drive and catalyze that change. And, you know, in many ways, Trump is the change on the other side of it. Sort of like the gateway versus the new land or the bridge versus the new land. And so the scope of this is pretty similar. But with the zero trust worker really trying to take a lot of the lessons learned from the Jericho world, including the commandments and the clarity that they bring. And effectively help define this new world and kind of reinvent security. And as opposed to just a modification of what was there, it's truly, OK, what does this new world look like? What does it need to look like? And what, you know, what is involved in security, you know, scoped for the current time? You know, because we do have it, which is of course the most important thing, the most frequently attacked thing in a lot of organizations. We also have operational technology that, you know, physical life and safety and literally lives are on the line. If one of those machines, you know, over revs or blows up or stops supporting someone's heartbeat or whatever the case may be. So there's there's a lot more that's becoming at stake with the IT systems that has happened the past 20 years. And so there's there's sort of a natural increase in scope there. But in principle, we're trying to accomplish the same thing. We're just kind of doing it based on on what we understand of the world today. Right. Thanks, Bob. Certainly, from my perspective, Zero Trust is a lot easier to say than deeper immaturization. So he's to always try and get that out without stumbling in the Jericho forum days. But as you say, John, there was some great thinking there that was ahead of its time. So it's great to cycle back and reuse some of that thinking. So sticking with the the commandments theme, commandments sound like a straw man. Virtualization has taken hold of most modern technologies. If each piece needs to have an IAMS in them, which will increase its complexity and burden and users with lots more authentication and authorization steps. It's easy for social engineering attacks. How, how does this approach address these issues? We've got a lot piled in there. So there's some extra authentication and authorization steps. Social engineering attacks. I can see you're smiling, Nikhil. Any, any thoughts on that? Sorry. This is a conversation Michael Lizinger and I had a thing on the Friday before we were recording anyway. So basically, firstly, yes, it involves, it involves the ability to be able to expose your capabilities and your entitlements at an asset level. But it involves policy based administration. And that's why we talked about adaptive identity. I know Mike mentioned it earlier. And I think I mentioned it also as part of the ACME review, right? So there is a concept there of adaptive identity where you are definitely going very granular, like a microservice that is going to be reused and you're addressing your identity at that level. I understand the panel and the audience members ask that makes it more complex. And so there were some examples that given in the ACME Corp scenario where what you do is you still use that concept of security zones where you define it based on some higher order principles like the grouping based on a level of trust or grouping based on the business process and data classification and level of trust. There are certain core things. After that, you come down to a little more fine grained activity and you let that decisioning occur at that individual network of one level. And now what happens is now you have the flexibility and now you can switch it through technologies, which I don't want to get into because that's different for each in a scenario. Mark, for example, I talked about, you know, there's no one size fits all. But there are very rapidly evolving capabilities for being able to use the another methods to predict and help define what kind of access should be made available. So being able to manage what would be more complex environments, right? And if you looked at the initial part of both Mark, Mike's and my presentation, we talked about growing complexity. One of the characteristics of the digital age is complexity doesn't go in a hybrid cloud environment where your partners keep shifting and changing every other day. That's the reality of life. So you have to think about it in terms of how do you reduce that threat landscape and how do you actually manage that? I don't know if I fully answered the gentleman's or the lady's question, but, you know, I hope it gives you some context. Thank you. Thank you. It's great. Anyone else? Any comments on that before we move on? Just building off of what Nikhil shared, right? And this is all, you know, there's also technology coming to our help here, right? So, you know, Nikhil touched on it. I mean, centralized policy-based management for those multiple systems, right? So you no longer have local, you know, Authent and AuthZ down in every service that you have having to, you know, work through its own fine grain, as well as just automation, right? So, you know, it's something I'm certainly grappling with. How do you keep up with just the complexity and policy management? And there are a lot of technologies, you know, building in machine learning, recommendations engines, and so forth. On top of, you know, the key I have found is a simple but, you know, pragmatic layering of security controls through, like, trust levels. So what are your trust levels? What are your data classification levels? Working that through as many of those centralized and automated systems as possible gives you a much better chance of working that security down into the, you know, the fine grain layers that Nikhil described. Right, right. Thank you. I'll add one more. Steve, you go ahead. I was just going to add real quickly that, you know, the technologies of the cloud are really one challenging and forcing this to happen, which is kind of why Zero Trust, I think, became very popular. It's also a key enabler of it. You know, those machine learning requires being able to process over large data sets to find the normal baseline so you can get the probabilities and identify the anomalies. So it's really important to understand that the cloud technologies want a driver of forcing this to happen, but it's also an enabler to make it possible to deal with in a way that the Jericho Forum really didn't have at its disposal back then. Right. Nikhil? Yeah, I'll just add one more comment. A common concern that a lot of folks will have, and I know that Mike, for example, will have it, is you're going to end up with federated IAM environments at any access management environments. So the reality of that is that's part of the reason why we go down this concept of adaptive access control. And part of what will come out of the reference architecture initiative is going to be standards and sub standards or references to existing standards as we lay out an overall detailed reference model. So again, there is a method behind the madness that's driven by what the world is today and what it's becoming. And it's a different world than what it was maybe 10 years ago. Right. Right. So we talked a little about the relative, well, the complexity of life nowadays and the relative simplicity maybe of this approach. I'm going to maybe aim this one at you, Mike, because it came in while you were talking. And the question is, can you define simple? Having been in the industry for 30 years, I always raise an eyebrow at the word. Java.net Node.js, for example, is a simple tool to use in development until its dependencies hit its release streams. So any comment on simplicity? I believe I used it in the context of trust levels. You know, I talking to some of my peers at other large organizations that have tried to define things like, you know, trust level and data classification is there's the tendency to kind of dive in and try to create this, you know, a multi tiered stratification. And that almost always crumbles pretty quickly under the weight of a very complex type of enterprise, right? So it's kind of finding that balance of what's going to be sustainable, but with enough granularity or enough levels to really drive the business use cases. Overall, I would say, you know, comes back to, you know, the architecture concept of just purposeful complexity. You're going to have complexity. I mean, the Node.js can be very simple until it actually hits the, you know, hits the oxygen out in the real world and becomes very complex. So thriving that purposeful complexity. I mean, you know, being being a nationwide, we have 20 some different business units that all have their own business goals and objectives. That creates a certain complexity. But what I strive for with my teams is, you know, where are we going to have that complexity and then where are we going to make other things very simple to key off of. You know, it's a very good question on what a simple mean I think back to where I shared it before it was being very purposeful and especially kind of, you know, walk before you can run with some of these concepts, right? You know, your trust isn't, it's not all or nothing. I know it came out in some of the other speaker talks earlier, you know, just getting to start in on it and things like data classification and trust levels, starting to define those in a more simple framework before you start adding all the edge use cases. Time in here as well, if I could. We had this debate, I think on Thursday of last week we were looking at the core principles and we got to the simple and pervasive core principle and we immediately went well that's probably not the best way to say that actually because define simple, which split into Mike just mentioned of the purposeful complexity as one around as well as one around practicable and sustainable. So we realized, yeah, trying to put simple and something like a guide or around implementation may be made it harder to understand than it needed to be. Right, right, makes sense and if I can just one quick comment is that simplicity, simplicity is critical as you interface with people. So whether it's the end users, whether it's the administrators that are making day to day decisions, whether it's the security people that are monitoring. I mean, the systems by themselves are complex. There's, you know, trillions and more of ones and zeros that are arranged in all these different patterns. But ultimately, you want to make it as simple as possible as it hits people and you want it to be consistent. And that's kind of the key is is people that administer that understand it that design it that use it. The systems themselves should appear simple so that it's easy for them to make a decision instead of overwhelming. Great. Thank you. So, here's a question that I'm pretty sure I know the answer to but but may lead to to something else is ZTA a decomposed a model of toga could it be. Obviously, when one of the things we know for the open group is our toga standard. And we're talking about zero trust architecture and in the architecture space. So I could talk to that a little bit since I guess I represent architecture form anyway, but separately. The thing is, basically, yes, it's not necessarily decomposed version of toga, but I believe it will be woven into the next releases of toga that will come out over time. Just like we did with the SOA practicality guide when we came out with the SOA standards eventually aspects of that have been woven into toga over time. And I believe that the world has changed and information security is now sufficiently important that it should be and is front and center and almost every architects and frankly even every business leaders mind as they execute right. If you have a great company and a great marketing and sales organization, and then you have a ransomware attack where you can't do business anymore. They're done. And so literally the world literally has changed and the prioritization has changed in today's world. And that's part of that again when I go back to when we talk about simplicity and zero trust what we're trying to do is say look, it is a complex world. We use opinionated in a prescriptive guidelines to try and reduce that and make it into smaller buckets and chunks of work that you can deal with. So, you kind of make it into simpler may not be totally simpler empirical. And that's part of that whole conversation as we go forward. You know, yes, this is there. It'll be embedded into toga for and DP Bach and other architectural frameworks and standards. I believe there won't be anyone which won't really consider zero trust as we move forward. I hope that answers the question. Very much so. Thank you. Yeah. No, it's a great answer. Next question. Can you give some examples of standard interoperable device trust models. Standard interoperable device trust models. Any takers. So we had published something last year on this in in a publication and futures of technology conference sits out in the spring of our lag publication notes or proceedings or so on so forth. Right. But basically the gist of it is, it's not that simple. When you define. So when you say device level, it becomes a question of defined device. Right. So for my crampier loop is also a device in a utility. The environment is also a device using modern sim architectures is also a device using much more modern IOT frameworks is also a device and I can guarantee you in any non trivial sized organization. You have all of these devices there. Right. And you can say I'm not what do you how do you define identity for a four micro ampere loop. I'm an electronic and telecom engineer apart from being a computer scientist and tell you it's really hard. So that's why we call it a strategy and not a fantasy. So to speak, it's a strategy and it's a framework. There are some standards for interoperability. But keep in mind that in the real hybrid world. Those standards can only address that hierarchy or that generation that you're dealing with and they may not really address prior generations. Yeah, as an example in the Microsoft world with conditional access, which is our zero trust policy engine. We boil down user trust to low, medium and high. There's a lot of complexity, machine learning and waiting and crazy stuff behind there about all the different factors and stolen passwords and we can just all sorts of hundreds of factors there. And then the same thing is true on the device side and we boil it down to a low, medium or high and then you can essentially create a human readable and human set up policy on low, medium, higher devices do or do not get access to these resources. But I don't think, you know, simple and interoperability and open are quite all able to converge at this point in time. Because of, you know, how relatively new it is, you're going to see some mature vendor offerings like Microsoft and there's probably a few others out there as well. But getting to something that's like a comprehensive standard that's also simple and interoperable, maybe a few years out, just as a guess. Okay, thank you. A couple of questions here on potential content of the models first so I guess two parts to this. I'm managing two questions together I guess. Do you see that there will be specialized reference models for public sector or municipal entities is the first part. The second part is, should buildings or facilities be represented in the model for specific more secret use cases. So do we see do we see public public sector specific or municipal entity entity specific reference models and should we be including buildings and facilities in our model. So something we've had a conversation about before was, and we're decided at this point exactly what the final reference architecture will look like overall. We do plan to utilize the snapshot process with our initial conceptual reference model and then sort of build it out. The idea we'd had before was to put something out like an 80% reference model that would allow for sort of some consistency across a bunch of different sectors or industries so including public or utilities that they that may then allow contribution of reference implementations for those specific industries to sort of give those other perspectives. So if we're still working on that initial conceptual model to begin with, we haven't quite gotten to that level of detail yet. But public sector utilities, OT have all definitely been been points that have been brought up in conversations. Great. Yeah, and this, as you say we're in that with, we're still not quite there on that on knowing exactly what's in and what's out at this point. I had one quick comment. Yeah, ultimately I think there probably will eventually be industry specific things, but the big blocks the important things that need to transform from sort of current classics strategies. Those are universal across industries there will be refinements and specifics I suspect over time, but I don't think there's any urgency, or need to wait on those to get started because I think the first steps of most industries journeys will be extraordinarily similar. I'll add a little bit more color. Thanks, Mark. By the way, so I'll add a little bit more color. So what Mark said. I'm in violent agreement with that that's going to be something which there's going to be that 80% which is common to everything and that's going to be what we'll cover to the reference architecture level zero and level one, as well as part of the practitioners guides. But if you look at the slides that Mike spoke to, there was a slide which laid out different levels of of the reference architecture. And so there are specializations if you want to call it for different elements and then we have elements of it going down to a much lower level of detail. Which would be more like almost like an RFC model and we will be reaching out and engaging everybody to make sure that there's global consensus on that. Great. Thank you. Well, keep keep the mic on. Nikhil because this one's this one's aimed at you. It's about your ACME call. So it sounds like the presenter ACME call is saying out with the perimeter security and in with ZTA. Wondering how data centers with advancements in edge and folk computing devices can be secured. We can't. I can't hear your audio at the moment, Nikhil. So what happened? There you are. You're back. Okay. So basically, the couple of things. One is just about a week ago and this released or maybe a couple of weeks ago released a document which talked about assume breach. So a lot of these edge devices, they basically said that all agencies should assume breach. And I would say that pretty much every commercial organization should assume breach in the higher ed sector. For example, malicious actors are having 56 days on on average on on a compromise network, which means almost every higher institution before they execute their attack. 56 days. They're watching monitoring and planning their attack. Think about that. All right. So what I'm trying to get at is the reality is, yes, you're still going to have levels of trust and you're going to have your perimeter to log in and log out and authenticate. But you're using those data centricity, asset centricity, network of one approaches to be able to manage and operate in that environment of assume breach. The president's executive order, for example, basically took from what we had in our core principles paper. If you were to read the core principles paper, you'll see it right there. Literally. And what it's basically topped up is the ability that we should be able to work on any network anytime, which basically again boils down to you. If you went home and you had your work from home when COVID started, you didn't have an option even to buy a laptop, just give it to your employees because we were out of laptops. And there were none tripping. And so basically you ended up with what kind of trust level did you have? It's that simple. And there are reasons why we're bringing out these different approaches in our recommendations. Because again, that dynamic and the rate of change, and this is not really a COVID thing only COVID accelerated it, but this has been going on for the last decade and a half. And that rate of change is only accelerating. It's not staying at its own steady pace. It may moderate once in a while, but that's because the market is changing. It's not because people want to change at a faster rate. And those are the reasons why we have a lower level of, we talk about secure trusted zones. And the reason is when you have secure trusted zones, you assume that maybe two or three of the zones may be breached and what you lose is not of high value. We talk about low value and high value data so that the thief basically doesn't get that high value stuff. Now, that high value stuff you put into your highly protected environment with only maybe 10 users instead of 10 million users. And you can apply separation of duties. You can have your firewalls driving the flow of traffic on the network and you can watch it through every perspective. That's what you try to do to minimize your risk level. I don't know if that helped answer that person's question, but it's not that you get rid of the perimeter. But again, to what Mike and Mark spoke earlier about, you kind of manage it and say, keep it simple and then you focus only on those things. That's what I spoke about in the ACME example to focus on your crown jewels and then expect that there's going to be threats in the other areas reduce the value to the attacker on those areas. And use the isolation reduction of blast radius to be able to let's say you do have an explosion while you reduce the blast radius, which means if you do have an incident. The person asking the question is confirmed that you've answered it. So thank you. We've got time for one quick answer. I do want to get to it kind of takes us in a nice circle for where we started off references to the NIST work. A comment that it would be great if what we do was was aligned with what NIST does, which is, I know, certainly our intent. But a specific specific question, which is, what is it that the the unique what is the unique perspective or understanding that the open group work on on zero trust is bringing, given the work that NIST has already done, is it how corporate roles perceive zero trust, perhaps, is that one of the differences. I know john you said earlier that there was maybe a different, different focus between, you know, I said in data, but Yeah, I think I think part of it is, we're still that very gung ho about asset centric data centric NIST still is slightly more network centric approach to really sort of the same end goal. But really the benefit that the open group has the perspective that we're able to give and I may be a little bit biased speaking as staff of the open group. So we are able to bring together those end users and those vendors into the same space to have to have the discussion, have those debates to align whereas NIST may be coming at this with a little bit more of a government perspective, especially since being mandated to kind of do this work around this, if they were on it already, but the executive order now they've sort of been reinforced but you know get this done. So we're able to bring together the, you know, the people who are going to be using this, the vendors who are going to be selling these products or offerings into the same space to really focus more on sort of those individuals. I'll add a little couple of comments then Steve couple of other things I'd like to call out is NIST did engage with us over the last year or so. A lot of the draft NIST zero trust that's the 700 publication. They took a lot of our input. I don't remember John also mentioned we had a number of comments I think 40 plus comments. And definitely they shifted it from a purely network centric and they brought in the policy based access control. That was with publication number 700 with the current executive order and the direction that NIST is going. I think they're making that migration towards data and asset centricity the executive order talks about data and asset centricity. What I believe NIST is doing is they're shifting because it's a large they deal with a much larger audience than most organizations do right the entire US government and many of our partners. So they're shifting and how should I put it they're changing the engine while the plane's flying. You'll see data and asset centricity come in. We are a little ahead of the curve in that sense. But they're also participating with us. I believe they're already part of the activity right John. Yeah. So they are engaged. I think there are a lot of US government agencies and other agencies. MITRE is a part of the organization too. So great. So we have to leave it there to make sure everyone gets a break. But huge thanks to everyone who asked the questions and and specifically to to our speakers and panelists today. Thank you all very much.