 Hi. Hi. Good. Good. Well, my name is Evgenia Schmacher. I work at Mirantis. And I have Scott here. He's from PayPal and I'm going to pass the ball to him. So today we are going to talk about compliance. And I see quite a few people here. I hope all of you guys just decided to have a nap after the coffee break because compliance is boring, you know. Everybody knows about it. We'll try to make it more fun, but I don't promise anything. Well, as I said, I'm a business analyst at Mirantis. Actually, I'm not that familiar. Like, I'm not a very open-stack person. Like, I'm not a developer. And at the same time, I'm not a hacker. I'm not the person who knows how to make penetration tasting or whatever. But still, I spent a couple of years working at the security company. And I know what compliance is and actually that the standards, different types of standards like industry standards, government standards, they are a good source of business requirements for customers that we usually have. It doesn't matter which customers, but for our case, it's open-stack customers. Well, when it comes to compliance, and when I started to talk to different open-stack people and I asked them, what about compliance? What are you doing about compliance? The most common answer I heard was, okay, and what is compliance? Well, here you can see the pretty, like, I just copy and paste some information from Wikipedia. So it's very long and not very interesting description of what compliance is. But don't read it, please. I think you have already read, okay? But anyway, what I would like to say is just compliance doesn't mean security. And it's very important to say to people that people understand it. Okay, now I see that there is a place where I can actually see my slides. Good. Yeah, so actually, compliance is not the security. And being compliant doesn't mean that you are secured and being secure doesn't mean that you are compliant. And when it comes to, when we talk to, like, open-stack developers, open-stack developers, all of these people, they are very technical. And you guys, I'm pretty sure you are very technical. And what you can understand is security. But when it comes to different standards and papers and, like, 200-page documents, well, it's very boring. You can become sleepy. It's okay, actually. But still, it's very important to understand what compliance is and why we as, like, open-stack community should think about it. Actually, if you look at the standards, like, different guidelines, regulations, et cetera, what we will find that most all of them are about information, about its availability, confidentiality, and integrity. And only the part which is about confidentiality is more about security. Other parts, they cover all the different topics of the whole, like, your customer system. And, of course, for people who write code, it's not that obvious that it is important, but it is important for companies. And as long as, like, open-stack is now pretty mature and we go enterprise, we build private and public clouds for banks, like Wells Fargo, we build, we deploy open-stack clouds in different, like, the U.S. government organization. What we should think about is, like, that this cloud, they should follow the rules this organization have, organizations have. And these rules are different types of standards. Well, let's take a look at the, like, the whole enterprise ecosystem and the open-stack in it. So as you can see, we have, like, physical facilities, we have data, we have open-stack, we have people, we have business processes, and this whole ecosystem, it should follow the regulations, different types of regulation, which means that, like, open-stack as a part of this ecosystem must follow these regulations as well. So, practically, if you look at the situation the way we have open-stack cloud deployed, and now our customer owns it, so he or she is the one who is responsible for the whole compliance. But we, as the people who develop open-stack, who build open-stack clouds, we are responsible to deliver the product, the solution which can be compliant in a very easy and, like, painless way. Here I decided, like, to show you, like, an example, that it doesn't matter, either you build, you're building, like, infrastructure as a service, or platform as a service, or software as a service, you see that the open-stack is that layer that, alongside this processing and physical facilities, all these three layers, they are on your side as a cloud builder, which means, which means when you come to service provider or to a kind of private company where, and you build a small private cloud for them, you are the one who should, like, do all your best to make all these three layers as much compliant as possible. It doesn't mean that the whole, like, ecosystem will be compliant. No, these people, they have things to do on their side, and Scott is going to tell you a lot of things about it. But, anyway, this is how things work. This is why we should think about it. Well, it was, I talked about, like, standards. It was a kind of justification part. I tried to, like, convince you that standards are important and compliance is not boring. I know I was boring, but it's okay. Now, let's move to the standards. And here I have, like, a very short list of standards that we use, I think all of us, we know. Like, PCI-DS says it's a payment cart industry standard. HIPAA is a healthcare standard. We have SOCs. We have some very specific government standards here, like FISMA FedRAMP. They are not more, like, standards, but, like, procedures, programs, guidelines for OD, like, for things that you should be done in order to be certified. We have ISO, very, like, very basic, but at the same time, very important standard. We have NIST. We have actually a bunch of NIST standards. These particular standards are about, like, security controls, but there are plenty of others that some companies, they should follow. It depends. It depends on the, on the business model. The company follows. It depends. Either it's a bank or a private company or a public company or government organization or a science institution. Doesn't matter, but a lot of standards. And the second question that comes, like, to everyone's mind, why should open stackers think about all these standards? And how they could know about all these standards? They're just, like, people who write code, who deploy clouds. They know a lot about virtualization. How should they know that they need to read, like, SOCs or whatever? And how should they know what they should do to be compliant with it? Well, good thing, good, like, good news here is that all these standards, like, almost all standards, they have pretty, like, typical structure. And it's, like, standard, a bunch of requirements, and each requirement has a bunch of controls. And actually, there is a tendency in the community, in, like, compliance community, just to take all these controls and have, like, metrics, have, like, a set of controls that covers, like, all different types of standards. And the best news here is that, actually, the job, specifically for cloud standards, is done already by, by CSA. And actually, they have around, like, I think, 140 controls in one place, in one matrix. And they cover PCI-DSS, hip bind, all other different standards that are usually important for our customers, like, for different companies and for open-stack customers, of course. So, and if you take a look at the, I think you can see, if you take a look at the slide, you will see that in control specification is written something really generic, like, security mechanisms shall be implemented to prevent data leakage. So nothing specific. And that's true about almost all the standards, like, here's PCI-DSS. Like, all these standards, they have requirements and controls. They are pretty generic. You won't find words, like, open-stack, cloud, I don't know, cloud, like, KVM, or something, like, super specific. This is how they were designed. And probably, you know what standards, like, your open-stack cloud is a part of organization ecosystem should be compliant with, but you don't know how to do it. And maybe, like, two or three years ago, nobody knew it. But now there is a tendency that different organizations like PCI-Conceal and NIST, they are working on it and they implemented a bunch of guidelines on how to map those requirements from these generic standards to cloud infrastructure. They are working hard, but still, you know, like, if you take a look at PCI-DSS cloud guidelines, what they say, oh, please don't store process or transmit payment card data in the cloud, because they don't know how to deal with it. And actually, there are some technical people who know how cloud works. So they can say, like, it's okay to store and transmit data in the cloud. You just need to know how and to be very, like, very, very smart to do it, yeah? Well, anyway, if you take a look at another PCI-DSS guidelines, you'll find more, like, specific information, which is pretty useful. Now we see words like VM images and virtual system, which is very helpful. Still, nothing about OpenStack. And actually, you won't find, like, anything very specific about OpenStack. That's why, you know, we have this kind of really interesting situation. We have OpenStack is pretty mature now that we know that clouds we're building, they must be compliant with different standards. Different organizations that publish those standards, they understand that there is a cloud, clouds, and there is a tendency for different companies to go cloud, to go up. And now we need to work, like, in both directions, like, like PCI Council, they publish some kind of cloud guidelines. And what we need to do now is, like, to hear, like, the OpenStack community, we need to take those guidelines, take our expertise, and to create a bunch of guidelines for OpenStack clouds to be compliant. How to build a cloud that can be compliant, that can be secured, that can follow the rules, like, different types of rules. And as you probably know, OpenStack has an OpenStack security group. They published a really nice document, OpenStack security guide with a section about compliance. It's very interesting, it's not that, like, complete kind of limited, but guys, they are really working on it. And Scott, one of the guys who's going to, he's going to say a couple of words about it, I believe, but he's the one who's going to contribute there. And also, I know different companies, they are struggling, like, with compliance issues, so they kind of have, they invented their own way how to be compliant. Like, we at Mirages, we did some stuff for PCI compliance. And some people from our team, they presented the previous summit at Hong Kong. So, here you will find the link to this presentation, so feel free to see it and to watch the slides. So, and practically, actually, like, I think that's it, yeah. My talk was more kind of educational and just to say that, guys, like, clouds, OpenStack clouds must be compliant. There are a bunch of standards. And as long as these standards go on the way to cloud, OpenStack as a cloud technology, need to go towards the compliance. And now I'm going to pass the ball to Scott and he will provide you with some really nice use cases. So, thank you. No. Hello, hello, hello. There we go. All right. So, Scott Carlson, I work at PayPal, and I am the cloud security architect for PayPal. One thing that is important as I go into this presentation, a lot of the compliance talks at the past conferences have included a lot of information around what compliance means, like nobody has ever had to do compliance before on infrastructure in a data center. And what I want to make sure everybody understands is compliance means something specific for you. But there are some key things that you need to remember when you take a look at compliance, decide how it sort of fits in your use case. And what's nice is it shares a whole bunch of different sort of common things that apply to OpenStack as well as elsewhere. As you can see from our cool new infographic that we just came out with, we are everywhere. PayPal does business in a lot of markets and a lot of countries. And especially if you look at Asia, the EU, Brazil, the United States, there are compliance requirements for all of these countries, very specific to their country, but many of them share a lot of the exact same underlying sort of foundational elements that are in all of the majority of the standards that she just talked about. When we apply our sort of take a look at our company size, the cloud that we're building has to go across multiple geographies, multiple countries, as well as multiple data centers. So when I look at compliance, when I take a look from the PayPal side, I have to think what kind of things can I do to make sure that my cloud comes out of the gate pretty compliant no matter where I build it. So that's why PayPal has started to focus on a data center that we can define with software. Of course it has physical components like switches and firewalls and routers, all those common things that you need to build a network. But there's some common principles that we want to do out of the gate as we build new Havana based clouds, ice house based clouds to ensure that we at least get these minimum set of criteria out for compliance. Some of the things I think people can read, I won't cover the slide specifically, but common things that apply to most virtualization environments and most clouds that you build include good design principles, templates. What do you do with templates if they're on and they're off? What do you do with common infrastructures to deploy one image everywhere? Other things like scale up, scale down, what do you do when you turn the VM off? All these things people have looked at in the VMware space for a lot of years. So it really doesn't need to be that different with OpenStack. You can really make your brain hurt. If you take a look and you say, oh no, OpenStack is a brand new thing, how in the world am I going to ever make a compliance since there's no NIST document called how to make OpenStack compliant? The thing that we're concerned with at PayPal is yes, we need to be compliant, but we also want to be secure. Securing our customer's information is the most important thing for us and we want you to feel comfortable when you do business with us. So out of the gate, what I think I'll focus on mostly here in terms of the general criteria, and I want to sort of talk to you guys like you've done this before, right? SmartSys admins in the room, people are building clouds, but we're going to focus on PCI2. PCI3 is different enough. It starts to get sort of a little bit more aggressive, but let's start with PCI2 and let's figure out what sort of the minimum set of criteria is. So I think I've broken this down into some basic methodologies as well as common things that should make it more easy for you to think about how do I secure this, how do I make it compliant? The one thing out of the gate, OpenStack has servers in it, right? People know how to secure servers. There are NIST standards for secures. There are CIS standards for servers. There's hardware there, right? People know how to do firmware by now. So take a look at your firmware. Dedicate the hardware to the cloud. Hey, that follows the guidance, right? Don't share workloads of different security zones on your hardware, okay? That's pretty easy to do. You want to do that out of the gate. Follow the guidelines for servers. Hypervisor builds, right? Everybody is wondering how do I put down a cloud layer in my private cloud that's compliant? Well, you know what? People have been doing that for a lot of years. The government started it a long time ago. We have IP tables. We have trusted compute. We have all sorts of different ways that you can do it. But really, it's still just a server. So once you get a build standard, which I think almost every single compliance document you read has, have a build standard that is secure, that you scan with a vulnerability scanner, that you patch every 30 days for critical things, that you keep updated, that you have inventory of. It's pretty much word for word in every single standard. The same applies to OpenStack, security, and compliance. You get that vulnerability scanner and you point it at your OpenStack, and it's going to scan Ubuntu, Red Hat, Debian, whatever you have your cloud running on. And it's very likely that that scanner you pick is going to pick up all of those, you know, mostly known vulnerabilities in your hypervisor that you can pretty easily bake into your image that will go anywhere. There's nothing too specific to the U.S. or to other regions about doing that hypervisor. Some of the things that get a little bit more challenging as you sort of look at your hypervisors, how do you patch management, how do you do configuration management, and password management? With the passwords are easy, right, root, and you rotate them and stuff. Config management and patching is tougher in a cloud space. If you're the cloud provider, which PayPal is both in my case, I'm a private cloud, so I built this cloud in my already PCI certified data center. So in essence, I can take advantage of my company controls around my entire data center. I'm not building a cloud for other people to use, and I don't need to worry about separating the managed service provider space from the tenant space, which if you read a lot of the guidance that's out there right now, it actually says if you're a tenant, just go ask your MSP for a certification statement on this. If you go to people like Amazon, they have eight or 10 documents that you can get now that say how they are PCI compliant at the various infrastructure. So in essence, I provide that for myself by following my common practices. Moving on to the next thing, there's users in OpenStack, just like anything else. You've got to follow the standard things. Don't share passwords. Don't share accounts. Create separate accounts. Use different tenants for everything. Don't use your administrator account to build everything. Rotate your passwords just like you would. What you can't do, which we have argued about this inside of PayPal for a very long time, why can't we just use common things? It's just one data center, why shouldn't we just use one building account to build everything? The reason is because it's very slippery slope to get into a non-compliant space. You create an environment that all of a sudden opens up gaps to anybody getting in to do bad things to your network. So do not break the rules that you wouldn't break if you were deploying physical Unix systems when you're building your cloud portal. I think that's very, very important that you do role-based access, like is enabled now in most of the tools for your users out of the gate because that will make you compliant with just about everything out there again. How do you be secure and compliant? Do the basics first. Let's move up the stack a little bit here. Hypervisor components, right? Again, it's just Linux, right? Harden it like Linux, lock it down. If you tell your auditor who's coming in to do PCI, a HIPAA auditor, whatever, and they say, how have you secured your environment? And you say, I took the NIST standard, and I pulled out the steps in the CIS guide, and I hardened it according to that. And here's my checklist. And then I scanned it against that. The questions pretty much stop outside of, okay, show me a couple of examples and prove it. So don't forget to log it. One thing that's interesting about the hypervisor in a cloud space is how do you separate the management traffic from your guest traffic? There's a lot of different ways to do this. And depending on how you build your infrastructure, you can separate at the NIC level. You can separate at the virtual VXLAN sort of level. You can overlay it. But the important thing is that you design your network in such a way that your management traffic is going to be separate from your tenant traffic if you're going to be in a compliant location. The one thing that you don't want to do, so maybe you can, but you shouldn't in my opinion, is combine it all because the minute you do that, every single management component that you bring into the picture now is in scope to be audited. If you have a credit card workflow flowing through a tenant in your private cloud, but you allow your management traffic to talk to that tenant for some reason, now your entire management control plane is in scope because it touched that cardholder data. As you design this, it's very important to consider what touches what and what can talk to what. Because as we look at PCI DSS3, it basically says the minute you touch cardholder data, that's contagious. And everything that touches that now has to be audited, logged, just like it's the most secure thing. Don't combine security zones, and this is an important one. All of the cloud guidance out there right now essentially says that you shouldn't do this. You probably can now. There's containers, and there's IP tables. You can probably harden your hypervisor enough to have a in scope zone and an out of scope zone on the same piece of hardware. I know that VMware has some good guidance for vShield. I know that no such document exists for KVM today, and that's something that we all need to mature if we want to do this. But as of right now, you will not get any questions if you decide to separate hardware between zones. You'll probably get the question from your management, why do I want to waste that compute? How could I dedicate so much hardware to an in scope zone versus a not in scope zone? And the trick there is just do it at a granular enough level, which in our case is one single physical machine. You put it in the right place. Nobody really cares about wasting machine. If you waste a row or a rack, that's a whole completely different scenario, so make sure you do it at the machine level when you separate. Let's see, auditing. Auditing, auditing, logging, you'll never find a compliance standard that doesn't say log it. So everything you can turn on, turn on when it comes to off events. Take all those off events and stick them somewhere. I don't know if you use syslog or Splunk or log stash or I don't know, pick your log thing of choice, but put it there and keep it a long time. A lot of these things require seven days, prove it for a year. I know one place that I used to work, my auditor would come in and say, okay, it's August. You guys laid off a bunch of people in May. I want all the logs from you revoking their access in May from your credit card zone. You haven't till tomorrow. And so my team was able to do that because we had kept it all in one place for a year from all the systems. And so I know when a lot of people are building a cloud to try and get it up, a lot of these off events are not turned on by default. They're just starting to get now, but in the past they weren't. Especially login events to Horizon or who created and deleted a VM. Some of the more interesting use cases that we haven't yet sort of figured out is let's pretend my audit is January to January, right? January to December. And during that time PayPal goes through this Black Friday cycle, right? We build 10,000 VMs in November to handle Black Friday, and then in December we tear them down because Black Friday is over. If I built and destroyed 10,000 VMs, are those VMs still in scope for PCI compliance when my audit happens in January or aren't they? Yes, right? A lot of people are shaking their head, yes. So I have to prove that I created them, got rid of them, and really deleted the data, and then who did it? So these logs are very important that you don't just assume you don't need them because you kind of almost have to assume that your guy is going to ask for them and that you'll have to bring them back up. So don't just get rid of them. Keep them forever. Oh, let's see. So be ready to defend your shared portions. This is sort of common thing. Physical world, we've been doing this a long time, right? People share routers. People share firewalls. You don't really need to buy two firewalls to separate your secure zone from your unsecure zone because that's the point of the thing. But have your diagram ready. Have your decision process. Have your architecture ready. Prove that out. Let's talk about the software for a minute here with OpenStack. You can't really buy something like HP Fortify and say go scan OpenStack and tell me it's compliant. It's mostly Python, right? There's not a whole lot of good Python security scanners out there yet. And what you won't do is you won't get a static code analysis of Python that will tell you that there are bugs in it. This place is maturing pretty quick, and a lot of the OpenStack security group is trying to find ways. A lot of the vendors are coming into this space now, specifically, you know, HP is starting to scan their cloud more. And as people create security as a services around some of these things, you will be able to do this sort of, you know, do code analysis. But in our case, so we check out from trunk and we do basic things like would be expected. But one thing that in Scott's opinion here, my opinion, the community needs to look at this over the next couple of years so that as more and more very large financial companies start to deploy this, there needs to be a very easy way to say yes. In fact, this has been scanned 100 million times by every single tool in the market. The version, you know, let's call it Havana, Havana Core as of August passed all of these tests. Here is the practitioner statement. And we're based on that. And as auditors get better at that, or more aware of it, I guess is what I mean, because not a lot of auditors know cloud, let alone OpenStack right now. And so some of these, you know, cloud security lines, all these things, once they get these statements out there about the software, then they can start to do better safety controls over, oh, this is all open source. I'm scared of open source, right? Because I have no idea what bugs were introduced. So a couple of interesting dangers around just checking out from trunk and applying it to your production cloud, I would say just don't do that. You know, check it out, Q8 all the way through the normal cycle, CICD, I think one of my other colleagues is talking about that at this conference. Some of the other things that you really want to do, specifically around OpenStack, make sure you have an open source advocate in your company who follows the licenses, and we know it's compliant from that point of view. It matters in some countries versus other countries. Make sure you do scan it. Somebody takes a look at the code, however your level of comfort is, so that you can prove, you know, at least some level of diligence there. And one thing that I think is really important to add about the software stack is, right now, I think it's very important that you avoid putting any sort of card holder data or compliance data on your cloud itself. That's what guest VMs and tenants are for. Do not compensate and say, oh, I just am going to put this cool thing at the hypervisor so that I can blow it out. I'm just going to put it in the image so that I can blow it out. Just don't do that. Because, again, you run the risk of bringing everything in scope, which you probably didn't want to do. And if you want to get to the place where you can start to descope some things, you will have just messed yourself up by putting your compliant database on a bare metal image on the same v-line as your hypervisor. All right, so this one is kind of more advice based on the stuff we've talked about. I think we'll call this Scott's opinion for now. Stick with physical components. For now, don't go with virtual components when you talk about in-scope compliance separation. Everybody, I think, in the compliance world auditors, everybody speaks physical components today. If you justify your load balancer as a firewall, if you justify your firewall as a firewall, if you justify your switch, router, v-lan, configuration, you'll be okay, because everybody is used to that. The minute you start to bring in virtual components in, you have to bring in the hypervisor, and you have to bring in the network, and you have to bring in the network design into that conversation. Because if you have the most secure firewall living on the least secure hypervisor, there's no point, because you can just bypass the firewall. It doesn't serve the purpose. There are people who are starting to build architectural blueprints to explain how virtual components are good enough. Vendors who roll their virtual component as an ISO that lives on hardware, you know, that's kind of a physical component at that point, because it doesn't live as a guest on top of OpenStack. But what doesn't exist today is a sort of certified reference architecture for how do I take my HA proxy and my virtual ASA along with my virtual F5, how do I stick them together on one hypervisor and call that a compliant cloud? That doesn't exist today because not enough smart people in the community have certified that there's no way to bypass that. The clouds are still a little, I guess, squishy enough where that sort of between component traffic, intratendent traffic, hypervisor traffic, manager traffic, we're still not sure if it's 100% protected. And I guess, in my opinion, until we know with reasonable level of confidence that it's 100% protected, it makes a lot more sense to just externalize these really important things, especially when you're living in a data center like PayPal, where we do this for a living. And nothing wrong with staying physical for a while. And the same thing applies for physical as virtual, I think I want to say this. So if you rely on, you know, F5, for instance, you can go to them and you can say, how well have you tested your physical load bouncer? Or your physical load bouncer with a firewall? Hey, Cisco, have you tested your firewall? And they'll say, yeah, here's all of our statements for the last 10 years that we've tested this. If you go ask them to do that the same thing for virtual, I haven't had anybody ready to give me a piece of paper yet today that says they have tested their virtual thing at the same level they have tested their physical thing. And so I'm challenging all my vendors to give me a statement on their virtual thing. And hopefully they all will, so everybody push your vendors to do that with virtual. If we're doing dynamic clouds, we need virtual stuff. And until they get on board and they certify their virtual thing, you really can't use it in your cool dynamic cloud. Let's see, last slide here. So basic methodology about data, right? It's car holder data, kind of get interesting. Open stack has some native encryption challenges. There's lots of cool little blueprints for relying on the cloud services to encrypt stuff for you. I don't think we're really ready yet unless you want to be bleeding edge to rely on that to encrypt your really cool stuff. So you should just rely on stuff you do today in physical. Use your HSMs, use your key management, use your crypto, take care of all that stuff yourself. There's nothing wrong with building MySQL on your cloud and encrypting your stuff in it as long as you do it the normal way, like you would on physical infrastructure. Just don't rely on your cloud. In my opinion, it's not ready yet. There's no FIP certification, all those kind of things. It's coming, you know, 18 months, two years, we might be ready. Pay attention to your data. Be responsible for your own data on your cloud. Don't rely on your cloud to control your data for you. And then the last thing about users again, it's very specific that you log who's touching the data, what tenant it's involved in, who has access to it. And if you can, start to implement your edge controls. Some of the sort of in-between tenant things like IDS and data movement and behavior isn't there yet. Some of the hooks in VMware made it there two or three years ago. They're not quite all the way there for KVM yet. But at least around your edge or on your tenant, you're going to want to watch what your users are sending in and out so that we can go from there. So I think that's it. Feel free to tweet me or find me afterwards with questions. I think we just have a few minutes left. If you have a question for either of us, please feel free to come up to a mic and happy to answer them. Maybe you have some, you know, like statements to say about compliance. That would be nice to hear to actually. Or if you disagree, please. Yeah. You know, it's like a really hard topic now for OpenStack. So maybe guys, you have something to say. You're welcome. I might go over here. Yeah. So a question about the physical network components and kind of maintaining a boundary. And so you were making statements that at least I interpreted as, okay, so if you keep stuff out of your hypervisor space and keep it in your cloud space, that's good, your data, keeping that separate and keeping it up there above the hypervisor, if you will. Where do you bring in your physical network components without having had some sort of a virtual networking component that just kind of naturally lives within the hypervisor as far as separating out your tenants and things of that nature? Yeah. So I think the way that I'll answer that is in a standard layer three design, right, the default gateway or the route out is through your firewall. So as long as you have different layer three spaces in your in-scope and out-of-scope space and you make, allow them to talk to each other through that firewall, the out-of-scope device, then that's where the physical component comes in. You let everything play together over here and you just assume it's in scope. Everything over here is out-of-scope and the only way to talk to them is through that firewall. Okay. So we have a single user that instantiates all our VMs, but we control access to that pretty heavily. Can you talk more about the weaknesses of that and, you know, I mean, we need to tear everything out. The weaknesses of a single user doing things. Of course, there's lots of it depends in the answer. If your company has a build team that is the team that builds things, you can usually compensate for that with process and pass your compliance audit. Is sharing an account amongst people that you have to walk around with a post it's secure? Absolutely not. And that, I think, is the difference in this thing. You can for sure pass compliance because you have a procedure and a process to manage this and you know who does it. But you can't prove who did it because it's Cloud Builder. You don't know if it's John, Fred or Bob. So you're not necessarily secure. Right. But we're logging who has access to the Cloud Builder and like whenever they instantiate a VM from the Cloud Builder, that gets logged. So their source IP address on your net at internal network? Their username. But didn't you just say you're sharing the same account? Yes. So the in the open stack world, it's a single account, but we have an access system that lives above that. Okay. Who has access to that system. So again, I think you can, as long as your front door is unified with nobody has, you can't get in the front door with your Cloud Builder account, then you're, I would say you're reasonably okay. If your back end demon account is the one that runs off and does things, it's sort of just like using HTTPD, Tivoli, TSM. Those use common accounts to go do things. And as long as that's abstract enough and your password isn't baked into the files, you know, clear text like in some versions of Essex and whatnot, you're pretty okay there. As long as you're RBAC on the front controls that. Scott's opinion, I'm not an auditor. Over here. Most of the compliance require you to tie to a particular release and patch. Now, given the fact that open stack is a open source product, right? And given the fact that it's not compliant. That's a vendor. How do you make sure that you're tied to a particular, I'm talking about standards like 5th 140 and so on, right? How do you make sure that you are tied to a particular patch and a release and you actually certify that patch and release for, because when the patch changes, you need to re-certify. You know what I mean? Yeah. So I guess the way I would answer that as I would say, you need to build your own snapshot methodology for your own internal release management versioning. If you check out once a month or even daily, right? You're probably not going to release them into production daily because it's just too scary. So you're going to want a snapshot at your own, you know, company 1.1.1 is my release candidate, which is Grizzly, August 14th, right? If you bake that and call that a version, I believe it also complies because it is open source and you versioned it yourself and you're tracking it like it's a real version. If you then, you know, put that in an RPM and MD5 it, then it's a real version. It's just controlled by you, just like you wrote it in-house. And so that's how I would answer that. Thank you. Yeah. One more over here, I think, and we're done. Go into your comment earlier about using Linux containers and IP tables. I worked for Oracle in Solaris. We recently worked with Coalfire to help provide some guidance for separation of PCI DSS versus non and using Solaris Zones. And they were very comfortable with that. We've written up in a white paper. So the fact that we've got that, you should be able to use the same thing for the MD who wants to deploy Linux containers because they're similar architecture. And it is all about saying, you know, there's layers in here. In actual fact, something like Linux containers or Solaris Zones are actually more secure in some ways than running in, you know, a tight one hypervisor. Got less of a surface and you can point to more things and show the auditor. It's actually locked down even tighter. Yeah. I appreciate that comment because you did it the right way. You came up with a roadmap, a white paper that showed how it was secure and you can prove it on the back end. And so if the community at large does that with all these components, then I think we're in a good space because people can just follow it for whatever the thing is. So if MD wants to try and do the same thing for Linux containers, that would be great. Solaris Cold Fire White Paper, PCI-DSS, you'll find it. And there's enough information in there to translate it over to them. Solaris Cold Fire? Cold Fire. So Cold Fire was the QSA that we worked with. Got it. Sounds good. Guys, everybody, thanks very much. Appreciate your time. Thank you, guys.