 All right. Can everyone hear me in the back? I can't really see you because of these lights. So throw something at me if you can't hear. All right. So my name is Major Hayden. I work for Rackspace. I work on our OpenStack private cloud product. And a lot of the focus for me lately has been around security and around automating security. And so that's what a lot of the presentation is going to be about today. So a little bit about me. I'm a principal architect at Rackspace. I've been there since 2006. I've been working with OpenStack in one way or another since 2012. And I've been a member of the Fedora community since about 2011. And so our agenda today is three parts. So first, we're going to talk about the security tug-of-war that we probably all face within our companies. And then we'll talk about this concept of meeting halfway, finding common middle ground. And then at the end, I have a little bit of a call to action for people to get involved with the project. And so how many people here work on information security inside their companies? OK, good. Awesome. How many of y'all have used Ansible in some way or another at some point? Oh, fantastic. All right, cool. I'll go over a little piece of that. So if you're not familiar with any of those parts, I'll go through it just a little bit. So I think we can all agree on one thing, that it's very hard to do slides and make them go. There we go. Information security is very, very difficult. It's a cultural problem. It's a technology problem. It's a time problem. When you're going to build a product, you don't necessarily sit down and say, hey, let's make this thing secure. That's not the first conversation that people have. They say, hey, let's make a product that solves a problem for a customer. Or let's make a product that brings more value to our suite of products that brings more customers on board or get customers thinking a different way. And the tough thing about security is that we want to create just enough security to create those valuable outcomes for our customers. So we want them to feel comfortable putting their data with us, trusting us that the systems are going to be up all the time. So we want to create that trust. But we only want to create just enough because if you create too much, you end up having this drag and this friction on your business. So I don't know, at different companies, I hear this all the time, you come in on Monday morning and they say, hey, look, this application you used to just walk straight into, now it has two factor. Or now this application is behind VPN. Or maybe you can't use this application. Or the way this thing is done has been changed. And it adds on a couple of minutes to your workflow. It can be a little frustrating. And this is the drag that we fight with. So this is this tug of war between creating value and increasing drag. And there's a third component that all of us in the room that have worked in the information security field at some point is that if the auditors aren't happy, nobody is happy. So when the auditors show up and they say, hey, let me see your controls. And you're like, hey, take a look at my controls. And then they say, hey, show me that you're doing the controls. And you kind of have that moment where you start to get the cold sweat. And you show them the stuff. And you're like, OK, here's what we do. Here's what we do. And they get to that last step and they say, wait a minute. You didn't do that one part right. You're not doing it like you said you were. So when the auditors aren't happy, nobody's happy. Especially not the CSO. They will come and find you. And it's going to be very bad times. And so the big question is, how do we make these valuable security changes without disruption and also keep the auditors happy? And so our answer to that is make security automatic. And I know that makes it sound easy. Everyone's like, oh, let's make security automatic. Let's talk about it. We'll build it into every product. We'll do this. But inevitably, at every company, you have that conversation where, hey, this product is going to launch on the first, right? Yeah, great. Have we made sure it's PCI compliant? Oh, wait a minute. Was that in the scope? Oh, well, let's push it out three weeks or whatever. Well, we can't push three weeks. Marketing's ready to go. And so then you have to figure out what to do. So a lot of what this talk is about is about how to make security automatic and how we do that for our private cloud. And so I created this quote. So when the going gets tough, the tough adopts standards. So, and I'll go through this in a minute. If you're not familiar with where I'm going with standards in the information security world, I'll get there. What we're talking about here is that when things are very tough, when things get very complex, you fall back on to standards that have been set up, that make sense, that create this real value and create minimal disruption. And if they do create disruption, you have this opportunity to say, hey, look, I want to take this entire standard and apply it to my environment. But maybe I'm going to turn off these one or two things. Or maybe if I do this one part of the standard, it's going to take my customers offline. So I can't do that part. And so to explain this a little bit better, I was once Rackspace's chief security architect. And so I led a lot of the security architecture within our company. And I had to learn less in the hard way. Is that, and here's a tip I'll give to anybody in the audience so you don't have to learn it the hard way. People should feel like security is something they're a part of, not something that's being done to them. So I think we've all felt, at some point in our lifetime, when security was done to us. And it's never fun. You feel like you were never involved in the conversation. You felt like you had no say in what that security was. And sometimes nobody explained the why of why it's there. And sometimes you never do find out what the value of that security really is. And so to give you an example, which sounds better? This is option one. As developers, you don't know how to secure systems properly. We will tell you what to do. And you must have it done in three months. And if you don't, we can't take credit cards. How does that sound as a developer? It's pretty demotivating. This is how I talk to my five-year-old to get him into bed at night. I say, hey, look, you've got to get in bed. Because we're not going to be able to read books. But if you, as a corporate security team, go and talk to people in your business like this, it's not collaborative. They feel like security is something that's being done to them. And so as an alternative, think of something like this. Since you use Ansible, we wrote some automation that fits into your existing deployment method and won't disrupt your production environments. Can we work with you to test it this month? The impact of that is much different. Because then when you go into that meeting with the developers, they're like, whoa, when did the info set guys learn how to do configuration management? And they're sitting there, well, how do they know we were doing Ansible? And so then you kind of come to this table and find this middle ground. And then you also see the second part there that says, won't disrupt your production environments. So that means the information security team has taken the time to understand how to do a configuration management system that works well for what you have. And they also understood what your production environment looks like. So a production environment that's running a LAMP stack looks very different from a production environment that's running an OpenStack Cloud. There's tons of security changes that you would make on one that you wouldn't make on the other. And finally, the very last part, you go down and say, can we work with you to test it? We would love to go and apply this. Maybe we can do it in your staging environment. If it breaks, hey, we're going to be sitting in the room and you can make fun of us. We can go and file bugs and get it done. But it's much more collaborative. It makes all the developers when the organization feel like they're part of the process. And so with that in mind, when we thought about doing automated security for OpenStack, we said it has to be easy to implement. It has to be simple to maintain. And of course, it has to be nondisruptive to an operating cloud. So if you have 1,000 virtual machines running in a cloud and they all go offline at the same time when the security people show up, that's going to leave a bad taste in everyone's mouth for a good while. It has to be effective against attacks. Otherwise, it creates no value. And it has to be open and transparent. And so I think this is a great opportunity for information security teams to go to people and say, hey, look, we've put the code for this in a source code repository. You can go there. You can propose a change. And so our great friends at the Payment Card Industry have also set up something. Requirement 2.2 requires that you take hardening standards and apply them to your systems. And so they have a laundry list of acceptable industry accepted system hardening standards. And this is really the base level of hardening for any Linux hosts or Windows hosts. And so as we went down this path, we found that selecting the right standard is really, really hard. So some standards are as long as novels. I don't know if anybody's read ISO 27002 cover to cover. Has anybody here done that? All right, that probably didn't go over so well. I mean, that's a book. It is huge. I think War and Peace actually is a little shorter by a few pages. So and also ISO 27002, 27001, they cover things like human resources. Your developers really don't care about HR in most situations. So they're uninterested. If you go and look at a lot of the NIST guidelines, they're just not specific. There's a lot of really great content in there, but again, it's a book. And the actual specific part of it is very small. It's very hard to test. And also very few directly apply to Ubuntu. So we deploy our private cloud on Ubuntu. There is almost no hardening standard content out there for Ubuntu. There is a small amount, but some of it is very brief. It's very incomplete. Trying to find anything that works with tools like OpenScap or anything like that, it's very difficult to find. And then some of them have very restrictive licenses. We were working with a group to try and figure out a way to use their standards with our private cloud and get it into the OpenStack Foundation and the licensing just wouldn't work out. And so after all this deliberation and going back and forth, we decided to settle on the Security Technical Implementation Guide from DISA, which is part of the United States Department of Defense. And so this is the same security changes that the United States Department of Defense makes on their own systems. And the great thing about it is that it's cracked up into multiple levels. There's category one, two, and three, with one being, okay, if you're on a very, very secret, secure system, you must do these things. And then at the bottom level, number three is just good system hygiene all around. So it's things that every system should really have applied. Usually the stuff at the top will be a little bit more impacting than the stuff at the bottom. And I'll go through a couple of examples of that here in a second. And so the other nice thing about the Stig is that it covers the most critical security domains. So all the things you see here on the right are covered within the Stig. So as far as handling your package management and checking, you know, for check sums when the packages come through, auditing SIS calls, which can be amazingly helpful for when an intruder's trying to wander around the system and they're trying to access files that they can't, you'll receive just tons and tons of alerts coming through. And if it's on files that you normally don't see that on, that's a great time to alert. But it also goes through and deals with authentication, file permissions, file integrity management, all this kind of thing. So some of this involves installing extra packages. Some of it is just configuration changes or just changes in individual files. And so what we did with the community was take the DeSys Stig for Rails 6 and ansibleize it. And so apply the entire, all of the controls that could be applied with an automated platform. Took all that together and then we said, hey, wait a minute, which one of these is gonna cause a problem with a running OpenStack Cloud? For example, there was one in there that said, disable IPv6. Well, in my personal OpenStack Cloud, I have IPv6, that would be crazy. And there's some others that if you actually enabled them, it would take VMs offline. So that's a really bad time there. And then finally, what we did was we said, hey look, so now we've automated it, we figured out what's not gonna work well on OpenStack Cloud, we've turned it off. Now what we have to do is make this work really well for Ubuntu. So as some of you may know, Rell and Ubuntu don't really match up so well in a lot of places. So it took a little bit of careful tuning and sometimes some substitutions to get that in there. And so if some of you are not familiar with Ansible, it's a software platform for configuration management, deployment, and many other things. If you've used Puppet or Chef or SaltStack, it's generally the same type of thing. The reason we love it is because there's no agent required, there's nothing actually that you have to install on a server to use Ansible with it. So you can deploy from your laptop, you can deploy from a bashing server, you can deploy from Jenkins, you can deploy from wherever you like. But you don't have to go on the other end and install Ruby and install 56 other things. You just have to make sure the other end has Python, which if you're running OpenStack, I certainly hope you have that installed. Otherwise, your installation's gonna go in a bad direction. And so what we do with OpenStack Ansible, so OpenStack Ansible is a community project and it's what we use to deploy our Rackspace private cloud. And it's fully available and ready to use. You can go and deploy your own clouds with it. I've used it to deploy my own. And so what we do is we have a ton of Ansible tasks and roles that go and configure all the parts of OpenStack. So we'll have separate roles for Keystone and Nova and Cinder and all this kind of thing. And then OpenStack Ansible is the glue that holds all of those roles together. So it has all the configuration, calls all the roles and that kind of thing. And so what we decided to do was why not create another role for OpenStack Ansible? And so what we did was created two things. One was the actual role itself. And a role for Ansible is a bolt-on list of tasks and configuration, things that you need to go do. Usually with Puppet, this would be, I think, a module or a manifest. But it's basically a group of things that you would want to have done at the same time. So we have that. And then we also have documentation. And the nice thing about the documentation is it's very beneficial for deployers. Because if you're going to go and deploy the security role, it will explain things that you need to turn on and turn off. It'll explain things that we've turned off for you to kind of shave off some of the rough edges and things that would disrupt your cloud. And it'll also go through and say, hey, look, we felt like this one was overly stringent. And here are the reasons. And if you want to turn it on, you can. And it's flipping a Boolean, redeploy. There's a few things as well that give you opportunities to go and configure SSH timeouts and certain things that you would apply an integer to. You can go and do that. The other nice thing about the documentation, I'll go through a couple of examples in a second, is it's valuable for auditors. Because if you use this role to secure your system and your auditors come and say, hey, are you applying hardening standards? And you say, absolutely we are. And they say, well, I need to see evidence of this. I need to see documentation of what standards you're applying. You can actually grab the PDF that sphinx outputs and hand it to the auditor. And everything is documented. I'll show that in just a second. So it'll have the actual control. And then right below it, it'll say exactly what we did to apply the control. And any kind of gotchas or anything like that. If there's any exceptions that we made or any opt-outs, it'll fully explain why there's an exception or an opt-out. Then the individual companies could actually just fork the Docs repo and go through, change the docs, print it out, give it to the auditor, and be done with it. And so getting into the role itself, it applies 200 security configurations in 90 seconds. And as I said before, you can go in and configure all kinds of things. I'll show some examples of the configuration here in a second. And so one nice thing about Ansible is it has a check mode. So it's kind of like a dry run type thing. And the great thing about it is that with this role, you can actually do a compliance check. So when your auditor shows up and they say, hey, I need to make sure you're actually doing all the stuff that you said you were doing, you say, hey, come sit down with me at the terminal, run it in check mode. And if there are any of those situations where perhaps Ansible pops up and says, hey, I would have changed this value to something else. And the auditor's like, hey, what is that? Why is that not set? You could say, hey, guess what? I've got an exception for that. I can show you. And here's the reason why we don't do that setting. And it can also be used in a cron job as well. So you can just run it in a cron job on a regular basis. If it fails or it says it would have changed something, have it send an alert to someone. And it may just be there may have been a sysadmin that changed the configuration file without knowing that it was being managed. So it's just one thing to consider. And it's carefully written to be non-disruptive to existing OpenStack clouds. So there's certain things like disabling forward on Linux Bridges. That's kind of bad in OpenStack land. We use a lot of Linux Bridges. And that would kind of upset Neutron a little bit. And so getting into the documentation, the value you get from the documentation, I apologize, the text is small. I'll send out the slides. So the very top part is the actual configuration requirement from the Stig. And then right below it is a link to the Stig Viewer. The great thing about the Stig Viewer is it's a very colorful way to review the Stig, compare it to other configuration options and things like that. And at the very bottom, it'll have documentation about exceptions, additional information, warnings, gotchas, like things you need to be careful with in this particular security control. So in this example right here is talking about default operating systems accounts other than root must be locked. And so as it says in the documentation here, you know, if you need to skip it, you can skip it, you can go and audit these accounts. And it'll also let you know that the playbook will actually stop when it finds this type of situation. So some of these things we can't audit. So we certainly don't want to roll through and go and lock system accounts without you having a chance to have a say in that. So actually just lock and tell you, hey, I found these three system accounts that I need to go and take a look at. And so an example of a configuration option, it'll explain in full detail where you can go and find the configuration options for a particular thing. And this example is the SSH server. And then right below it, it'll give you extra advice on particular configuration. So right here is one for the permit root log in for SSH. So in some environments, people log in as root and that's totally fine and we don't want to derail them, although I would tell them to please stop it as soon as possible. So we go ahead and turn that off, we don't force it. But if you wanted to go and force it, that's one where you can kind of ratchet it down just a little bit more. And this is also something you can show to your auditor and say, hey, we diverged and went ahead and locked this down because we felt like it was important. And so configuration is pretty straightforward. So here's an example of the SSH configuration. What you'll see here is a little bit of verbiage. Now mind you, the majority of the verbiage is in the docs. This is just enough to get you through the configuration. So one of the requirements is a set of 15 minute timeout for SSH sessions. If you don't like that and you want it to be something else, change it, redeploy. 90 seconds and you're done. Usually a little bit less if you're redeploying. And then you'll see out to the right, this V number, that's the actual number of the stig. So if you want to go back and review it in detail, you can go straight to the docs and go and review it in more detail. And of course there's some other configs down below. And some of the configurations are actually flipping booleans from yes to no or false to true, that kind of thing. Another example of configuration, so Audit D, love it or hate it, it does system call auditing. So there's a lot of different system calls that you can audit on a system. The one thing you got to watch out for is if your particular environment hits one of these syscalls on a regular basis, you're gonna be pounding syslog and it's not gonna be a good time. So you'll see there's a couple of these that we already have flipped to no. I think like Chimad right there, let's see, deletions and things like that. When you're actually doing the open stack Ansible deployment, there's a lot of that happening. And so it slows down the deployment a great deal. But all those are fully documented. And if after this is deployed, you say, hey, look, I wanna go ahead and turn all of these on. Flip those to yes, redeploy. Hopefully in 60 to 90 seconds, you'll be good to go. And so if you're sitting there saying, okay, how do I get this thing? I want this thing. So if you're already using open stack Ansible from the community version, it's available in Liberty, Metaka and Newton. All you have to do is there's a variable called applied security hardening, flip it from false to true, deploy, done. If you've already deployed, fantastic. Flip it to true and rerun the security hardening playbook and there's documentation on how to do all of that. The great thing is in Newton, we've actually turned it on by default. So every single open stack Ansible deployment, by default, we'll have it enabled. And in Liberty, Metaka and Newton's gate jobs, it's already enabled. And so if you're a Rackspace private cloud customer, this is coming in 12.2, which is coming very soon. I'm told by our product people I'm not allowed to say dates. So I'll just leave that alone. So speak to your account manager. And then if you don't use any of these things, you can use it with your existing Ansible playbooks. So if you right now are deploying on top of Ubuntu 14.04, you can go ahead and rope that into your existing deployment. There's no extra work required. All the configuration and everything in the docs are all inside the role. So it's completely just plug and play wherever you need to put it. And it's compatible with Ansible 19.20 all the way up. So the road ahead for the role is obviously we wanna get support for Ubuntu 16.04 and CentOS 7. Both have system D, which is very entertaining. And so that's gonna take some changes. And also we wanna rebase onto the new stick guidelines for Rails 7. So there's brand new guidelines that include all the new services and features and of course like system D changes in Rails 7. We wanna have a little bit better reporting in metrics. We'd love to be able to have something where maybe you could run the role and get output that you can directly hand to the auditor. Maybe get a CSV file out or something like that that then you could file away. And you could also trend on it over time. So maybe if you had a few of the things turned off and over time you said, hey look I wanna get to the point where I have all these turned on, you could do some trending. And then also we wanna find a way to identify configuration security issues within OpenStack services. So if you're familiar with the OpenStack security notices, the OSSNs, one of the ideas we had was trying to identify if there's a bad configuration in the system somewhere. Be able to identify and alert you to it. Not go and change it, because that'd be kind of drastic, but at least give you some type of a notification. So if you wanna get involved, we'll be here for the Design Summit Thursday and Friday, the OpenStack Ansible Group. On IRC you'll find some pound OpenStack Ansible. And then if you send something to the mailing list, just tag it with OpenStack Ansible and Security. And then links, I'll send out the slides because these are a little bit long, but the project is called OpenStack Ansible Security. So if you go to Google and search for it, those are probably the first two links you'll find. And last but not least, if you're thirsty and or hungry, go across the street to the Rackspace Cantina. It's very fun over there. And with that, that's it. And if y'all have any questions, I'll be glad to take them. Thanks. If you do have a question, I think there's a mic there and a mic there. All right, good morning. The conversion from STIG compliance checks into Ansible Format or PCI into the Ansible Format, who does that and how long would it take? So there's a new STIG version and then you have to take it, read it, convert it into the Ansible Playbooks. So this was a manual effort. So this was reading the STIG, understanding it, interpreting it, really trying to think about how it applies to Ubuntu, how it applies to an OpenStack Cloud, and then getting it exactly right. And then getting it to the point to where the user experience is really good. So for example, if you have a kernel tunable, like let's say something in SysCTL or something like that, you have to really figure out, do we wanna apply this now? How will that affect a running system? Or do we wanna just have it come back on reboot and let the user know, hey, you need to reboot to get this setting or manually go set it. So this process took, the review process took a while, but the actual creation of the role was maybe about a month and a half, maybe two months total. And I mean, it wasn't just me working on it, we had some people from some other companies, some other hackers helping out as well. But it doesn't really take that long. So I think that the toughest part is the analysis, like really looking at them and saying, which one of these do we wanna take? And then actually doing the Ansible work to go and change the config file or install a service or change the way a service is running or shut it off or uninstall it, that stuff is pretty quick. But of course, everything goes through OpenStackGarret and so that process can get a little drawn out sometimes. But yeah, not very long at all. I got two questions, if I may. The first one is probably just a yes and no. Can I use it to basically audit existing systems that they haven't configured using Ansible before? Yeah, so that's the beauty of Ansible's check mode. So you can actually just apply the role and do, I think it's dash capital C or dash dash check dash mode or something like that. And what it'll actually do is Ansible print out everything and it'll say, here's what I would have changed or I think it's like a different color or whatever. And then at the very end, you'll have a count of all the things that it would have changed. You could scroll back to the output and get it. You said you had to make some changes because rel and ubuntu are different. Wasn't the whole point of Ansible to kind of shielding that when abstracting that? Yeah, so yeah, I mean there's some nice features in there as far as like, let's say you're gonna go and install a package and maybe there's called something different in each one. There's, you pick up variable files and roll through it and do that. I think the big challenge we had was around, you know there's this thing that says, hey, connect to the Red Hat network and make sure you're connected all the time. And it's like, oh well, I don't really have that. I mean we could do landscape or something but that's a little bit different. But I think mainly it was kind of around those nuances between the systems. Sometimes there's things that were called differently and sometimes it was, we had to say, man, that doesn't exist in ubuntu. We have to go find something equivalent. Like there, one example was Pam fail lock in rel. If you actually try to log in with incorrect creds a certain amount of times, you use Pam fail lock to just lock them out at the Pam level. And we didn't have it. And so we went down the route of doing fail to band and trying to get controls that are almost identical to that. Thanks. No problem. Thanks for the question. Yeah, I have a question. So we have a stack already running and it has a lot of containers. So can we just take your Ansible and run on it? Should we be able to do that? So the containers themselves or the hosts that are underneath the containers? No, the containers themselves. You should be able to. There's probably some kernel tools, tunables in there that wouldn't make sense. Like, and it probably wouldn't have an impact on your deployment at all. It should work, but that's one thing we haven't tested in detail. It's mainly been in virtual machines and on hosts. Do you like host security hardening? But I don't see a reason why it wouldn't work. But there's some things like, I mean, we disable USB storage and things like that, we're in a container. It doesn't really have that big of an impact. Okay, thank you. Since you implemented this at-rex space, which I assume you have. So since that happened, have you actually survived an audit? And if so, can you describe how that process worked? So internally, we haven't deployed this on any clouds yet, other than testing clouds, staging, that kind of thing, because we're still working on the release. But if probably by the next summit, I'll probably be able to have more detail on that, hopefully. So this is a follow-up of one of the questions that was asked. I worry more about the 5,000 apps I've got running in my stack than I do the actual stack itself. The stack itself is important, but I got other people worrying about that. You talked about the hard work of figuring out how to turn the stig into the actual set of Ansible rules that you wanted, and you had a very tight domain. You knew what an open-stack hypervisor should look like and what it should do. How much work was that, kind of if I wanted to think about all these different domains, and how much commonality would there be, like if I started with your work, looked at it, how applicable might it be to other kinds of applications? Okay, so we're just thinking of non-virtualized environments or just other applications? My tenants. What's inside my tenants? Oh, okay. I got you. Those 5,000. The reason that I've got a stack. Right. Exactly. So from understanding you correctly, I think you could use this role easily, and you may have to translate certain things, and that's why we tried to make as many things just toggles or little variables. So that way if you did have a particular application that needed something enabled, like maybe it needed a kernel, tunable enabled. I gave an example about Neutron earlier with bridge forwarding, like that's kind of important. You should be able to adapt this role pretty easily without actually having to change the tasks. If you have to change the tasks, I imagine we probably have a bug that we need to go look at, and that needs to be a configurable instead. But I would say you could take this and go and apply it to an existing system. So for example, I run a few different websites, and I've actually gone and applied this inside the virtual machines as well, and had no issues with them. And some of them have some squirrely port requirements and some strange sockets to connect to and things like that. And it's been pretty good. Yeah, thanks for the question. This is a good talk. One question I have is you mentioned you, but have you run this on a CentOS-based system or at the host level? So our scope for this one has been only Ubuntu, because that's the one that we deploy underneath our clouds for now. Do you happen to know if anybody's tried it, if there's a lot of changes you have to make on the, because as you know, it's likely different, right? You know, where the commands or configs are. There's gonna be quite a few changes. So especially going to CentOS-7 from Ubuntu 14.04, your system D is a big change. You know, yum in RPM as opposed to apt is a big change. So it's on our roadmap of things we wanna accomplish. And if it's something you're interested in participating in, let me know, because that's definitely gonna be high on my list for the next quarter. Second thing in that regard, let's say my OpenStack services are running in containers. There's one level of indirection that I have to go into the containers to check things around. That's part of this. Already you have that baked in? So we deploy our OpenStack inside of containers as well. That's how OpenStack Ansible works. But so far we've kept the scope just to the host. So a lot of work that we wanna do inside the containers is kind of a subset of this. Like so we talked about some of the kernel tunables earlier. There's some that don't make sense or if you try and tune them in the containers you'll get denied and that kind of thing. But yeah, catch that with me after if you'd like to contribute. We can use the help. Thank you, I appreciate it. Hi, more of a standard build versus buy type question, right? So there's a lot of work to take PCI, SOX, HIPAA, all those standards are wrap them and turn them into Ansible. Where would you see the line where you can go and pull something off the shelf that can scan your whole subnet and rel, sentos, muntos, it's transparent. It's just looking at all vulnerabilities and we're ported on it. I understand open source and we wanna build it ourselves but what's the tipping point where you say, if we did this for STIG and PCI and SOX and we have to do this every quarter every time they release it's gonna take us X amount of time in hours versus pulling something off the shelf to scan subnets and get me the same results. Where do you draw the line on that? So, that's a good question because I've been in that situation before. I think really what it comes down to obviously is time constraints but there's one time constraint you really have to understand is that something like this is open source it's a little bit more fluid you can make adjustments where if someone comes in, thanks, if someone comes in with a closed source tool that maybe runs on a closed source operating system it's a little bit more of a challenge to go in there and tweak it. So a lot of people say, hey, I'm gonna go buy it because it'll be faster. Well, it's not necessarily. So really the goal here wasn't so much to scan for vulnerabilities. Like the audit mode was an afterthought. Like afterwards we said, man, it'd be great if we had an audit mode. I don't know, that's a really tough question. I think it really comes down to the situation and it really comes down to what that vendor's gonna do to partner with you. So if you do choose to go and buy, it's like, hey, what are you gonna do with me to customize this or how much customization do I have? I think that's the big question to ask. I think the open source is very nice because you can kind of stand on the shoulders of other people. So for example, while I was working on a couple of parts of this role, one of the folks in our community works for Comcast and he gave me some feedback and he's like, hey, look, we should do it this way and not this way because we run into this other problem and I was like, wow, okay, I've never run into that problem before. So we've had some other contributors show up and give more input on it and we'd had the security mid-cycle in San Antonio as well and had some people show up and give input. So that's one of the benefits of open source. You can lean on more people than just that one vendor. Hopefully that answers that, that's a tough question. All right, anything else? All right, well, thank you all very much. I appreciate it.