 First, who am I? Keith Basil, I am a product manager in the Cloud Platforms business unit and I cover security for OpenStack and OpenShift. And so what I'm going to introduce today is a compliance-driven approach to better security. And I'm going to introduce this concept of compliance as code and what that means. So let's actually jump into it and get started. So fundamentally, here's the problem. Let me wait for the slides to advance. Yes. Okay. So there's about a four-second delay. We've taken internally an effort to research the many global compliance frameworks. And so RITAD being a global company, we run into these daily with our customers. So for example, in Australia, there is a framework of recommendations around what's called the essential eight. Like the essential eight things you need to do to lock down your computer system or cloud infrastructure. Right. We also work with an organization called ANSI in France who is responsible for enforcing security policy for things that are labeled as critical infrastructure to the country. Right. And then we have our friends here in the U.S. government. We have really good relationships with NIST and the DOD and IC communities where we are helping make our products more secure to meet their requirements. So the takeaway here is that you've got geographical boundaries, you've got industry specificity for these risk management frameworks. And as a product manager who kind of grew up in the D.C. metro area, I understand like the contractor mentality, right? And so my dream as a product manager was always to have a cloud product that would solve for these security problems to make the job of the compliance and audit folks a little bit easier by checking things out of the box. But as you can see from this slide, there's quite a few things globally that we need to be aware of. And it could drive you crazy as a product manager trying to pivot and answer questions along these many lines. Not to make it even more complex, but compliance is a full stack exercise. Kirsten had a slide that was very appropriate about Kubernetes done right being very, very hard. And so I wanted to call out a little bit more detail here in that the compliance that we look at, we have to look at everything from the hardware from the host level all the way up through the stack. That means, you know, what type of operating system are you running. The kernel matters in this regard because there are certain security facilities, particularly around Kubernetes container hosting that are absolutely critical to compartmentalizing, you know, the workloads on your Kubernetes platform, right? So namespaces, system calls, reduction of privileges via limited capabilities, locking everything down with SE Linux and for more extreme environments or having certified crypto, you want to make sure that that kernel enables FIPS, right? So these are just some low level pieces and parts, the Legos, if you will, that actually build up and that we have to take into account when it comes to compliance. And so, let's take it one step further. Okay, so on the right, when this slide loads, I'll show you on the right, we have our listing of all the risk management frameworks, right? Again, geographically bound, industry bound, maybe even a mixture. And then on the left, we have OpenShift as an example of an infrastructure as a service offering that we need to secure and lock down. I'm happy that Diane mentioned the compliance officer role at the top of the call because this is the nightmare that compliance officers have to deal with because on the left, you have an infrastructure stack that changes or iterates every three months upstream. So Kubernetes is a very, very fast moving upstream open source project, right? And then you have to marry that against one of the frameworks on the right. And so, for example, if we say we're going to get our OpenShift environment, FedRAMP, moderate enabled, right? That means that we have to take the time to document all of the things that go into doing Kubernetes right, right? That's a hard problem. So we have to build what's called a system security plan as an example. And that basically documents how you address all of the controls that are specified in FedRAMP. I mean, how are you going to remediate? What's your response to this thing and to that thing, right? And so there's gap analysis, there's audit and remediations, your auditor, your third party auditor is going to come in and give you a punch list of everything that's wrong. And so these things take a long time. So if we set out today to say, hey, we're going to go get FedRAMP moderate and what's called an ATO and authority to operate for FedRAMP moderate, then that literally could be a nine month to 18 month process, right? And so if Kubernetes and by downstream OpenShift are changing and doing releases every three months, when you start the clock on your submission, you're going to be at minimum two or three versions behind what you've documented, right? And so basically the takeaway here is that the hamster wheel that you see on this slide does not stop moving. In fact, it gets worse, right? And so doing these things manually, you know, addressing FedRAMP compliance and this overall 853 compliance or going for PCI, DSS, et cetera, these things are heavy processes. And so we want to shortcut this and this compliance as code approach is exactly how we approach that. So let's talk about the solution. Before we go into the detail of the solution, I want to talk about the approach, right? And so we, after we've done our research against the risk management frameworks that we run into as a company, we decided to settle on two things. One is NIST, the NIST 853 control set, because there's a lot of overlap with NIST and other frameworks kind of look to the US as the gold standard. And so what that does for us is it gives us leverage, okay? Meaning that if we can solve for, let's say, the 853 controls that have been carved out for FSMA or FedRAMP, if we can solve for those, we're going to get probably 80 to 90% of all the other frameworks out of the box in terms of meeting those requirements. And the other logo that I put on this slide is the Cloud Security Alliance. And let me talk about a really cool tool that these guys have. They have this thing called the Cloud Controls Matrix. It's essentially a spreadsheet and it acts as kind of a Rosetta Stone for mapping how you address this particular control and it shows you how you can apply that to other frameworks. So for example, if we solve for configuration management in NIST as a family of controls, then we can see that our answers to how we do configuration management could be applied to ISO, to HIPAA, to PCI, DSS, et cetera. So it's a really cool tool in that regard. It's kind of a roadmap to mapping down into the other frameworks. And so going more specifically from a RIDHAP perspective, I want to talk about how we approach this with OpenShift as an example. So on the left, you'll see what I call the FedRAMP cheat sheet. So this is basically a summary of the control families that you will find applicable to a FedRAMP deployment. And so some of these are highlighted in the green circle like access control and, sorry, Diane, can we mute that person that's on the call? Okay. So on the left is the FedRAMP cheat sheet, as I said. And so as a software company, we can only, RIDHAP can only influence and provide guidance for the things that are within our scope. For example, you'll see personnel security on that list on the left there, the PS family of controls. Well, RIDHAP is not in the business of doing background checks on people, right? So for example, in FedRAMP moderate, the folks who have hands on keyboard to administrate your system must be U.S. citizens, for example, right? So that's up to the organization to figure out and address how they're going to solve for that control. It's not a software issue, right? I just wanted to make sure that the folks on the call here understood that the things that we've highlighted here are the things that we have influence over and largely they are technical and system level control families, right? And the last thing I'll say before we go to the next slide is that the green that you see there is an internal tool that we created to do a complete assessment against the more than 1,400 controls that you'll see in NIST 853. So this is our kind of internal barometer, if you will, on how we're meeting from a product perspective FedRAMP or FSMA low, moderate and high as an example. And we'd be happy to talk to you more about that if there's any questions around our approach here around security. So going back to the concept of compliance code, what is the magic, okay? What are we doing here that's different? As I alluded to before, the process is very heavy, it's intense, it's very manual in terms of building documentation, documenting the system, all the controls and all the configs and the knobs and such that you do to make the system more secure. What we want to do is to codify that knowledge, right, in areas where we have domain expertise, right? So for example, think of it as building a cake and I'm going to use this cake analogy because I think it's effective here. So imagine if you will, we're going to bake a cake in layers, we're going to build each layer of the cake at a time and now we're going to deploy open shift for a federal government use case. So number 1, we need to figure out where the system is going to reside physically, right? So maybe we pick a data center somewhere in Ashburn, Virginia, that's close to, you know, our folks. And we're going to say to that data center owner, give me your compliance code or put me to the repo that shows your compliance code artifacts. So we could basically, in theory, just do a pull and pull down all of the data center remediations, like in descriptions, for example, in narrative pieces. So what does that mean? That means that we now have in text form information about the physical barriers around the data center, information about the security background checks of the security folks that physically reside in that data center. The man traps. What is the level of redundancy for power and pain for the, for the network. I was hard of cages built out, etc. So now we can just pull, do a get pull, pull that down. We have that in a JSON format format where we can drop that in as the bottom of the cake. And then going one step forward, we may say, if we're going to use let's say Dale hardware. Hey, Dale, show me your compliance is code repo that describes the hardware security that you have for your platform. Right. So maybe this will describe TPMs and hardware at a station, for example, and how that's done. So we can pull that in. And then we go up and let's layer up. Let's talk about real core OS as an operating system. So now we're starting getting into the red hat layers of the cake. And then we as a red headed and we are on the product management team want to make sure that we provide those layers of the cake and that they're fully complete. And then finally, going back to the scopes that we aren't responsible for, maybe the personnel security is an in house thing with a private repo, and they build out all of that into a repo that specifies via JSON, all of the personnel security procedures that they put in place. So now we've got the entire cake. We've got a directly full of like artifacts. There's tooling within this community called compliance masonry. For example, you can point that to the artifacts that we just assembled and actually bake the cake. It's like putting it in the oven, right. And so boom, once this tooling runs, it will build a 400 page word document that's the start of your system security plan. In a matter of minutes, which is phenomenal, right. And so this is the power of treating compliance as code where now we have very close to real time, a status on the actual compliance implementation for each one of those layers in the cake. So, for example, on the OpenShift team, our goal is to make our security profiles, like co terminus or released in parallel with the next version of OpenShift. So, for example, if OpenShift 4.5 comes out, we'd love to publish the compliance as code profile for FedRAMP, for example, for OpenShift 4.5 and then 4.6, 4.7. So that way anybody consuming this work downstream can just pull the latest, rerun the tooling and have immediate updates to their SSPs and whatever other tooling can come out of that. And the last thing here that's really critical is that the compliance as code work is really two parts. There's the text part, the narrative that describes your responses in the system security plan. And then there's also a baseline set of content that does auditing and remediation. So what does that mean? There's actually code code in the compliance as code piece that will allow you to basically analyze audit and a test that your system is in compliance against those controls that we've defined. And if it's not, you'll have the option to come back and force it to be in compliance via the remediation content that's supplied with that profile. So it's very, very powerful in that regard in terms of giving us leverage to maintain relevance and accuracy with our compliance processes. And so let's actually look at it a little bit in action here. So on the next slide, we talk about the process and going from left to right, this is typically how it goes. So you'll see on the left, guides and documentation. This could be auditor docs, security requirement guides in the DOD space we call them SRGs. Just general configuration guides on how to secure the system or make changes that are not necessarily related to security but need to be accounted for. And then you have properly published and blessed what we call STIGs, the Secure Technical Implementation Guides. So this is kind of like the knowledge but it's in so-called digital paper format. And so one of our missions is to take that knowledge and turn that into submissions against the compliance as code repo according to the recommendations that you find in those guides. And so that's number one. And then number two, we pick one of the risk management profiles that we're targeting. So for example, if we're targeting the Australian Essential 8, we'll take all of that knowledge on the left and we'll build an Essential 8 profile and put that on the get repo. In fact, there's a link on this slide to that exact profile. We've just recently got a submission from our Australian team specific to the Essential 8. And then lastly, as I said, there's two parts of the code. There's the narrative that describes things and then there's attestation to do the check and then there's remediation to bring that system into compliance. And what you see below those are just different facilities that can be enabled to do attestation and remediation. In the case of OpenShift, Kirsten mentioned that OpenShift was using Kubernetes to manage Kubernetes, right? And so we are working on this concept of a compliance operator. And it's really cool in the sense that once that operator is installed on your cluster, you can feed it a FSMA profile, a FSMA moderate profile, and it will bring that system into full compliance with that profile according to how it's defined. And it's a phenomenal thing and the leverage that we're going to get from that is going to be really cool. And so this is the process. So you got documentation and sometimes tribal knowledge that's baked into your organization in the heads of many of the people. And we want to get that from the docs, from that tribal knowledge into something that we can act against from a software perspective. So that's what we're doing here with Compliances Code. And so we've started this. There is a community upstream. This is a screenshot from one of our public sector meetups where we're talking about innovation and using open control. There's quite a few folks, Microsoft, Pivotal and some others are members of the open control community and have contributed their own Compliances Code profiles. So we're starting to grow quite a bit there. And we've also created a derivative of that. We call it ATO pathways where it shows kind of the Red Hat product status against the authoritative information that you'll find in the Compliances Code repo. And then lastly, there's a few links that you can look at to go a little bit deeper. Compliances Code, the first GitHub link is the number one is the top one. And then the Red Hat specific one is second and then the open control community you'll find at the last bit. So that's all I had today. Hopefully this was a good overview of Compliances Code and I'm happy to take any questions.