 So what Zach and I are going to talk today is about the identity-based segmentation for a zero-test architecture. So naturally, so we have to give some leading information on what is zero-test architecture and going zero-test and then we dwell into what is the identity-based segmentation and then all the nuances of the politics, Zach will explain later. Do you want to introduce yourself actually to the... My name is Chandramoli. People call me as Moli for short. I work for National Institute of Standards and Technology. We have been working with... Moli is responsible for writing a lot of the SPs that you all need to go implement in practice. So his fault, but also awesome work. And I'm Zach. I'm one of the founding engineers at TouchRates and I work very closely with Moli to help author some of these. In particular, we've written a lot of the SP 800204 series together, which is the set of security recommendations for microservices and multicloud. However, we're actually going to be working together on some things around zero-trust very soon, and you'll get a nice sneak peek of that here in this presentation. So first of all, as Zach mentioned in the keynote address, zero-trust has been around for quite some time. But then he says, hadn't focus on zero-trust right now, is of course we know all the good reasons that no longer there is something called a perimeter exist because people are sitting all over the place. And secondly, the applications themselves have become quite distributed. So naturally, east-west traffic is now a bigger part of the traffic rather than north-south traffic. And secondly, all applications are in the form of microservices. There are many pieces involved. And so naturally, each of the access decisions should be based upon per request. And you take into account all the context, there will be variables because there are very many variables involved. And it should be, of course, conformed to the good old cardinal principles of least privilege and so on and so forth. And naturally, it should be, so naturally means it should be identity-based. So and core all the entities carrying identity, you know, the users and services and devices. So that's what we are going to focus on today about the identity-based segmentation. And again, the high-level framing is, you know, assume the attackers in the network. What do we do to mitigate the damage that they can do by binding their attack in space and in time? Yep. So then, so we have now actually shown the need for why you focus on zero trust now and identity-based segmentation. So in other words, why do we call it as identity-based segmentation? Because originally our controls were based upon the assumption of a perimeter. And now that we venture into the zero trust, the initial thinking was, can we do a segmentation of the network itself? So but the existing techniques on network segmentation, like, you know, based upon subnets, as well as some labels as we case, the case of VLANs are no longer sufficient. Because all the virtualized containers, workloads, they move all over the place. You can't pin them to a particular, even a network address or a subnet and so on. So that's why we need an identity-based architecture. So in the zero trust architecture, essentially what we really described is all the very components that are involved and all the data flows that are involved. And last but not the least, the all the policies that we require and then the security of the enforcement points. So those are some of the things that we want to concentrate as far as the zero trust architecture is concerned. And then this zero set architecture is the fundamentally it is based upon the identity-based segmentation. So another name for zero trust segmentation also. And then, of course, as we all know, identity-based means what the name implies. You know, it is not based upon any network parameters and it applies to services, users, and devices. And also it should be not just any identity, arbitrarily like user ID and so on. It should be a cryptographically verifiable identity. That's the most important thing as far as the services concerned. Yeah, and a couple of things here to note is that and in that second bullet point is doing a lot of heavy lifting there, right? So we need not just a service and a user identity, but we also want to know where the device that it's originating from. And we may even use things like the network parameters as part of a risk-based assessment to give you permission or scope or things like that, but it cannot be the only check that you're doing because that is not sufficient. We need the identity checks and we can continue to apply traditional checks like network location as part of a layered defense. And we'll talk about that layering very soon here. So actually then as far as the zero trust is concerned, the comprehensive solutions we know consist of not only runtime checks, but also the whole processes in place, and also the monitoring and continuous reformulations of policies and so on. So that is the whole sub-process. But in this presentation, we are just focusing on the identity-based segmentation aspects alone. Yeah, so really just the runtime controls, which to be honest, are the easy part. The people process things are going to be the hard part to change within the organization. But the runtime controls, we can help solve with technology, right? And it can become a lot simpler. So it is a runtime technology solution that we are focusing on this. And then we identified, at least in the concept of microservices environment service mesh, that we do need at the minimum these five things. First, the session itself should be secure for that we need encryption and transit. And then of course, we do need to validate service identities. And then once identity is validated, we need some means of authorizing authorization at the service level. And then of course, the end user is also an integral part of the whole picture. We need to have an authentication of the end user. And then lastly, the end user authorization as well. End user authorization, especially if you want resource level controls, you need to have end user authorization as well. Exactly. And then this is our goal of realizing the ZTA through this trial technology approaches. Yeah, and just to kind of paint a picture here, you can imagine moving up the tiers. We go from subnet-based connectivity and micro segmentation at that level. We can start to layer in identity-based controls, but policy gets really powerful and very compelling when I can combine both service runtime policy and user access policy together. So you can write a policy that says, for example, not just the front end can call the back end, but the front end can call a particular method on the back end only in the presence of valid end user credential that has the permission to read, for example. And so again, the game is all about bounding an attack in space and in time. Those more comprehensive policies that combine both physical location and application as well as end user credential do a lot to help us write very tight policy that bounds an attacker in space what they can pivot to attack very tightly. Yeah. So just a background to that, we want to have some overall view of service mesh. We know that we are somewhat preaching to the co-head. Everyone will be familiar with the service mesh. But just to give you an idea that the service mesh really is meant to accomplish three primary things. So one, it has the infrastructure as an infrastructure layer. It provides identity to the applications, which is the very key. And then the second one is it does all the things with the traffic routing starting from service discovery, intelligent routing, and all the nice and goody resilient measures like the number of read, rise, blue, green deployments and all that stuff. And then the third one is, of course, the most important is to enforce service to service authorization as well as end user to source authorization. So that's where all of us focus on policies and everything comes into the picture. So and not only because this beautiful entity called the proxy that is part of the data plane of the service mesh, that actually really acts as a security kernel because it is non-bipassable and also it's verifiable. It is outside the application code. And then so then actually we just give a brief description of how these various things are accomplished in this one. So as also most of you may be familiar, the encryption we ensures through the mutual TLS and shake usually using the service identity which contains the service identities, the subject alternate name field of the service, the short-lived service. Yeah, basically we can leverage Spiffy certs to do both encryption and transit as well as our authenticateable runtime service identity. So we use the same certificate for service identity and authentication as well. And then for service to service authorization we actually got a lot of 15 options using that. It can be an in-process filters in the proxy itself. You can use proxy extensions or you can call external services if you want more sophisticated authentication like the NGAC that NIST has developed and so on. And similar then we come to the end user identity authentication. There as we have said in one of our publications that we can land up with, you can use any of your native identity providers to give you the end user authentication, the end user credentials. And then at the ingress point in the gate and the ingress gateway, you can exchange it for a job token which contains you'll give the local identity and so on. And it can also populate it with claims. And then the same in the end user when they are inside the mesh and making a call. So those the claims in the job token can be used and compared against the resources that are being requested that particular resource. Or again here we have the option that if you want to detail the resource level authorizations, you go to an external service like NGAC and so on for the end user to resource authentication. And you know specifically in SB 800204B which Muly and I wrote, we talk about extra and so if you want to dig into some of these ideas in more detail, go check that out. We talk about pulling out things like authentication into this common layer into the service mesh so that it can be audited so that we can have higher assurance in the code because it's not delegated across every application. There's a lot of really strong properties from a security perspective that we can get pushing this out into a common layer. As long as the application still ensures that those checks have been applied when it gets it. Things like looking at a job that the system mints, validating that job that it came from a trusted source and then using those claims to actually apply authorization is one way that an application can attest that these checks have happened before the request reaches it. Essentially we have detailed the function of how JOT token is being processed to arrive at. And not just JOTs, it doesn't have to be. And one thing I'll just point out is there are actually multiple high assurance deployments hitting things like FedRAMP moderates in high controls, leveraging things like the service mesh to offload user authentication and authorization to a common infrared layer, to the mesh. This is not just something that we can do, but this is something that actually is done in the wild in high-criticality environments that are security-first. So far we have outlined all the goodies that a service mesh can do, but then this may be at a particular service mesh instance for a particular cluster and so on. So how do you take it to the enterprise level? And that's where we need another infrastructure layer that's sitting on top of the individual service meshes so that you can apply uniform policies throughout the enterprise for all the service meshes and so on. And secondly, that is really a reality because not only there are multiple clusters within the organization, but the common scenario is that you do have hybrid environments, you do have some resources in-house in the data centers and branch offices and some in clouds, and some in even multiple clouds. So when that is the scenario there, we definitely need a higher level infrastructure layer to in fact act as the super control plane for the individual control planes in the service mesh instances. Exactly. And that lets us do things like enforce consistent identity for services across the different sites. That lets us do things like author a single policy, hey, the front-end can call the back-end and manifest that policy across the infrastructure, right? And we can take care to ensure that we have the right application in the identities everywhere, even when we're doing things like going across clusters or across clouds. So that same policy that you write front-end can call back-end is going to apply equally, regardless of whether they live next to each other on the same, you know, it's pods on the same host or they happen to be traversing a DMZ and going through a firewall to reach back to the data center. So yeah, that's why, so we do need definitely everyone is convinced about the map to have policies, but then these policies alone cannot be sufficient. So that is why we need policies at the multiple tiers. Why? Because the network level policies are needed because some of the compliance regulations and even regulators, they are not satisfied with anything else because service identity is something not everybody can get their hands on and things like that. And secondly, it does serve its purpose in the sense that the network level policies itself can be at two tiers. One is very coarse grained between firewall to firewall, but it can also be somewhat subnet based in the sense of from a gateway to gateway and so on. And then, of course, on top of it, as Zach said, we can layer all the good service identity based public policies on top of these network policies. And so the beauty of this is we can, these policies can really coexist. They don't have to conflict with each other. So the multi-tier policy is the most desirable thing. And as just now described, can be network tier policies, which is can be both coarse grained and fine grained and then identity tier policies, which are more really dynamic. So that's why, so the tier policies can be really static. So you don't have to really, in some sense, it allows for relaxation of those policies in favor of higher level policies. Exactly. Keep changing environment and so on and so forth. And really, this is before, before we hop on, you know, this is really all about kind, trying to pave a path for organizations and the auditors who checked the organization's compliance to understand the move from a perimeter model into an identity based model. And so we view these multi-tiered policies. One is a stepping stone to facilitate that. But two, exactly like Muly said, is to help with defense in depth, more layers for an attacker to have to traverse, you know, more ways to bound the attack in both space and in time. Right. And then this is just a schematic diagram that's just showing at, between what entities the network policies apply and then where application layer is. Exactly. And so just to help kind of make some of these ideas concrete and help kind of paint the picture for how they might help you bridge a traditional perimeter model, I want to, you know, walk through some cases. So, you know, suppose we have these two services communicating, and suppose one, you know, they're at either different sites or maybe one is in cloud, one is in the data center, right? And so we have a traditional, you know, DMZ and a whole class of policy that we want to apply to that traffic as it's coming into kind of our trusted data center. Oftentimes, that requires rule changes per app, right? And that is where we get the pain in managing outbound firewalls. This is where we get the pain in managing the network-oriented rules, right? You look at a set of subnets that are allowed to egress to a set of IP addresses and like, what does it mean, right? And this is where we have a spreadsheet where we record it somewhere, right? That is clearly brittle and painful and we see it regularly create, you know, slowdowns and organizations, right? So one of the ideas that we put forward is using basically identity-aware gateways to help us bridge that perimeter. So the idea is that we can have, you know, gateways on both sides of the perimeter. We can establish relatively static policies to facilitate those gateways communicating, and we don't need to change those policies per app because those gateways are static deployments on our site. Then we can leverage identity-based policy, which is, which can be much more dynamic and hopefully easier to maintain, about who can go over that connection, who can go over that transit. So in other words, as Jack explained, these gateways offer somewhat of a bridge to go from identity-based policies to the network-based policies in the sense that they are participating in both. Exactly. So in that sense, they are able to go over policies and now Jack will explain in detail, these are three levels of policies, Yeah, exactly. And so we see these exactly overlay on top of each other, right? And so we have exactly like Millie said, core-screen firewall policy at the bottom. Obviously, these are not like, you know, real real policies, but a shorthand if you didn't kind of get the idea, right? We have firewall-to-firewall policy. We need microsegmentation as well on each half. Very hard to manage how they go over that, by the way, with things like a CNI, it becomes challenging. It's not easy to bridge across the two halves of our policy. The service mesh can sit on top of that and facilitate consistent policy across our different deployments, right? So we know, you know, lower-level policy is going to live at the site, right? The microsegmentation is bound to a cluster usually, right, or a set of VPCs. And we typically don't, you know, we're going to open up firewall rules between the two. We typically don't see microsegmentation across these. That's, again, where we can start to layer. We can start to relax some of those policies that can be hard to maintain and replace them or augment them with mesh-level, identity-level policies that can be consistent across the entire infrastructure. And when I say consistent across the entire infrastructure, what I mean is like literally we can instantiate the same policy document in every mesh without having to specialize it or change it for each deployment and have it be correctly enforced because identities flow in the end. So as we're looking at how we realize this enterprise ETA, you know, the first step is we want to start to implement this identity-based segmentation, right? We want to start to migrate towards identity-based policy and we can leverage some of these patterns to help make our lives easier dealing with things like the traditional perimeter. You know, as we said, you know, we need some, you will likely want some central coordination infrastructure that sits above a service mesh to help manage some of these, right? So if we look at a traditional, you know, corporate topology of three zones, this is pretty standard stuff that we see all the time, we can start to insert these identity-aware policy enforcement points, these gateways, fundamentally an envoy proxy in the data path there to start to leverage higher-level policy at all of these locations. So in other words, what we call as a proxies in the context of service mesh, they play the role of the ingress proxy as well as the egress proxy and then also as what is known as the transit process itself, you know, in terms of they can even perform other goodies like load distributions and identifying the ingress proxy for the various clusters and so on. Yeah, exactly, because there's a certain amount of like service discovery information you'll need to propagate across clusters, right? For example, you know, your ingress edge may want to load balance across multiple clusters behind it in the same VPC or in the same data center. So there's some service discovery that you need to wire up, there's policy that we want to push to these layers as well, you know, and so we can start to leverage things like your CD pipeline as one of the ways to implement this coordination infrastructure, right? You can, for example, templatize a lot of the things like service exposure and service consumption and let your CD pipeline instantiate the policies across the various meshes. Certainly there are online ways to do that as well. The advantage of implementing all these through the processes, you know, you can have a level of security assurance because of all this. Yeah, and fundamentally again, you know, we see this as layering on top of each other. So again, this is a, you know, kind of a rough picture, but you know, we still anticipate these traditional perimeter based controls. We're going to have, you know, segmentation or micro segmentation underneath that inside of that perimeter, right? You typically see and I will sit even on top of that as another layer and we want the mesh to fit exactly on top of all those, right? And again, the advantage here is that we can start to relax some of these lower level policies that are hard to maintain in favor of policies allowing these gateways to communicate and back that with identity based policy to instead. Yeah, so again, you know, why do we do this? The main motivation for, you know, in general identity based segmentation, hopefully people get why we would want to do this in the context of moving towards the ZTA. Why might we want to manage multiple tiers of policy at the same time while we're doing that? You know, again, it's really all about appeasing your current regulatory requirements, your current control requirements and the knowledge of your current security team and the auditors, regulators you have to deal with, right? They may not be in some places, you know, they're very forward. For example, the Air Force is a very forward organization where I can, I don't need a perimeter and I don't need to show a bunch of these controls to get approval to get an ATO. Other parts are not the same, right? And so we want that defense in depth to be able to prove both the original perimeter based controls and that we can do better and that we can facilitate the organization moving faster because we're not having to manage brittle policy at a lower layer. And further, most of the time, the reluctance and acceptance and accepting the policies is due to the complexity and that way, in the tail case of identity based policies, we are able to express in terms of entities that people can understand. Exactly. This application and this process can talk to this application and this process. Exactly. So that's one of the other advantages. Yeah, policy becomes a lot more, yeah, policy is more maintainable because it's more readable and it's in terms that are closer to what a developer thinks about service names and service identities, not like what's subnet of my own. And again, these can continue to exist and we expect them to. We'll end and take questions for whatever time we have left, but just to give you a teaser here, SB 800 207A will be coming out in this calendar year in 2023 around these ideas, this idea of starting to use identity based policy enforcement points to help span traditional perimeter based controls. And with that, I think we have hopefully a little bit of time left for some questions. I think maybe about five or seven minutes. So please, any questions for either of us, for both of us? Yeah, exactly. Yeah. And so we, and you know, for example, in GAC, next generation access control is an access control standard that NIST is working on that's an ABAC kind of similar conceptually to what Zanzibar is used to implement. And so yeah, exactly. You know, we can implement, you know, all of these orange pieces are policy enforcement points and we can choose whether we integrate with an external system to apply, you know, potentially very rich policy because we have like a full ABAC like a Zanzibar kind of a system. But we can also apply much simpler policies that are like already built into Envoy, right? For example, you know, just simple services service access with our back, right? And so that's a spectrum there. So yeah, the mesh is bringing enforcement and what you choose to use as your decision system, you know, as long as it integrates with the mesh, it's all good, right? And we typically see, for example, OPA used with Envoy actually enforcing the policy, but OPA acting as the decision point, right, is a very common deployment. And all that is possible because of these capabilities of proxy one, it can do the enforcement doing, using an in-process program, like a Jot filter, which compares simply the resources against the claims and so on. Or you can use external APIs or, you know, you can call the regular authorization service with external. So all this, because of the extensible API, the proxies, all these goodies are possible. That's the goal to get to. You can certainly start by delegating to Active Directory because that encodes your current policy, right? And so we don't, you know, I don't want to paint this as a picture of like, do this perfectly. The whole goal is to give us stepping stones to get to kind of that ideal world where we're doing very rich end user-based application context, aware policy on every hop. That's the goal to get to. If the policy is in Active Directory today and we can use that to do user authorization, then that's the perfect place to start with one of the integrations and then go from there into a richer policy engine where you need it. So in other words, it offers a very great path rather than one day turning out the light and so on and so forth. Exactly. Do we have another question here? Yeah, so it can be any number of things. Yeah, it can be, you know, they're, yeah, typically it's going to be like a CD system that's coordinating. There's also a variety of like vendor products that do online policy pushing and like multi-cluster management and stuff like that as well. And, you know, any of those are good ways to do it. The, you know, in my opinion, the important thing is to get the right abstractions for your application developers and fit them into your workflow, their workflow in a, in the right way. And then it shouldn't really matter if it's the CD system that does it or some other engine because they should be interacting with it in a way that's abstracted and controlled by the platform team. That's why we want to call it as a super controlled plane that sits on top of the individual service instance control plane. Yeah. And it doesn't necessarily, so control plane applies runtime. It doesn't necessarily have to be a runtime system. It can be a system like a CD system that's pushing it, but it can also be a runtime online system that's acting as a control plane, getting data and pushing it around. Both of those are good ways. It depends on what you need out of the system and what are the properties and what's the operational investment you want to make for what is right. Right, Arjun? Yes. Yes. 100%. It could potentially, right? So like, yeah, you know, it doesn't really matter how we encode that identity as long as we all agree on what the identities mean, and we have some mechanism at runtime to authenticate it, right? So at a service, you know, at a service-to-service layer, of course, we want to leverage Spiffy because that's a good standard. But, you know, at the end user layer, it could be, you know, whatever you want, right? It doesn't really matter. And then, you know, the SP, for example, won't be strongly opinionated on that. Yeah, that's why you said you can have either a custom authentication or one of the OIDC providers, OpenID Connect. Yeah, because we very frequently see, you know, yeah, somebody do OIDC. Yeah, OIDC or OAuth, and they're just holding tokens, right? And so it might as well just be an opaque thing. Exactly, right? So there's plenty of room to do exactly. Exactly. And to be clear, you know, encryption and transit, we just to tee off that a little bit, why do we say encryption and transit is required? It's not because encryption transit is good. It's because we want message authenticity and we want eavesdropping protection, right? And so we can achieve the message authenticity is the really important one, right? You may or may not care about eavesdroppers being able to see what the requests are, but you certainly want to know that it hasn't been tampered with, because otherwise all these other checks are meaningless, right? Who cares what the identity is if somebody stuffed the envelope with something different, right? And so really has to start there with the assurance of the data on the wire, and then we can use that to kick off policy down. Any other questions? Yeah. Yeah, exactly. So the question is roughly just a paraphrase, have auditors actually approved this? Can I actually do this pattern? Is that roughly it? Yeah. And the answer is yes. Across the board, we've seen a bunch of different auditors under different regulatory regimes approve these style things, whether that's folks like the Air Force AOs who have approved ATO for a lot of, you know, federal moderate to high systems on this kind of thing. We also see it in folks that are subject to PCI, right? And for years, actually we've seen folks implement a variety of PCI controls using this kind of stuff, right? So this is something that we're seeing, and that's why we're moving to start to write this as a standard, right? Not because it's brand new and like we think it's cool idea, but we've seen this implemented. We're seeing regulators start to accept it. And so our goal in codifying it as an SP is to really push that to those regulators, to those approvers, to say this is a good thing. You should accept this as a first step for educating them to move the ball, to get to the end, to say that we all want, which is like identity-based policy. So in other words, the lessons learned there into the implementation that Zach talked about as really is going to be a good input into this document that we are. Yeah. Was there a follow-up there? Yeah. Yeah. So we're starting to build those out. So for example, there is an Istio to NIST SB 853 mapping, for example, and that's actually in the form of an OSCal manifest that can be used to feed that in and check the assurance of the system at runtime, right? So it's early days for that, but those are things that are being developed there. And the goal is to push a lot of this into open source, right? So things like OSCal, the open source compliance assessment language, lets us do programmatic checks. A computer can verify that you're implementing controls, not a human auditor who's quinting at it and checks the box, right? That moves us to a world where we can do it continuously. My goal is that we can get basically all the big infrastructure projects that we're depending on to produce and maintain OSCal definitions of their components. That's one of my longer-term goals to try and implement. Yeah. Yeah. So the important part here is not how the policy enforcement is implemented, right? So I mentioned Envoy a few times here, but all the concepts that we're talking about are independent of the data plane implementation, right? So as long as you're doing those five checks, I don't care. You shouldn't care. Nobody really needs to care if it's EVPF or if it's Envoy or if it's a VPN. That part is not very important, right? There will be security in runtime and operational tradeoffs to different implementations, and we are starting to do some write-ups, kind of starting to analyze that, right? I fully expect a lot of this policy to move into EVPF as an accelerator, right? Anything that we can move out of user space and into the kernel to be able to reject a request earlier without having to do those context switches is going to pay a lot of dividends for, you know, higher throughput and higher performance systems, right? And so in that sense, I expect that EVPF will be widely used as an accelerator for data plane policy application, right? In other words, providing coverage for the various events is what is important to us rather than what will help us identify the events in terms of the kernel triggers and things. Yeah, exactly. Yeah. All righty. Do we have time for more? How are we doing on time? Nobody's come with a crook to get me off the stage yet, so we can keep doing questions until that happens. Any other questions from folks? Yeah. Yes, they will be available. The conference should make them available. If not, I think we have our contact info here. Just shoot an email worst case if they don't pop up in a week. Already awesome. Well, hey, y'all have been an awesome audience. I really appreciate the good questions. Thank you. Thanks for your time.