 Good morning, everyone. Thank you very much for joining me today. My name is Joy Doraraj, and I'm a security product manager for Hewlett Packard Enterprise. I've been with Hewlett Packard for more than three years, with OpenStack for almost two years now. But I've been in security for many years, and I joined Hewlett Packard from Symantec. So I've been doing product management and development for many years in the field of security. How's everyone doing today? Great, great, great. So raise your hand if your organization is bound by any type of compliance. Like raise your hand if you're bound by PCI or FedRAMP or OK, great, HIPAA. Is it FedRAMP, HIPAA, or what type of compliance? HIPAA? Excellent, great. So what I'll be talking today, thank you again for joining me over the next 35 to 40 minutes. What I'd like to make sure that you all walk away from this discussion, from this session, is knowing what is compliance, why it matters. Perhaps some of you might be already knowing this, but I just want to make sure that we have a common ground before we start. And then what are the challenges with cloud security compliance? I mean, people have talked about compliance all the time. It's a big checkbox. So really, what is it that about cloud security, particularly something like OpenStack that actually makes it more challenging? And then we want to talk about the types of compliance. And when I talk to customers a lot, there's always some sort of confusion about product compliance versus service delivery base. So they ask questions like, hey, is Healing OpenStack PCI compliant? And then I stop them at their tracks and say, no, no, no. Healing OpenStack is a software distribution when it goes out to customers. So that means some of the controls that physical administrative was still falling under customer responsibility. So I kind of want to set the stage on, what are the different types of compliance? And then I want to walk you through an example of PCI DSS 3.1. And I want to give you an example of the different sections and how OpenStack or particularly HP Healing OpenStack can be configured to meet those requirements. And PCI DSS is a huge discussion in and of itself. So I probably won't do too much justification given the short amount of time, but I do want to highlight the different areas and say, hey, what are some of the key OpenStack features that help fulfill this requirement? So without further ado, it's no secret that security continues to be the single biggest barrier to adoption. And this is so because a lot of it is probably lack of knowledge and people don't have this visibility and control over where their data is being stored, who's handling the data and what kind of controls are in place, that visibility, lack of visibility, lack of monitoring. A lot of these puts suspicion and fear in the minds of C-level execs and other organizations that are trying to make the journey to cloud. And then when we take a look at compliance, but really in reality, compliance is more of a checkbox. Just being compliant doesn't mean that organizations can feel very secure. What is more important is they have to have a risk mitigation strategy in place to stay ahead of threats. The biggest fear for a lot of organizations is not really, you know, the compliance is a headache. Yes, you can somehow meet these, but the bigger fear is, hey, what do I do with perceived threats, right? Well, what happens if there's an attacker sitting in my network and I don't even know that he or she is there for days together. And then something happens. By that time it's too late to respond. So that type of being able to be staying ahead of threats, being more proactive is really very critical. So that's why I'm in the common example is we've got Home Depot, Target, I'm pretty sure they're all PCI compliant. But just because they were PCI compliant didn't mean that they could not get hacked. So it's very important to understand that compliance is an important milestone, but you have to go beyond that to have a proper risk mitigation strategy in place. So let me take a look at cloud security. So particularly let's say OpenStack. So what is it about cloud security that makes this compliance more and even security concerns more difficult? So first of all, you know, these are all, you know, software defined architecture. You've got REST APIs, you've got DevOps, you've got continuous integration, CICD. So then the important thing here is in an open source software, how, it's important to understand if your vendor is using secure coding practices, are they doing things like, are they doing source code analysis? Are they doing, you know, are they following threat architectures? So it's very important so when you, you know, make a decision to go with a vendor, whether it's HP or any of our other vendors in this space, it's important for you to understand that, you know, secure coding practices, you need to make sure that they're hardening your distro with every release. And then when we talk about rapid scales, rapid provisioning and scalability, so that's a huge, you know, cloud benefit. But then the reality is how do you monitor for drifts and how do you ensure continuous compliance? That continuous compliance is a huge challenge for a lot of organizations. And the reason for that is, you know, when you're in a cloud environment, you've got P, you've got your users bursting clouds left, right and center. You've got your guest operating systems sitting there. You've not rebooted your servers in many months. How do you ensure that they're patched properly? That is important. And how do you ensure that your guest operating systems are up to date from a compliance standpoint? How do you monitor for any kind of drifts? I mean, how do you make sure that, you know, when from a coding, even from a coding practice perspective that developers are not doing things like, you know, security bad practices, like storing passwords in clear text or storing passwords in configuration files. So these are all a lot of security best practices that needs to be followed and needs to be, you know, taken into consideration when you do, when you think about compliance. So we talked about virtualization. Virtualization is a huge benefit. So we talked about, you know, how do you monitor your east-west traffic? So the recent survey has shown that, you know, majority of the threats are actually coming from insiders, more customers move, I mean, organizations are more worried about insider threats than anything else. So in that case then, how do you secure your data center traffic? And that's an important aspect from a security standpoint. How do you isolate? How do you isolate your environments? How do you patch them? How do you harden them? And then now the other, the benefit of cloud is that it brings about multi-tenancy. So when you think about multi-tenancy, now you've all got, you know, how do you achieve proper rollback, rollback, roll-based access control? How do you audit all user activity, particularly admin activity? And so this is a huge pain point for a lot of customers that we talked to. They're very worried about, hey, I don't know, you know, privileged access. You talk about stack user, privileged access. Hey, I wanna know who are these users that are actually gonna be, you know, installing my bootstrapping, my environment, and installing it. So it's very important to understand that you've got to have auditing all the way through. I mean, not just the open-stack services, but also your physical layer, your hypervisor, your host operating system. And of course, application workloads, you know, typically customers have that type of auditing already there. I mean, it's kind of out of scope from a, you know, infrastructure as a service perspective, but from a compliance standpoint, very important to understand, you know, what the different layers are. Then we talk about compliance due diligence. Now, this is an important aspect. So this is where we talk about, you know, I brought up this example of, you know, customers and some of, you know, some of the people who are still trying to get their head around open-stack. The first question they ask is, oh, AWS is, you know, PCI, FedRAMP, and all of this compliant. What about open-stack? Then the response to that is, you know, open-stack is a software distribution. Ultimately, you know, when a customer deploys it in their environment or they engage a service provider to do it on their behalf, they need to understand what the different responsibilities are. And then we'll talk about it in just a second. So then the concept of shared responsibility comes into picture. There are things that, you know, the vendor is responsible for. They need to make sure you've got the right feature set to comply with standards. And then there are, you know, I would say service provider responsibilities. So they are managing their data center. How do they do the physical, you know, aspect, the physical controls, like biometrics and security guards and cameras, closed circuit cameras, et cetera. And then you've got customer, like for example, you, like you as a customer, ultimately responsible for getting the certification. So it's very important to understand these concepts. And then, of course, this is just saying, you know, what is compliance? Of course, compliance is, you know, set of regulations, standards and laws. And then the assessment and audit is very important. And many of you probably are, you know, your security team or you yourself are engaging with external auditors to go through your compliance. And the assessment needs to be done first. So you have to make sure, you know, what are the different systems and, you know, how many of these are in scope, how many are out of scope. And that assessment is important before you perform an audit. Probably, I'm sure, you know, many of you have already gone through this process before. And then the third aspect is certification. So once you go through the audit, then the auditor comes back and says, yes, check box, you know, all these rules have been satisfied. And great, here is a certificate that says that your PCI compliant or HIPAA compliant or whatever. But then the important aspect to this is, a lot of these is not a one-time activity. It's an ongoing activity because you've got to be, you know, doing annual audits or perhaps, you know, you do quarterly scans, depending on, you know, what level of compliance you, and risk mitigation you want to take. Why compliance is important? Of course, these are barrier to entry. You've got fines that are levied. You've got penalties. In some cases, you've got even jail time. Classic example would be, you know, there were some companies which, which inadvertently sent out personally identifiable data that ended up paying a huge fine. And then there are different, you know, this is probably something that most of you are already familiar with, but I wanted to put a, you know, common ground here saying, there are various different, depending on what type of industry you fall under, there are different types of certifications and the evaluators are all different. And then the regulation standards are all could be very different. Could be things like, you know, financial and legal services. You could go into SOC, SOC compliance or PCI, healthcare, life sciences, HIPAA. If you're a cloud service provider, you would want to, you know, CSA start as a commonly known standard that cloud service providers go through. If your technology, media, telecom, ISOs and other great example. So these are all just examples of how this thing works. I'm so sorry, I just don't seem to be getting this right. And then we already covered this in terms of service delivery based versus product. And as I said, you know, when you take about public cloud providers, they're all service delivery based. And then so they always, you know, will go through the full audit compliance. Whereas product, if you take a product or a distribution, they, you know, we can do certifications like common criteria, FIPS 140, et cetera. And the reason for that is every compliance standard has three types of controls. You've got administrative controls which are typically very, you know, awareness, training, documentation, disaster recovery plans, and your risk mitigation strategy, your data classification. How do you classify the data, right? I mean, not everything needs to be super secret. I mean, the different levels of classification based on that, you know, that dictates the amount of spending you would do to become certified. And then there are technical features. So this is the important aspect of which I will be covering, which is really saying what are the product features that help customers become compliant? And then there are physical controls that we talked, I alluded earlier, which is, you know, all the things that you would do in a physical environment like closed circuits, TVs, security guards, biometrics. Now, and maybe some of you have already gone through this process. So it's not, you know, surprising. But for those of us who are new to this, you know, we would be surprised that, hey, even you have to literally like walk your auditors through how secure an environment is, literally go through all these different, you know, physical controls, your administrative controls. And of course, technical controls is something that, you know, people like me, I'm a product manager, I understand it very easily because to me it's like, oh, great, I've got this product feature, you know, you've got this reporting that you can show, you can take a screenshot, you can do all kinds of, you know, things to prove, demonstrate to your auditors that you're compliant. But all these other aspects are also important from a compliance standpoint. In summary, when we talk about, you know, cloud compliance concerns, we think about, you know, the environment is constantly changing. How do you automate compliance? This automation is also an important, is a key concern for many customers. And the reason for this is gets to be a very huge pain point because literally I've heard from customers, they're saying that, you know, I have to literally take log files and take, you know, sift through the log files and show it to my auditors. It's very painful. If I had, you know, ready-made reporting that would help me, you know, with a good formatting, I could show it to my auditors. And then in some cases, they say, I literally have to call my auditor right next to me, show them on the screen that, hey, this is how we are, you know, satisfying these controls. So when we look at it, we say, hey, how do you help customers automate the process? And I think that's an important aspect of it. Compliance, checking for compliance drifts is important in a cloud environment because you've got VM sprawls all the time. You've got, you know, your users coming in and out. You're, you know, cloud bursting. How do you keep them patched? How do you keep them isolated? Very important. And also, how do you measure integrity against a known good state? So this is, again, looking at, you know, hardware-based root of trust. And we're having a panel discussion later this afternoon with Intel and Visa. So I'm going to be part of that. So we're going to show you how, you know, HP, the hardware has these modules, TXT, TPM modules, which when you integrate with, say, Intel, you know, cloud integration technology or open attestation server, how do you get that root of trust and how do you use that root of trust to enforce security policies? So that is an interesting and an important one, especially in data sovereignty compliance standards because customers are asking, like, hey, how do I make sure that only users who have, you know, only users who are located out of France, for example, can run workloads on my service? And I have a global, you know, large enterprise. I've got globally distributed users. The other pain point is, how do I control the workload access? I only want users to be running workloads on servers which are trusted. So these type of policies can or also play a big role from a compliance standpoint. So in summary, you also have to start off with an enterprise cloud strategy. You need to understand, you know, what cloud services you will be using, who is responsible for what, that separation of duties is critical. You have to be able to map out and say, hey, these are my users that are going to be using OpenStack or these are my dedicated users that are going to be installing OpenStack. So that way you have good visibility and control over who is, you know, audit or who is doing what. And then the, and the other part is also, how much risk are you willing to accept? So it also depends on your risk, you know, mitigation strategy and, you know, based on your workloads. If they're DevTest workloads, you know, you don't care, not, you don't need to go into heavy duty security. But then you think about, you know, production workloads, yes. There's some, definitely, you know, good amount of security. Compliant workloads, great amount of security. So it's kind of like your Goldilocks story, you know, what is the right fit? Like this is too big, too small, but this is the right thing that feels good. So what is right? No, there's no one size fits all. What is right for one organization is obviously, you know, is different from different organizations. So I want to take the next, you know, 15 minutes talking about PCI DSS. Most of you are already familiar with PCI DSS. I won't go into too much detail about it. And so we recently did, you know, PCI DSS assessment. We did external assessment using an auditor. And we are going to be, you know, HP Helion OpenStack 3.0 onwards as PCI ready. And we'll have literature coming up shortly. And we'll show you different controls, how we need different controls. And what is important to understand here is, you know, the classification of different sections. So in PCI DSS is basically, in summary, applies to cardholder data. So anybody that's storing, transmitting, or handling credit card data, there's different levels of PCI compliance. There's a huge website and standards body devoted to this completely. So more information can be found there. Then there is the different levels, level one, level two, level three, all based on the number of transactions you, you know, you handle and whether you're a merchant like Visa or American Express or someone else, or whether you're a provider, say for example, you could be on a retail provider that's handling credit card, or you could even be any enterprise that's using credit card for handling your transactions. So it's important to understand the difference between, you know, certification and compliance. So even in the world of PCI, there's a self-certification and then there is the proper, you know, going through the proper audit and engaging an auditor and getting certified. Now the latter obviously takes more time and obviously, you know, more expensive. But the self-certification is more of a, say, oh yeah, great, you know, I'm PCI compliant. But in certain cases, you know, takes the certification is obviously more, carries more value and carries is more, you know, a lot of weight. And then what is important, we talked about this earlier, is understanding the scope. And the scope is critical because you need to understand how many servers are, you know, actually storing or they're handling or transmitting. In some scenarios, you may not be storing any credit card, you just be handling or transmitting. So you need to understand the difference. You need to get an inventory of all the different systems that touch PCI, that or rather that touch the credit cardholder data. And then there are, you know, things like tokenization which can be used to reduce scope. You may have probably been following voltage which was bought out by HP Enterprise almost a year ago. So now they're part of our data security business unit. So they have great solution. They have format preserving encryption and tokenization, stateless tokenization technologies. They have very proven products. They've been in the market for many years. They're the market leaders. So if you're interested in those, I would absolutely encourage you. And you know, I know this is a bit of a marketing pitch but this is our session. So I have full, I'm fully okay to talk about it. So you should absolutely check it out if you're interested in that type of solution. So what I'm gonna do is I'm gonna give highlights of different sections and then say, you know, what is, how are we gonna be meeting these type of requirements? So sections one and two, they talk about building and maintaining a secure network and systems. So when we talk, when we look at this particular section there are controls which are administrative controls and then there are controls which are physical controls. So those are completely, you know, outside the scope of any product-based control. So if you look at the features of OpenStack which will help you address this. So we've got network segmentation. You've got, you know, neutron-based capabilities. You've got IP groups, security groups, IP tables, all your, you know, quotas for managing your resources. So all the networking features, security features, absolutely help meet these particular section of requirements. And then this talks mainly about making sure you've got firewalls in place, making sure you've got, you know, the network security aspect in place. So that's an, that's one of the key features that'll help meet this requirement. So when we take a look at sections three and four. So there are 12 sections in total and then there is an appendix that talks about shared, that talks about service provider requirements. So sections three and four talks about protecting the cardholder data. So the moment we think about protection, we're always thinking, hey, you know, data address protection and transmission of data and, you know, encrypting data and transit. So very straightforward. Basically there are 26 total controls of which seven are administrative, procedural, 19 or fall under customer responsibility. So the key features that of OpenStack or even, you know, let's say even HP, Helene OpenStack that help meet this requirement is we've got encryption of stored cardholder data. So typically in majority of the cases, you know, customers already have their own PCI compliant workloads more than, you know, most often they're not, they're probably not using, you know, OpenStack, Cinder or whatever it is for storing that data. They're probably having, you know, their own, say, storage systems. But if they choose to, you know, use OpenStack, we've got data address encryption, Cinder block storage, you've got the Barbicon, you've got the key management using Barbicon. You've also got the ability for Barbicon to talk to an external key management device. And I would say that Barbicon is probably, you know, still evolving. It's still, you know, they're still trying to get some key management capabilities in place. But in reality, there are other choices that are more, you know, more interesting. More interesting choices like using an external key management device. An example would be HPE ESKM, which is our enterprise security key manager. It used to be called a TALA key manager, but now it's called ESKM. Now that particular, it's a hardware based of lines, very expensive, but it is completely, you know, tamper evident. You've got HA built in. You've got high availability built in. You've got FIPS compliance. It's all been completely, you know, certified for FIPS. It's PCI compliant. So those key management devices really help, you know, meet this particular requirement when you talk about encryption of data. And then there is also, I talked, I talked about data centric encryption and tokenization from HPE data security, the voltage solution. And then the encryption of data on transit. So this is pretty straightforward. I mean, you know, most vendors, including us, we've got TLS to access to external data API endpoints. We've got TLS. And pretty soon, you know, we also are working, we have beyond encrypting, some amount of traffic within the internal, you know, but between in the internal cloud traffic between API to API, between, say, RabbitMQ to, you know, other APIs and so on. So, but it's important that, you know, these two are the key requirements when you take a look at sections three and four. So five and six talk about maintaining a vulnerability management program. So if you take, this has about 24 of them or administrative procedural. And so this is, talks about malware maintaining proper patching. So this brings us back to, you know, patch management. And patch management is very, it's very painful, but it's an unnecessary thing to meet this particular section. And again, when you look at OpenStack and when you talk to different vendors or even when you talk to us, the way that we approach this is we deliver a single set of, you know, patches and then we have this critical security patches. We've got turnaround time for delivering critical security patches. And those patches not only include OpenStack but the entire distribution. So our host operating system, which is the HPE Linux. And so what we do is we make sure that, you know, normal releases contain all the bug fixes and everything which is typical of any vendor. I mean, you talk to anybody, they'll say the same thing and we are no different either. So, but what is important is for you to understand, you know, what is the critical security fixes and need to understand what the process is, how often do your vendors, you know, give you those patches? What is the turnaround time? Where do you go get the advisories? All of that is critical. And then the other customer best practices, you have to deploy antivirus, anti-malware. And there are a few things that are available for, you know, I would say in a virtualized environment but still this is, I think, I haven't really found anything that's more open source but there are a lot of choices available for customers. So, 7, 8, and 9 talk about implementing strong access control procedures. So this is again restricting access control access to cardholder data, identifying and authenticating. So this is pretty straightforward. You've got the Keystone authentication service which has, you know, which meets all these different features. You've got all the built-in capabilities, directory-based authentication, role-based access control. So all of that covers the open stack layer. Now when you really look at it, you know, additionally what we do is we do security during bootstrapping. So that's important. So when you talk to, when you buy, hopefully, you know, you all go with HP Healing OpenStack but when you look at other vendors, then you have to be able to evaluate what their security is during bootstrapping. This is before all the open stack services are even installed. How do you access different keys? What are the config file settings? What are the service passwords? How are they doing the encryption of data in rest and transit? How are they, are they following security best practices like segmented networks, you know, separate networks for your storage traffic versus say your, you know, your management plane, your data plane. So you've got to make sure that they're following all these, you know, security best practices. And then the SSH keys, so this is very important. So when you bootstrap, open stack, any distribution, you've got the stack stack user. How do you, you know, access all the controller and compute nodes? You've got SSH keys. How is your vendor protecting those SSH keys? Are they using a passphrase to encrypt it? Where is the passphrase being stored? You know, how can, you've got to think about in our tax scenarios, right? Can an attacker, if they gain access to it, can they gain access to that encryption keys and what's the damage being done? So very important to pay attention to that bootstrapping security beyond just the open stack security. So 10 and 11 talk about regularly monitoring and testing networks. So you've got, you know, the logging is important. So how are we meeting it? We've got audit logs, which are CADF compliant. CADF stands for Cloud Audit Data Federation. And it's an interesting one from an, from a compliance standpoint, because it meets a lot of the seven Ws that you need from an auditing perspective. You've got to be able to back up your audit logs frequently, regularly, you know, in a proper cadence. You've got centralized logging that will help achieve this. And again, additional best practices, you've got to do things like file integrity monitoring, penetration testing, vulnerability scanning, wireless IDS IPS. So these are all things that are not out, these are all outside of open stack, but these are all things that customers have to think about when they want to meet DSS, PCI DSS requirements. So 12 talks about maintaining a policy. This is again, you know, there's only one open stack control, which is automatically disconnecting idle sessions. And this is met by Keystone TTL tokens. And the rest of it is all procedural. Appendix A talks about shared hosting provider's requirement. So this is in a multi-tenant model. You've got to make sure that it's fully segmented from each other if necessary. And how do you achieve tenant isolation, right? So you want to keep them in a separate project-based and the audit logs have to be segmented by tenants so that in a service provider model, you can, you know, each customer can access their own data. And then you also have things like, you know, neutron-based, role-based access for networks so you can, you know, basically prevent each other from seeing each other, each other's networks. So in summary, we talked about a lot of things. You have to have the right mitigation strategy, visibility control. You've got to harden, you've got to isolate. So we do a lot of things from a hardening perspective. So we do app armor for compute nodes, controller nodes, and also, you know, we are introducing Red Hat KBM for a compute node. So we will be introducing AC Linux as well. So then, you know, with every release of Healing OpenStack, we follow the security best practices. We do threat reviews. We do penetration testing, vulnerability scanning, all critical threats, or immediate prior to, you know, giving a, releasing it to customers. Then, so this isolation hardening, very key. You've got to have proper auditing and then proper patching. So I kind of want to, you know, wrap up with this. Again, keep in mind, the key takeaway is compliance alone is not enough. You have to have a risk mitigation strategy which is equally important. I want to throw it open to questions and answers. Any questions from the audience? Sure. Sure. So first of all, you need to understand, you know, who your public cloud provider is. And typically, you know, common ones, or AWS, Azure, and so on. You need to find out if they are already PCI compliant because it's important. In order for you to achieve the PCI compliance, your service provider must have, must already be, you know, PCI compliant and they will give you a package. They will say, hey, here is a report from an external auditor that goes through all these different controls. And AWS actually does that, but you have to be a customer to get that report. And Azure has a report that's available publicly on their website. But once you get that report, you have to go through those different controls and then it'll tell you, you know, these are all customer responsibility. So then when they go through each of these, and then when you look at the ones that you are responsible for, then what you need to do is you need to take that report, you need to work with your own auditor. You need to work with an external audit firm. There is so many available today. You know, if you go to the PCI DSS website, you will see a list of all the approved auditors. You can engage with any of them and then say, hey, this is the report I got from my provider. And how do I go about doing this? And then they will say, okay, you know, you got to provide documentation that you're supporting all these data. So that's the process you would take. You talked about encrypting config files and are you encrypting the whole file or just the passwords in the number? The passwords in the file. And where are you storing the encryption key that's used to encrypt this? So encryption keys can be stored in different places. So you can configure them to say, you know, store depending on where they are. It could be an ansible vault or you could store them in ansible vault and you know, down the road, you can look at ways of integrating with outside key, external key providers and configuring it to store it externally. But today, the Cinder encryption keys and then the Nova ephemeral encryption keys, they're all, you can take them from Barbican and you can configure Barbican to say, hey, store these keys in a NES game device or a KMAP compliant device. Is the purpose of that to keep someone with root access to the box from being able to? Yeah, the biggest, you know, the biggest reason why you want to do that is you want to keep your encryption keys separate from the data. You don't want to co-mingle them. And the reason for that is, let's say, in the event of an attack in your OpenStack cloud, you know, the attacker will not be able to gain access to your keys because they're stored in a totally, you know, different appliance. That's not really what I mean. What's the point of encrypting the passwords in the first place? Because the config files themselves are only accessible. So let's say it's a Nova config file. It's only going to be accessible to Nova and to root. Unless you've found a way to keep root from being able to get access to that key somehow, but through whatever you're doing, Nova's going to have to be able to access the key in order to decrypt it, in order to use it in the service anyway. And so have you really added any true security or is it just basically security theater makes people feel better that it's encrypted, but it was actually no safer than it was to begin with? I'm not sure I completely understand your question, but let me make sure I replay this. So what you're saying is, you know, when you look at, and I think you brought up a good point, which is you've got all these config files from OpenStack like NovaConf, right? Which is storing the Nova passwords. And then the only people that can have access to it is your root or your, you know, Nova admin, right? And typically even inside the config file, when you take the open, a DevStack version, the DevStack, you know, doesn't encrypt it. I mean, vendors like us, we go in and we harden that and we say, okay, you know, this is not a good security practice. So then what we do is we take those, we make sure that those passwords when they stored inside the config files are actually encrypted. And your question is what is the purpose behind that, right? And then the reality is, you know, it's just being security best practices throughout, you know, and also understanding what is at risk involved, right? So if someone gets access to it, it could probably be only a root that gets access to it and what is it that they're gonna steal away, right? So it comes back to, you know, security best practices and risk mitigation. I don't know if I answered your question, but we'll take it offline. Are you finding a way to prevent root from, someone with root access from being able to? That is, that's gonna be really hard, right? I mean, if somebody has root access, they have access to everything. You can't, you can't prevent that, yeah. Yeah, you can't prevent that. Sure. I have a different kind of question. I'm due to open stack it. So in your presentation, I think there was one slide that mentioned that, you know, given that you know what to do to be compliant. I think there is actually, it will be great if there is a framework or tools that, so users can quickly verify that, you know, things are actually configured correctly for open stack. It would be great to have a tool or framework to easily tell that you have actually configured the system correctly. Exactly. So that, you know, you can show auditors, things are actually, you know, compliant, and you can frequently do that. So that, you know, it's always compliant or most time compliant. So I wonder whether, you know, I mean, this question is maybe for the community as well. Is there something in open stack already that, you know, can do that? Or is that something that's desirable and it's not there? And it should be kind of created as maybe a project or something. So that, you know, I know a lot of proprietary products are out there, you know, to check for, you know, compliance of your entire stack, you know, are they, you know, different layers are all compliant for PCI, for example. But for open stack, you have different nodes, you have nodes. Correct, correct. Now actually you brought up an excellent point, which is really saying, you know, how do you have a baseline of configuration and how do you kind of monitor for drifts? And then so there are a couple of ways to address this. So one is, you know, you have file monitoring, file integrity monitoring tools available. So they do that sort of thing where they have a baseline config and then they check for drifts. For open stack in particular, there are, you know, few startups that are actually doing this type of thing. I don't think there's any open source community initiative as far as I know, but there are a few startups that I mentioned. So one is called Cloud Rakshak. It's a cloud CLOED, Rakshak is spelled R-A-X-A-K. And then so those guys are actually having what are you known as the continuous compliance monitoring for open stack and they can do that for AWS and Azure. So, and they can also do it for a VMware environment. So you can say that they do it for all types of clouds. So we will have actually a demo from them later today. So what they can do is, so basically the way that they do is they have this baseline of compliance template or standard that they input into their system. And then it basically says, hey, you know, this is the template, these are the 10 rules that you need to follow. And then it can actually look at end-to-end compliance. It can go all the way from hardware root of trust all the way up to your open stack services. So, but it's not, but obviously it's not open sourced. It's proprietary, but this is definitely one area that I think the community needs to start thinking about and addressing it. I agree. I think it's a great question. Thank you. So when and where is the demo? The, that panel session is actually going to be here. It's at 5.40. I think it's in, I forget, it's probably room 14 or 15. So somewhere here, yeah, yeah. Thank you very much. Yeah. We have time for one last question. Yeah. So certification and compliance are starting to manifest an open stack in many different ways. If you look at, you know, from the exams that are being put out for administrators to configuration, open stack configurations, that should be considered secure to, you know, talks like this and others who are trying to put a holistic picture together. When I did, I did an informal survey of open stack of various vendors out there asking them that, you know, do you have an open stack solution that you can give me and is HIPAA compliant from, and it's turnkey. So the answer I was getting was that it's, you know, if I use this widget or that widget, you know, then you could do, but not the whole solution. So in your opinion, I guess, long story short, in your opinion, where is open stack heading? Where is open stack currently in terms of security and compliance from PCI and ESS? I've got beginners, intermediate advanced level. And two, what should the community do as a whole to address this? Is there need to publish some kind of open stack, compliance guides as a similar to open stack security guides? Some products or configurations have to be considered that way. So where should the community- Where do you say? That is a great question. So from the, from a PCI perspective, I certainly see open stack more in the intermediate. It's definitely not a beginner. We have crossed that stage. It's the intermediate and then we want to get to the advanced stage. I think there are definitely opportunities where the community can contribute. There's certain areas that I think would be things like, you know, file integrity monitoring. I think the gentleman brought a great example. I think we want to do documentation. We want to be able to publish this to our community users and say, hey, how can you actually, you know, configure your open stack cloud in a compliant manner? Documentation, I would say, exploring areas such as file integrity monitoring and also tightening each layer of your, you know, all the layers of the stack. So you, we have to look at, you know, even auditing. We have to take a look at auditing from, you know, host operating system to guest OS, open stack services. We really have to look at, you know, centralized logging. How can we implement that? I would say three different areas. So one is obviously, you know, a documentation, file integrity monitoring, monitoring drifts, continuous monitoring, and then the other one would be auditing and logging. Would be those areas. Thank you very much. But, you know, we are a part of HPE and I work very closely with my security team who are, Rob Clark used to lead our security. He was a PPL, but he's moved on to another vendor. So, thank you. Thank you, everyone.