 Hi, my name is Bobby Samuel and I've got Frederick Coutts here with me, and we're going to talk to you today about health OS and enabling standards-based healthcare interoperability using cloud native and zero trust. So first of all, I'm Bobby. I work at Anthem. I lead up the health OS development as well as precision insights. Frederick, would you like to introduce yourself? Hello, I'm Frederick Coutts. I am a director of software engineering at Sharecare, and I collaborate with Bobby and Anthem on zero trust and variety of architectures and systems. So the way we're going to walk through this today is we'll start with the business case or the business challenge and then we'll move into the technology and then be here to answer any questions. So first of all, you know, what's what's the challenge? What's the what's the point of all this? So health OS is something that we've created internally here within Anthem and payers are seen as the middleman pain point across the ecosystem and causing abrasion across various user segments, whether as provider, member or even to other payers. But we also sit in position where we have the richest longitudinal view of data and that's whole health data about the person. So health OS helps us operationalize our health health data to drive improved outcomes and reduce costs and overall, you know, increases efficiency. So we'll talk to you about how we do that, but at the foundation of it all, health OS is a platform. It's a hub whose primary emphasis is interoperability and then driving world-class experiences and uses machine learning and AI to drive insights and also actions. So just to talk about the business architecture and how the pieces fit together, at the bottom we've got the data layer and that data layer it focuses on integrations with the EHRs. It's got payer and clinical data and then our data about members or our constituents is based on fire or the fire standard. On top of that layer, and this is where we'll get into cloud-native and zero trust, but in that space in the security layer and our platform layer, we've got a number of things that are running and happening. So insights and action apps live here and are created here. We've got tool sets or IDEs and tool sets to rapidly build, validate and or deploy health apps. And then this is where we'll talk about where we're implementing zero trust to do workload identity management. And then on top of that, we've got interaction layer. So the cool thing about health OS is that, or one of the many things about health OS is that whether it's a UI UX that health OS manages or a UI UX that someone else manages, whether it's another EHR or a homegrown app that we have, those all plug into and have the benefit of connecting back into all of these health apps and back into the place where we've got the rich data stores. So this is the ecosystem that we've been putting together with our client application endpoints to connect as well as SDKs to build and rapidly deploy apps. So in our ecosystem, what are we trying to do this for? And at Anthem, we have a number of partners we work with. We have a number of partners that we connect with and various lines of business. But the big problem is they're not connected. Anthem's connected to them, but they're not connected to each other. And what this allows us to do is to connect all the apps to each other. So health OS allows us to connect to Anthem's data ocean. It allows health apps, insights and actions to run and connect all these different apps. So we bring our digital ecosystem together and we bring our EMR systems together that we connect with, as well as internal systems that exist within Anthem. All of these things working together focused on better outcome for the member. And so let me zoom back out into what's our ecosystem and where Zero Trust kind of fits in. So we've put health OS in the center. Once again, action apps and inside apps. So an example of an inside app would be what benefits are covered for Bobby or does Bobby have this in his formulary, this particular drug in his formulary or treatment in his formulary. And action could be scheduling an appointment. It could be one click prescriptions or painless prior off, one click prior authorizations. And so those things run together and then using Zero Trust connections, we connect to various clients like the desktop or it could be, and I'm going counterclockwise right now, but like the desktop, it could be on AIML tooling that we've got running that we can make insights available. Third party health solutions. And then even to clients like third party clients like Telehealth OS, which Telehealth has seen a huge rise in popularity and usage due to the pandemic. And then EMR apps or apps that do payment acceleration, as well as just traditional EMR platforms like in large hospital systems, Epic, CERN or Athena Health. And all of these connected together, working together, once again focused on our member's health and improving the health of humanity. And so what we'll do is we'll dive a bit more into how we're putting all of these things together on a cloud native Zero Trust foundation to deploy this ecosystem. So Frederick, let me turn it to you. Thank you, Bobby. So before we jump into Zero Trust, let's talk a little bit about some security basics. Very often, when you speak with a security or information security person, you'll often hear about the CIA triad. We actually look at four things now, but the first three in the CIA is what traditionally people would look at. Those three are confidentiality. Is the information protected against unauthorized viewing or access? We look at integrity. Has the information been modified in a way that was unauthorized? How do we protect it from being modified? We also look at availability. Is the information available when you need it to be? And there's a fourth thing that has been added in in more recent times called non-repudiation, which is how can you ensure that an entity that has performed a transaction cannot back out of that transaction? And there's multiple reasons for this, which could include at the business layer, how do you prevent fraud? How do you ensure that you can observe the system? And know that that's what the state was likely to be. It could also be based upon trying to make sure that when you're looking at security systems, that you know exactly who you're connecting with and that it hasn't been swapped out with someone else. So in general, there's now four main categories that people tend to look at. There's a couple others that people will bring in as well, but these are the main four that you tend to see. So using this particular framework, we then take a look at what are the business requirements? What is it that we're trying to protect? What has changed? So when we look at the zero trust space and why it's important, one of the things that we want to look at is what are the previous assumptions that we've made? And what is the reality that we're seeing today? What has changed? And the differences between that assumption and reality can be seen in the form of cyber attacks where people will perform data breaches, will run ransomware, denial service attacks, forging identities, or so on. And the policies that we tend to apply in from a regulatory or policy perspective may also end up ossifying some of those assumptions, end up entrenching those assumptions in such a way that they can be difficult to respond to. So zero trust is about realizing that we have these gaps and then building up a new framework that is more flexible in order to allow for response to these type of conditions and to allow for additional controls to be put in in such a way that it enables other parts of your organization, your digital organization or your developers to be able to make the changes necessary to meet your mission, but at the same time still maintain that control to hit your confidentiality, your integrity, your availability, and your non-repeation goals. So what is zero trust? I try to distill it down into a small image. And this is the simplest I was able to find. In the top half of this, you have perimeter defense, which is the common gold standard that you see within many environments. That is where you have a trusted network. In that network, you have your services. If you need to connect to another network, you may have a firewall that you put in between them in order to protect entities in one network from entities in another network. But the problem is that if you end up with an attacker in one of these networks, then there's a lot that they can do there, a lot of damage that can be done. In the zero trust model, instead what we say is, well, what if that network was not trusted? No, it's not implicitly trusted. That doesn't mean the firewalls go away. It doesn't mean that you're not trying to protect the network, but it means you're no longer saying, this network is the implicit thing in which we base our trust. So once you no longer trust your network, then you have to look at where you push the controls. And the controls end up being at the services themselves. So if you look at the bottom half of this, you can see every service when it connects to something else has some form of a, of something resembling a firewall, something that is a control that allows you to determine what you want to send over those links to those other devices. If an attacker enters into your network, again, that doesn't mean you're no longer at risk, but it's yet another layer of security that you have that doesn't allow for implicit access to things simply because they're on the network. So to build our zero trust framework, we started with three main foundations. This is identity, policy, and automation. Identity is what is it that identifies your service? What does it identify as your user or identifies your data? How do you know that what you're looking at is the thing that you're, that you're looking for? How do you attest that identity? Policy is how do you develop the rules and apply those rules and enforce those rules across the, across identity? From the automation perspective is how do we take this from, let's say you have a single system and you can put a person on that system to defend it. When you say, when you start to try to scale this out to a large number of systems, hundreds of systems, thousands of systems, tens of thousands of systems, you need to have automation in place that is able to help you assign the identity and enforce the policy, but also bring in things like observability so you can audit what's going on and to have controls over what the automation is capable of doing or what it's not able to do. So it ends up being three intertwined primary pillars that have to be put together in order to build a zero trust framework. So we've been working on a reference implementation for this in the cloud native environment and we focus around three primary things. So if you notice, in the triangle, I actually made them link up so you can see identity. We're using Spiffy Inspire. For policy, we're using open policy agent. For automation, we're relying heavily on things like network service mesh. Now these aren't the only things in the infrastructure, but they're the representative of the type of things that we're trying to accomplish. So we'll go over each of these in more detail soon. We also build this on top of Kubernetes. We build it on top of systems like OpenShift. We build in automation on the infrastructure side. We have GitOps style processes that we're bringing in. Underpinning all of this, you still need observability across the whole stack. You still need control over the whole stack. So it ends up becoming this model that this particular thing represents, that all works in coordination to deliver the infrastructure that is part of HealthOS. So what Spiffy Inspire are is they provide identities to your workloads. So most people are familiar with user identity. You put in your password, you log into an online service, you have that user identity. In this scenario, we're looking at workload identities. So every workload receives an X509 certificate. This is the same type of certificate that when you log into your bank, your bank will use an X509 certificate to identify who it is. So we're relying on the same type of primitives and principles in order to secure the workloads. When a workload connects to another, they use a new feature within TLS that is available in TLS 1.3 and presumably above as those are released. And that is mutual TLS. Mutual TLS is where your client is able to validate your server, like you typically can from a web browser validating your bank. But simultaneously, the server is capable of validating the identity of the client. So you have this two-way validation that occurs within a trust domain. So we're able to create these identities that live within a trust domain that allow them to establish their identities. And these identities are constantly rotated out. Every hour they get rotated out by default if you're using Spiffing Inspire. And every time that you assign a new certificate, you perform a verifiable attestation. What we mean by that is that the system will ask for an identity. We will look at the properties of that system. You might have a TPM module that you're working with. You might have a identity document that is within AWS or within GCP or other similar systems that have some cryptographic material inside of them that help prove something about that system. We are able to build our Spiffy identities with attestation that is rooted in these cryptographic materials from these types of systems. This also has a very nice effect because since we're performing this mutual attestation and validation between systems, in many scenarios it reduces or also eliminates the need for long-living bear tokens. So in other words, you don't need to pass in a secret. The fact you're connecting in with a specific identity is enough for the system to recognize what type of a system it is and what type of policies need to be applied. In terms of policy, we're looking at things like Open Policy Agent. And Open Policy Agent allows you to consume the identities that are produced by a system like Spiffy Inspire and allows you to decide what does this system allow to do? What are its capabilities that it is able to fulfill? And when you create these particular systems, the properties we're looking for that led us to Open Policy Agent has to be something that's human readable, has to be something that meets the look and shape of common policies. So in other words, how do you classify data? How do you classify workloads? How can you say this system has PHI and create defaults that say, don't allow them to connect the systems that don't have PHI or vice versa? And then from there we can carve out patterns that the system is allowed to perform. In this example, we took this from OpenPolicyAgent.org. It's one of their examples they have on their front web page. And you can see a request that says, pet owners are allowed with a specific ID that is verified by the JWT, which is something that identifies the user cryptographically, is allowed to receive information or is allowed to make a request against this API in a specific way. If and only if the request comes from, like I say this is in front of a database, if and only if the request comes from a client or a workload that we have identified. So it gives us a lot of flexibility to define the exact type of shape and policies that we want in a human readable way that also allows us to get this policy into Git. It allows us to have code reviews on these policies. To share them with with other stakeholders so we can get their opinions on whether this policy meets their requirements or not. And it gives us that change over time so we can see how policy has changed, when did it change, because it's all checked into Git. We also rely on a new technology called Network Service Mesh. Network Service Mesh is another CNCF project that is looking to automate low-level networking systems. So we're looking at, if you're familiar with the OSI model, we're looking at Layer 2, Layer 3, we're looking at frames in Ethernet and IP and other similar level areas. And what it does is it facilitates the underlay to services. So typically when you're running in Kubernetes, you'll often have multiple clusters you want to connect together in some way. And when you connect them, the assumption is there's already connectivity established between both systems. What Network Service Mesh allows you to do is to acknowledge that there may not be a connection that's there and you may need certain things in place in order to make that connection work. So this allows the operator to say, in order for this connection to occur, I needed to have a firewall and intrusion detection system. These will go through a certain VPN gateway, a certain VPN concentrator. So Network Service Mesh allows you to automate these processes through a cloud-native API with native support from Spiffy Inspire and Open Policy Agent. And it provides you a cryptographic reputation of that connection chain. So in other words, in this example we have on the left, HealthOS app, going through a specific VPN gateway to a specific VPN concentrator to a specific health app. We can get the cryptographic identity of everything in between and see what is a system connecting through. Is it connecting through systems that we trust? Is it connecting through systems that are required to? Do we have everything in here that we need in order to establish this connection by policy and enforce it on an ongoing basis? Finally, we look at GitOps. And from a GitOps perspective, the workflow, this is more of a process side that is then committed as a service. So from the process, you have a developer. Developer will make some form of a commit into the source code system like such as Git. Then the CI CD system, your continuous integration system will see those changes that have been put into Git and will then render them into your test environment, into your staging environment, your production environment. The every change goes through source control. Every change goes through Git, which gives us that auditability. It gives us that chain as to who made the change. We also have control from the QA side. So in fact, when you're looking at regulatory concerns in this space, it's important that your developers are not allowed to push into production. You have to have a separate group of people, a separate team that is able to look at what changes are there and decide whether or not those changes should hit production. So when you start looking at things that are PCI compliance or HIPAA compliance systems, you tend to see this pattern quite common so that you don't have a single place or a single person who is able to push these type of things in. So the QA team is then able to determine at what rate and when something is promoted from testing to staging or staging to production. A really great example of a system that you can use to achieve this in your own infrastructure is Flux. So highly recommend that you go look at Flux and give it a try. It hooks up to GitHub and gives you that initial path towards automating in this style. So with that, I want to thank you all for joining us and learning a little bit about HealthOS and Zero Trust. Please consider that these are the type of technologies that we're using. We're using OpenShift with Kubernetes. We're using Spiffian Spire of the Policy Agent, Network Service Mission Envoy. Please join these particular communities. There's a lot of things that you can work on in those particular spaces. And if you're interested in the type of things that we're working out, please reach out to either Bobby or I and we'll help you navigate the path, whether it's coming to work with us directly or whether it's trying to work in the same area in your own industry. So please come and join us. With that, we have time for questions and thank you very much.