 at the mic. There we are. Good morning. Thank you everybody for coming to my party. Hello. No, come on. It's like four 10 on the last day of the conference. We're all just going to kind of stand up and stretch a little. Like, I was in here 20 minutes ago. Half of you haven't even left these seats. Come on, up, up. It's only one session left after this. It's going to help me stay energetic too, right? That and no small amount of chemical assistance, right? So to make sure you're in the right room, we are the practical open-stack, or, yeah, practical open-stack cloud hardening and PCI DSS readiness. That is totally not the title it had when I submitted it. I went out of town. Somebody manipulated it. And poof, here we are. But it's what we're going to roll with. I'm Cody Bunch. We have Rand. Rand Wacker. Yep. And that's it, right? So let's get to know each other a little bit here. I work for X-Base. Well, actually, you'll get to know me on the next slide, right? You can totally tell we're ad-libbing this slide deck, right? No practice. So who in here works for a provider? Or are you an end user of open-stack? Or how many of you in here actually work for X-Base? I asked that question earlier. It was like 50% of one of my rooms. That was no fun. OK, now I'm embarrassing myself in front of my coworkers as well, not just like random strangers. So because this was actually supposed to be two separate talks, Practical Cloud Hardening and PCI DSS as two separate things, not that they're entirely separate. There's a whole lot of overlap, but they can be treated as separate entities. So who's here for the Cloud Hardening part? And who's here for the PCI part? OK, almost the same set of hands, which is fine. Good overlap. And then who actually works in some manner of InfoSack on a security team, something of that nature? OK. So judging by the number of hands that went up, you guys are the experts. Please feel free to stop us at any point and make fun of me. So I'm Cody Bunch. I'm principal architect with the Rackspace Private Cloud Group. Yes, that is a cartoon. The PR shot was a little blurry, so I made the best of it. Principal architect means anything on any given day. Some days, like today, means I'm talking security. Yesterday, it meant I was doing a hands-on interpretive dance with Quantum and Cinder, my Quantum spirit fingers. So I've really been a jack of all trades. I've done InfoSack at prior employers as well. So I do have some experience, but not as recent as most of the room. Rand Wacker actually came up here with me and Cody connected earlier this week and wanted to talk about some of the PCI aspects of running servers in an OpenSack cloud. Our company does security compliance automation for cloud infrastructure. My history, background, Cisco security, I report before that and whatnot. So my picture, unfortunately, is way too long ago when I had way too much sleep. But nothing like that today. So a little bit about what we're going to go through today. PCI in a cloudy world, what that kind of means or what that looks like. A little bit of infrastructure security, shared responsibility model. Ultimately, at the end of the day, we are responsible, but when you trust in a provider, what that actually means. A little bit about hardening OpenStack, hardening the guests, and then if we get some time, how to actually integrate compliance into some of your CI, CD stuff. Okay, cool. So a lot of folks raised their hands as part of the InfoSack community. How many of you actually been through a PCI audit? Okay, good set of hands. So it's a good experience. So I'll go pretty fast through the details in a couple of slides. But the first thing that actually spend a lot of time talking to people about is that for the past few years, there has been this assumption that PCI can't work in the cloud, either for various reasons of control or ownership or those kinds of things. A lot of that has been clarified. And earlier this year, the PCI CloudSig did put out a set of recommendations around what you can and can't do. And there's definitely some on both sides in that environment. And I think it speaks really well to the general approach that we need to take to security in the cloud in general, which is we cannot take our old style model of perimeter security and owning everything in the data center and doing all of that and expect it to work in this environment, whether it's public or private, in particular because of the way that even a private cloud model is very, very distributed and very, very dynamic in a way that traditional security controls just really didn't work that well or would freak out in an environment where your IP addresses are changing so rapidly and those kinds of things. So the biggest challenge that we've seen with regards to people looking at any kind of compliance in the cloud is that this lack of understanding has immediately led people to say that things are unsupported and that's just simply not true. So we recommend that people kind of go through pieces. There are people doing PCI compliance in the cloud today or in a private data center, all these different pieces and you just have to rethink the way that you're gonna put those controls into place regardless of wherever your resources are running. In particular, if you're starting to do compliance in any type of infrastructure as a service environment, you really need to rethink the responsibility and while we're focusing mostly today on private cloud, I know that in 80 to 90% of the open stack people that I talk to, their ultimate goal is to be able to burst out and do some type of hybrid cloud deployment and so keeping in mind that if you wanna go from this environment over to this environment, you have to make sure that your controls can operate in both of those infrastructures and so the very last bullet on the very last slide is gonna actually give this trick that I've heard a lot of people talk about which is if you need to figure out how to do security, operations, compliance or whatever in any kind of environment, even if it's just private, figure out how to do it first in a public cloud environment because the public cloud environment is the most restricted environment out there and once you figure that out, then it's very easy to do it in this environment and the reason that you really need to pay attention to that public environment is that in that environment you have a shared responsibility between the provider and the customer and in an internal system you have the same thing so if you have the IT team running the shared resources for the open-staff cloud and the application team or the payments team is responsible for the servers that are actually doing the PCI processing, then they need to come to an agreement. Luckily they're in the same organization, it's easier but that's a really key piece to keep in mind as you're thinking about how are you going to build on top of? That's not always easier, by the way. All right, good point. With a service provider, you can end up with that in your SLAs as part of your contract or so this is where our demarcation ends and yours begins in an internal IT team that may or may not, you've got 15 guys total, it may just be a gentleman's agreement. Yep, yep. Cool, so PCI in general, I'm not even gonna go into all these, you guys have been through it before between the access control, the host's integrity, the IT security processes and everything that's there but do note that there has been recent updates from the PCI cloud SIG and these apply to private clouds and open-stack in particular because they have made a lot of clarifications around things like security in the hypervisor versus security on the guest hosts. So that's supposed to be in green or so? Yeah, it's not, just pretty well, sorry about that. Yeah, sorry, some of those up there. And they've gone through that but let me actually skip to this slide which is kind of a good breakdown, this is actually, or this is from Dave Shackleford at IANS, between in the SAS world, we're used to the provider taking most of the responsibility but in an IS world, either public or private, you really have to understand who's responsible for both those pieces. And the last thing I'll do before handing this back to our esteemed hosts is I wanted to call out actually when we did a survey internally about what compliance rules people needed to worry about for their cloud environment, got a long list and some surprising items up there but as you all know, in many of these cases the controls overlap and so for example, HIPAA high tech actually had guidance updates again this year as well as PCI, so many of these folks are evolving, many of these regulations are evolving to understand cloud computing, infrastructure as a service in a private or public environment. That means SOCs, yes, but SOC to SSA 16, this is about six months old, I would definitely put that up on the list. Okay, okay, so next we're gonna jump into the actual practice, yes, what it says up there. Okay, and maybe I'll actually be able to English the next slide as well, right? When it comes to hardening open stack or hardening a cloud of any sort, right? Practicing good hygiene is critical, right? Why does your 10 year old still get cavities for those of you that have kids, right? Brush your teeth, floss, like put the deodorant on so you don't stink, right? It's the fundamental things that get missed the most often, right? So when you're building a cloud or so start with that good foundation, start with that good hygiene, start with the way you've been building your physical plant, right? You still need to make sure you have key card entry on your data center, right? Or that the front of your cabinet's lock if you're in a colo facility, right? Start there. What else do I have up there? Hypervisor security, so if you're using KVM on an Ubuntu install, make sure you've followed best practices for hardening and Ubuntu where that applies, right? Or Red Hat, right? Try to use SE Linux if you can. That may or may not be a good idea, right? Could be more pain than it's worth, but give it a shot, right? If you're working with a provider, make sure they have whatever certifications or I'm not even gonna try to pronounce that this late in the week. Patch management is still important. Guest hardening is still important and we'll get into some of that a little bit further. Just throw in real fast. If folks were here two sessions ago for the excellent open-stack security group overview, the hardening guide that that team's gonna put together I think will really help in this environment as well. So we're all very excited about that and wanna help out in any way we can. Yep, and then the last little note when it comes to open-stack hardening is you will need to change the way you do things, right? If you buy a Roomba that's gonna vacuum your floors but you forget to take your dog out, you know, things happen. It doesn't always end well, right? So in the cloudy world, you're going, you know, as instances come up and down and they're ephemeral or so and don't last very long, you'll fire up an SS scan and then like half of those port or half of those IPG scan won't even be in existence anymore, right? By the time you go to audit them and like why did that show up in my report? So you're going to need to adjust and start integrating that hardening into how you're actually provisioning those instances. So if you're using a chef or I'm actually getting into the end of the slide deck instead of the beginning, but it's important here. Actually, we've kind of jumped. Yeah, we've jumped into the guests. So what we'll do is we'll... Keep going through your section and we'll jump into that. Yeah. So secure the foundation. We touched on that one, post-security. We touched a little bit on that one. And then when it comes to network security and demarcation and so on, the slide we borrowed from, what is it, two presentations back? Yeah, so that is not even all of your ingress and egress and all the various points where these things touch. Yeah. Okay? So not only are you going to want to run that on a private management network, you're going to want to apply the appropriate ACLs. You're going to want to start orchestrating, where is it? Actually, there it is. Start orchestrating your IP tables. Maybe use SE Linux, limited user accounts. What networks do you really want going where? Maybe you want Keystone and whatnot to have a separate management network because it's talking to your corporate active directory or something of that nature. So you're going to want to carve those networks out and secure them appropriately. And you may actually want to investigate to find the other 50% of those wires. Right. So we jumped into the hardening of the guests at first. At first? It's Cody's birthday. It's all saying happy birthday. Jared, you're going to start? What? Let's keep going, we got so much in time. Cool. Okay, so, cool. So, you know, so everyone's locked down the whole OpenStacks provisioning, right? That's easy to do, obviously, from that last slide that you saw. So, good hygiene doesn't stop there. You really need to worry about what you're doing on the guests as well. So everyone here knows that all the people that think that security's done once you have a firewall installed are missing about 80% of the story. And so when it comes to actually securing the guest VMs that are running, you need to take into consideration a lot of the traditional host-based security controls that people used to run in private data centers. First of all, in a cloud environment, the idea of host firewalls works really, really well, because if you need fine-grained control over which servers can talk to which, then you're going to want to do that and as basically small or small of a surface area as you can. You really need to look at the operating system. You need to make sure that the base images you're launching out of are hardened and patched appropriately. There's a lot of examples of base OS distributions having some pretty egregious gaps in their configurations and you want to root those out as early in your process as possible. So on that one, Ryan Yard and Evan, not Evan, the other calico, earlier this week gave a talk on how to integrate image building and dumping those images back into glance with your CI CD tools. So it's part of that image building and keeping your images continuously updated is really, really important. Yeah, and I'll actually go through a couple of slides and talk about how different that is in a cloudy way of operations as opposed to traditional long-lived servers. The other piece you need to look at is your application stacks, like as well as having the OS locked down or the application stacks locked down and then your individual code. So traditionally, people would use things like configuration security management tools for the app and the OS and then they'd use file integrity monitoring on the core binaries there and on their code and those pieces. So you need to figure out how to run those on each of the guests in a way that's not gonna crush those servers. And then protecting the data. Definitely, you gotta protect what's going in and off of that box, but also you need to look at encryption capabilities. There's been a lot of talk this week about Cloud Keep and some very interesting stuff that's going on with key management as a service. The other piece though is that all these controls need to be designed in a way that's gonna run anywhere. If it's on VMware or if it's on Xen or if it's in the cloud, if it's at any of these providers, you need to figure out how you're gonna automate and really make sure that all these things can stay portable in that environment. Because vast majority of folks here are talking about OpenStack unless you truly have an air gap requirement are thinking about moving to a world something like this where you've got your traditional first generation virtualized data centers or bare metal servers. You're now moving to the sexy new infrastructure as a service cloud and I bet sure as anything that you've also got people who are out there running in different public clouds. You probably have all three at once. Exactly. At least. Who's got at least two of the three? Come on, there should be more hands than that. And if you're not raising your hand, you just don't know if it's probably not. Yeah, we don't know yet. So in these cases, elasticity and migration are key goals. There's been a, I actually tweeted something earlier today that I was frustrated by some of the fud about security that some people in the security, the fud about cloud that some people in the security community say that we can never solve these problems X, Y, Z. But you really need to rethink the approach when you're talking about a world that's so much more dynamic as cloud is because fundamentally I think the theme of this entire summit has really been the cloud equals agility and people are starting to realize that if it's self-service, if it's full automation, if it's metered uses, if it's API access, those kinds of things. And security teams never thought about that kind of environment. And so the cloud folks, the folks in this room really understand what they need to do, what the benefit of this technology is. In some cases, the security folks need to really rethink the way they're doing things as well. So real quick set of slides as Cody was, was alluding to earlier, that kind of illustrates the difference between traditional DC operations and what we're seeing with regards to automating security for cloud instances. Most of us are familiar with a traditional DC operations model where you have long-lived servers. Put up a system. I don't care if it's physical or virtual, but those are usually static. You patch them over time. Things degrade as things happen, but you were always protected by that outer defense. Keep the puppies in the fence yard. Yeah, exactly. The puppies metaphor, that one. I love that one. This is my favorite this week. In the cloud, you've got a lot more cows. I'm gonna change these icons next time because it's a whole bunch of images of basically an exact model or the same clone of the gold master. And you update the gold master and you throw those out. And that was part of... Yeah, so part of what I was getting into is as you're deploying from these, if you're using a DevOps framework like a Chef or a Puppet, you need to start integrating into your roles those basic, you know, that good hygiene again. So if you're deploying a bunch of web servers with Apache or EngineX or LightACPD, you need to be applying in that cookbook that defines how you're applying that, you put in those best practices, right? The limited user accounts, how it gets deployed in the Apache directory or so, where that lives and how, you know, basically you carry forward all of those best practices in the framework that is configuring those boxes for you. So when you have a giant herd of cows that all look exactly the same, it gives security an interesting new thing to look at, which is the fact that any one server that has a single change that looks different from all the other ones is something of concern. And Netflix, who's obviously really advanced in their cloud operation, their security lead, Jason Chan actually was saying this even two years ago, which is in a pool of 200 servers. I don't have time to look at each individual one and patch it. I look for the one server that's different from all the others. So this ties into the anomaly detection that the fellow that was on stage just before us was talking about. So as you're aggregating logs from this 200 servers or 2,000 servers or so, start looking for what looks different, right? You have a whole bunch of houses that all look the same, look for the one that's crazy. And we have a new opportunity for security in the cloud, whereas when you used to see this in an old data center, run down, pull the plug, then you've got your box, you're gonna go off and audit. These days, people are hopefully designing their systems well enough so that you can immediately take a cloud image offline, save that image for forensics later on, and then hopefully your orchestration system is gonna automatically backfill that capacity. So in some ways, I'm starting to see some traction on the argument that in many ways we can do security differently in the cloud and in some ways we can do it better than we have before, which is really, really exciting. So I'm gonna skip the last couple pieces of this and just jump to the end so we have plenty of time at the end. Few final notes on PCI and folks from the audience can throw out their input on this as well, but when it comes to actually doing your assessment, you're going to have a huge challenge finding an auditor that really understands cloud. I don't care if it's public, I don't care if it's private. The understanding of infrastructure as a service among auditors is nascent to say the least. There are some and in particular there are some that are actually auditing cloud service providers today and that's a good place to start. Beware, I have seen a couple of cases where the auditors will use your audit to train the more junior people on their team. So it is an area where the auditors are getting up to speed but like there's a very small number of people that really know cloud so you need to ask and make sure that whoever's the lead on your project has done this before at least once. Also it's really helpful internally, obviously if you have people that maybe have QSA experience in the past or have been through it, the best luck that we've seen and so I'll give a shout out to Phil Cox at RightScale that published a blog post about six months ago about how he did PCI compliance in the cloud. He really had to rethink the way that they were applying the direct controls and the compensating controls and so it takes a bit of creativity to think about how to do some of these things in the cloud and it takes frankly a relatively new toolbox but it's gonna be very different than any other PCI deployment that you've done in the past. And so this is mostly, we're talking mostly about private cloud but if you are doing anything and you have any intention of going out to a public cloud then you need to make sure that your public cloud provider is putting PCI in the contract, they're on the service providers list all those pieces so that's really critical. Okay. So where do you wrap up? You say it was best. Yeah, ultimately you're on the hook for PCI compliance. So no matter what the service provider says, no matter how many contracts you have signed or whatever, that may cover you after the fact but it's not gonna stop you from getting compromised to begin with. So again brush your teeth, lost your teeth, put your deodorant on, the good hygiene, the good practices and just carry those forward and adapt them to your new cloud world. In an open stack environment it's gonna be a mixture of both parts of the platform that's pretty obvious but this is another case where automation really is key and I would say that having been in the cloud security space for as long as it existed this is one of the areas that security still needs to catch up on automation and so that's a real challenge when people think about doing things with the old tools they've used before the first challenge they're gonna run up in against is how can they do self-service fully automated provisioning? But it is not as complicated as it needs to be, right? Or sorry. It's possible. Not as it needs to be but as most folks make it rather. It's definitely achievable. So start easy, if you're provisioning servers by hand or your users are provisioning servers by hand like I want a web server from the catalog make sure that everything that you build in that catalog behind so you start with a clean base image, right? That clean base image is patched to a good level. If you're using a dev ops tool make sure your recipes and cookbooks are kept fairly up to date, right? Yeah, exactly. And that actually ties into the next piece that when you're taking the right hygiene also with your hosts then when you start moving to a world of hybrid cloud and bursting outside your data center then you wanna make sure that you're taking care of everything in that definition, in the recipe, in the construction, in the original image before they go out to the public. Take your security with you. Yeah, absolutely. As much as possible. So if you're running host-based firewalls take that with you, that's a good practice, right? If you can't take your perimeter firewall with you at least not quite yet but to bring that forward, bring your data encryption with you, bring your shared key management with you, right? Yeah, bring that's exactly the right term. And as I said before, it's a bit of a hack but in a good way in that if you really know that you're gonna be hybrid in the long run figure out how to solve these problems in a public cloud environment and then it's easy really everywhere else that you go. So we've got some resources, they'll be in the slides, you can go. Rackspace has got an excellent security blog. We've done everything we can for the community to make this as easy as it can be right now but wanna open up for questions. Please. Actually, you mind going to the microphone please. Hi, first of all thanks, great presentation. Off PCI for a minute, is anybody, either of you or people in the room going through the same process with HIPAA? And do you have any thoughts? Yes, and I'm sure yes. And as I mentioned earlier, I mean HIPAA and PCI have some overlaps. PCI is nice and it's very prescriptive and it has a relatively broad set of things. HIPAA is a subset to a degree with some other pieces about the data itself. So and actually, I forget if it's high tech or the HSS group, but there was actual guidance about HIPAA put out also this year about doing it in an infrastructure to service environment. So they've caught up quite a bit. I'd reiterate that once you have those good practices, once you're starting to practice that good hygiene, a lot of that will carry forward regardless of your varied regulations, right? So having a firewall, that's a good practice, right? Having your data encrypted, that's good practice. Having strict access control lists, right? So once you have that, a lot of the tick boxes for PCI or SOC or HIPAA will start to get ticked for you. And SOC too, in SAA-16. And then as you start to integrate that into a chef or a puppet, right? The documentation, that becomes much easier. You have manifests or cookbooks or roles for how servers are built, right? That's actually a good point. So as various folks that we work with have been going through this, the automation tools that we're using to actually do the enforcement has a side benefit of providing so much of the documentation and history trail the auditors need. It's actually made life easier in some ways. Yes, please. So say you have a customer that's sitting on Rackspace that has an e-commerce solution and you've prepared them for PCI compliance because you're a PCI service provider. And they don't do their due diligence on their end and it leads to some sort of cart breach. Does that fall back on, say, Rackspace in any way? Have you encountered that and how do you deal with that? I have. I'll put you on the spot. So anytime a customer gets compromised, obviously you got to first figure out what the problem was. Nobody knows usually off the top of their head. But as a shared provider, usually we do try to be specific about who kind of owns what. And so customers get compromised all the time. If it's something that's due to fault of the customer in this case, they didn't do their data, didn't perform key management, didn't patch their stuff as long as we're not responsible. Left default passwords on a bare metal provisioning system and started hacking Brazil. They do, so they understand that there is a split in responsibility between both. They obviously will always ask us hard questions. We have to prove to them that this was not something that is bigger than just a single customer. The responsibility delineation slide that we had up there was derived from the recent PCI DSS Cloud Guidance paper. The mistake guidelines. Yeah, it does matter. Obviously the bigger the breach gets, the more time we spend looking at these types of things. But the visa guides understand where, how everybody's deploying stuff now. So it's not like you have to go and go through this big education process every time they show up. It's not as bad as it used to be. But at the end of the day, your service provider is involved in compliance. It's both of you together doing it. And so you always gotta make sure that you're very clear about who owns what piece of it. So if something does go wrong, you'll at least know who's responsible. Thanks. I can't be all the questions. So many stairs. Like you're waiting for me to dance or something. No, it's the end of the day. Cool, well we're, please. There we go. Yes, there we go. Hey. You saved the break. Ha ha ha ha ha ha. Depends on how loud it got. Like if we can disturb the other room like we're doing some kind of revival, then yeah, we'll dance. We'll try it at the end. Please. Do you have any tips or guidance on how do you manage passwords, keys, enforcing it, changing it? Ha ha ha ha. So this little thing called Cloud Keep earlier in the week. Yeah. So we are building a key management service for OpenSec. It's Cloud Keep. It's on GitHub. So github.com slash Cloud Keep. Please hop on there and help us build it. So that will help for a lot of those instances. When you're dealing with passwords, obviously using Chef and Puppet, they have kind of stories about how you do that. You have encrypted data bags in Chef and some of those types of things. So there are ways that you can kind of manage those particular bits. Obviously PKI can be very helpful in a lot of these cases. You can kind of eliminate passwords all together. And you can start to tie that into an LDAP based or other existing password management system that you may have. Yeah, I mean we do see customers routinely push their identity systems into Cloud. So the types of things that you do in dedicated, you can do in Cloud. There's something kind of preventing you from doing that. So it all kind of hard to get specific without knowing the use case, obviously, but there are a lot of tools out there, especially in the Puppet and Chef space, to make it easier to kind of distribute these types of secrets when you're doing the kind of provisioning. Thank you, Jarrett. So on the private cloud, really being an infrastructure provider, what are you seeing as far as trends or what do you see as the optimal solution for log and audit retention and things like that for mainly elastic and ephemeral instances, right? So making sure that you have a clear identity for that instance. Go ahead, I've got something to add. All right, start. I totally muted my own microphone, which comes back to following your good hygiene, your best practices, and so on. Being able to string all of those various things together Splunk and similar systems will help you search for, like, when was this deployed, what IP it got, how it got there. So, having had a lot of experience in this recently, I've seen two major things come up that people need to think about. First of all, most traditional SIM tools have this unfortunate habit of keying everything off an IP address. They really don't understand the idea of a dynamic service and those kinds of things. And so until the data is coming out that's more tied to a unique identifier for the machine and the SIM tools understand how to correlate off that, that's gonna be a challenge. And there's one or two folks out there that are down that path, but it's something to consider for your internal system. The other aspect that I see is at cloud scale, people are putting up a number of instances that are generating an amount of data which is literally almost impossible by the laws of physics to store in any one cluster. And so a lot of people are rethinking where are we actually filtering and collecting that data and bringing it in. So you're gonna have to really look at what are the important things you need to bring into the central systems and what are other distributed ways you're gonna look at that information. Right, so we're going towards a more restorative model for log keeping actually using our big data systems for the storage of that same data about the system. But as I start getting customers towards thinking about more elastic Hadoop clusters whether it's to bear metal ore within some sort of virtualized environment, even if you key it off the host's name, if you're reusing unless you're doing a unique host's name, are there any projects currently working on that kind of? Well, so you may not... For long term retention, so we have five year retention. Okay, so depending on how you're building those boxes and like if you're using a Chef or so, the signed key that you get back from the Chef servers you attach may be the thing you key off of and you just never reuse keys. You check it into a cloud keep or something of that nature. It's also worth noting that we are building logging as a service for OpenStack. So there's a presentation on it next. So you should all go to that and sit in C120, I think or something like that. Specifically aimed at solving some of the problems. Cool, the log has to stand up. Which is how do we maintain compliance in logs coming from infrastructure? And one of the things that we wanna do is surface a lot of the underlying cloud providers infrastructure and correlate that with customers logs. So your logging information from your VMs, it would be really nice if you also could see the logs from your hypervisors and from the provisioning services and various other things. So when IPs change and boxes get resized and migrated and all this other stuff, that's in your log files along with all of your stuff. So kind of increasing the visibility that you have to what the underlying infrastructure is doing so it's easier to correlate that stuff. And that'll help us get around the sim blindness and some of the things that we have that are kind of out there now. So it's projectminiscous.org. Feel free to come and join us. Cool. Great. I think one last question. Please, yeah, come up. I was wondering for RAT space, you guys, you offer a kind of their external private cloud for, which is a PCI compliance. Is that the right statement? Okay. I was wondering is from the business perspective is pretty much the business folks they care about the data and I understand hardening operating system, this kind of stuff. But do you guys, you implement a kind of the data leakage prevention for such as PCI compliance, cloud involvement for you guys, are you using any kind of the tool? If that, yes. A lot of that will depend on how your private cloud is built. Is it on R-prem? Is it on your prem? And where that delineation lives. Yeah, I think we can take any vendor stuff offline for afterwards, but in general even that type of solution, which is just one part of an overall PCI or compliance solution is gonna have to really be adapted to understand the dynamic nature of private or public environments. So there's a lot of challenges there as well, but we can follow up afterwards. It's okay. Great, thanks everyone very much. I think there's 10 minutes. Thank you all for coming to my party session. Cool.