How to meet federal encryption deadlines before September: a guide for DoD contractors

Uh, in November, there is, um, requirements for CMMC phase two that are kicking in, uh, certification for contracts with, uh, CUI. January 1st, NSA has requirements for national security systems. Um, this is only a 7-week gap between the FIPS sunset and the CMMC phase two. So, can you talk a little bit uh about these deadlines and how it's impacted your work and maybe customers and what you're doing here at CIQ? >> Well, yeah, let's start with um how it's uh impacted me and speaking sort of very personal as it sort of a product manager, right? I'm always trying to look at whatever customer needs are, uh outline a schedule, and then line things up so they land to meet market needs.

Um, I would say that the onrush of the DFAR that initiated these changes uh flagged uh the move of of FIPS 140-2 into historical status. Uh frankly, we had a number of customers reaching out to us saying, um we are not prepared for this. How do we do this? How can you help? So, um luckily, we have a a very sharp security team, a very sharp engineering team, uh a very a team that understands cryptography uh very well. So, we are able to build on effectively CIQ already being ahead of the game um to put together a solution that we'll talk more about, but in short, it um helps someone address the OS and system level controls uh and and the and in particular the cryptographic requirements sort of out of the box.

Um, you know, I think it's a real concern here because one, um when you talk about your cryptographic compliance, your compliance in general be a DISA STIG or NIST 800-171, which people call CUI, um um uh controlled unclassified information. Um, um often times you treat it as shut or forget it, right? You do a big spike, big spend, you get it assessed, you check the box. Um you may have playbooks to kind of manage drift, right? But what you are not thinking is about a complete system overhaul. Now as you just laid out from the time that your existing 140-2 models go into historical status um to the time that assessors are going to be looking for you to be compliant with 140-3, it's 7 weeks, right?

And >> Mhm. >> um you need to treat this like a program uh to a certain extent. Um cryptographic modules or you know, as Jeremy will talk about, are deep in your system. They're in the middle of critical path and core operations. Um so you need to apply change management. And know this, it is not enough to have an assessor show up and go, "Yeah, we have modules, but they're in historical status." That's going to be viewed as an evidence gap, which is worse than documenting maybe that we have modules in process that are not um validated yet. Um and then lastly, you know, you need to think about when I say look at this from a program management standpoint, I think the stat that I have here is um there are 76,000 orgs that need level two certification.

But as of last February, fewer than 1,100 have completed it. And there's a There's There's a finite set of um third-party certified organizations or C3PAOs um that can actually inspect and validate for you. So if you're not getting in line and you're not getting to a place where you're ready for the assessor fast, you could be in trouble. >> Yes, for sure, for sure. Um I'm not sure uh Dave or Jeremy, if you have anything that you want to add on that point, but before you do, I have one more thing to say. And Brian, you alluded to it. Um so you can be FIPS compliant on paper, but you need active certificates.

And also, if you've read any of our blogs, FIPS mode is not FIPS compliance uh on your system. >> is not enough. >> Right. Exactly. Exactly. Um so if we are looking at organizations and we're talking a little bit more directly about 800-171 and cryptography, um where does STIG fit in? Um and what do you think is the gap you may have seen or heard about, Brian, um for organizations who think they're ready but are not ready and maybe how does C2S help? >> Well, um uh there's a couple of ways. One is I'll just go back to Jeremy, what Jeremy said. I think you see a lot of FIPS, yeah, I have FIPS and it's on, right?

Um they are they are not checking to see if the FIPS modules they're running, first of all, are actually actively listed as approved on uh the NIST CMVP list. I'm forgetting um um the acronym. Uh the cryptogram cryptographic module uh validation program, right? And if they are not they're on that list, uh then you are not certified. Um uh and so that goes back to, you know, on doesn't mean you're compliant. And then to your point, Hope, I'll just underline it. Um if uh you have not had an assessor certify you, then you are not compliant. Um but then the other thing I hear when we talk to our customers is often times sort of an over indexing on the non system controls, sort of process controls.

>> Mhm. >> I'll either see it go either way, right? They focus in one area or the other and then in particular when they're looking at system controls not considering this isn't hey, I have a head node in a cluster environment or I have all my compute nodes done, right? You need to be able to prove that the underpinning of all of your infrastructure um is compliant. So that's probably the biggest gap. And I know Dave and Jeremy may see others. >> Well, it's it's not just the algorithms. The entropy source has to be compliant as well. >> Mhm. >> So you have to have the certificates of the entropy source.

It's not just the modules and their cryptographic implementations. >> Um and then hope regarding STIG is the way you know, the way we kind of describe STIG very casually is STIG is the is the mother of all security control policies, right? So what you will find and I've gone through this mapping is that STIG not only references your FIPS security posture, a number of the STIG controls map to NIST 800-171 controls which also ultimately map back up to CUI and the CMMC or NIST 800-53. So I think the one thing that I would say is that if you are already STIG aligned >> Mhm. >> then or your systems are already STIG'd, then you are likely in a good situation.

However, STIG is not a one-for-one for CMMC. So look at it as a starting point, but it's not the end of the journey. >> Right, right. Agreed. Um so with that, we're going to we're going to move into our technical our technical expert, Jeremy. We're going to talk to you for a few minutes. So we've talked a bit more high level, but you are one of the if not the person at CIQ has who has been very closely working with our certifications ensuring that CIQ is doing what we need to do for customers. So if we are talking about FIPS 140-3 validation at the module level.

Why does it matter for our customer whether their certificate is actually active or historical and how can they see that for our products? >> Well, so it it matters because all of the modules that we ship that Rocky ships actually they they have FIPS mode built into they have all the code that's there. They ship out of the box. It's maintained upstream. The problem is if it hasn't gone through the certification process it might not be complete. And that's that's the whole point. The certification process gives a customer a guarantee that what they have has passed the NIST tests, the entropy test, the algorithm tests. It will check itself on startup.

If you just download a Rocky and put it in FIPS mode, you know, it's going to look the same but it won't actually be certifiable and it wouldn't pass an audit. So so that's the important part and the other thing that CIQ has done is that we've made FIPS 140-3 we've back ported 140-3 to older versions of Rocky. So you can actually get 140-3 on 8.10 our long-term supported version. Now, lest anyone think that, you know, we're we're evilly taking the work of the open source community and and not giving back. All of this stuff is live and available as open source on our GitHub uh uh repo.

You can download every single change we've had to make. Uh of course, you would have to then go through the certification process yourself. So, it's it's it's kind of easier to get the the bits from CIQ. Uh you can check on the NIST site by looking up CIQ as the vendor, and you can see exactly what we have certified. You can download the security policy. You can take a look. Um all of that code is submitted upstream. All of that code has been uh certified and tested. And the other thing that we do, and this is where things get a little fuzzy, >> Mhm. >> the bits that get certified are essentially frozen.

So, they are the FIPS certified versions of the RPMs, the the module. They will never change, or at least it's really hard to change them. Um but obviously, bugs happen, especially in the in the era of AI attacking open source code uh for for security bugs, you have to have CV fixes. So, we essentially have a stream of RPMs that we call FIPS compliant, which are the same cryptographic bits that we have certified, but we're putting CV fixes on top. >> Mhm. >> So, you know, this obviously depends on the customer. If you if you must have FIPS certified and nothing but FIPS certified, then you can download those packages.

You're frozen on those. You're good to go, but you haven't got CV fixes. >> Mhm. >> If you go with our compliant stream, you've got the same certified algorithm bits startup, but you've also got the CV fixes. So, it very much depends what um the auditors and what the requirements are for the customer. But, that's >> So, what >> basically why I would say we were providing a service that that, you know, >> So, one of the callouts I think we should make that I think we've talked around a little bit is which CIQ products should we look at for um cryptographic compliance? Which of our products um would viewers >> uh want to do more research on?

>> Well, uh I you know, so I'd say in particular, probably the best place to start, if you have requirements for cryptographic compliance, you likely have requirement uh for uh for other areas of compliance like DISA STIG and or you want the whole uh NIST 800-171 uh compliance. So, the place to start there is going to be uh with our uh Rocky Linux from CIQ Pro Hardened or RLC Pro Hardened, uh which you can get on all the major cloud providers. Uh you can uh download uh as a QCOW or a VM. Those will come pre-remediated 97.8 58% um for CUI. Now, specifically around the FIPS compliance, you are going to want to look at our LTS versions.

Um where we are shipping with um the compliant or the certified uh modules out of the box. So, you lay it down, you have your FIPS dash uh 143 certified modules. But, then also be aware that we make the same uh available without the pre-remediated compliance available in our Rocky Linux from CIQ Pro or RLC Pro LTS. >> Mhm. Thank you, Brian. Um one other thing that I would love for you to talk about, Jeremy, um, not that it may be lost on anyone, but I want it to be so clear how much effort it takes to go through this process and that it's not a quick process, right?

Um, It is definitely not quick. Can you give some insight, um, on, you know, you know, maybe not too much of the behind the scenes, but a bit of what the process is like and how long it actually takes for >> Well, So, what you you have to do is you take the open source components and then you go through there are certain requirements that FIPS has. So, you have to make sure that you have known answer tests tested on all, um, of the algorithms that you're shipping. Not only that, whenever you generate keys, you have to do pairwise consistency tests to make sure the keys work.

You also have to make sure that when modules are actually loaded for the first time, that they are, uh, they basically hash the binaries that you are loading and make sure that they match the signatures of what is stored on disk. But, the what you have to understand is that many of the modules that are created by upstream maintainers, they're not, uh, FIPS engineers. They're upstream engineers, they do a fantastic job creating the source code, but they haven't gone through the FIPS process. So, there are things that it it essentially they they miss and, you know, as a maintainer of another package, Samba myself, you know, we don't think about FIPS when we're writing that code.

>> Mhm. >> So, what you have to do then is you have to go in and look at the modules, work out where the gaps are in the FIPS compliance and then you have to, in conjunction with the lab who are the experts, go in and say, "Okay, here's my remediation for this issue. Um does this it does this satisfy the requirements?" One of the classic ones is all transient key material or all transient cryptographic material must be zeroed before being freed. Um and so a lot of the time that that just isn't done. Um so you have to add a lot of the code in to do that.

That was one of the big changes for the NSS library we had to do for post-quantum um compliance. Uh and then of course you you have a long dialogue with the lab. Uh they have to test everything. You have to set up uh an operating environment that they can test on. You have to work directly with them. Essentially takes months. Um and depending on the module, they may come back to you and say, "Oh, since this was uh this module was released, the requirements have changed. You have to had a whole new bunch of restrictions that weren't originally there. So then you have to write new code." Um and so yeah, that's that's where it gets complicated, messy, ugly, and a nightmare.

>> Right. And end-to-end it could be it could be a year or more, right? >> easily 18 months. And sometimes upstream will say, "You know what? Those changes you had to make, they suck. We don't want them." So then you have to maintain them to separate set of patches. Uh and that's where we are with with our with the upstream kernel. The the kernel uh the upstream kernel engineer is not Let's just say they're not particularly friendly to the FIPS requirement. >> Yeah. >> Um but the the like I say, I posted a link to our repositories. >> Mhm. >> Every single code change we've had to make, every single patch we're carrying, you can see everything there.

If you want to see what we've done, everything is in there split out with individual patches with lists of what the patches do. So, if anyone wants to kind of watch the sausage being made, which is very unpleasant, that's where you can That's where you can watch the meat being ground. Yeah. >> Um the These are all uh you're speaking from personal experience, right? I kind of joined on the second round of the process to witness some of the pain. Um uh but uh this is not theoretical. This comes from practical experience, right? Yeah. >> Yeah. >> Oh, yeah. >> So, we've talked a lot about FIPS, but this also has to do with PQC, post-quantum uh cryptography, right?

These are also um some of the certifications that CIQ has pursued that are built uh that are modules that are available in the products. Um Jeremy, can you talk about um why PQC is particularly impactful now and why organizations who maybe have not paid as much attention should uh give it more attention very soon. >> Okay, so count me among the the idiots who who thought, "Oh, this PQC stuff, oh, it'll never work, you know, oh, it's just just a silly requirement." And then Google published that paper. And um so, if you're not familiar, PQC is post-quantum cryptography. I am not a cryptographer, uh so I do not understand the math behind this uh it essentially it means that you can use quantum algorithms to break most of the common key exchange algorithms that are being used.

Uh the uh elliptic curve algorithms, the RSA algorithms that are being used to exchange keys. This is very bad. Um and I I I thought this was years off and we didn't need to worry about it and then Google recently this year published a paper that essentially said that not only had they made progress on this with quantum computing, they'd made so much progress they weren't going to publish it. They were going to publish a proof of a zero-sum proof that says, "Okay, we here's how we can prove we can do what we claim we can do, but we're not telling anyone or anyone except the US government this is so dangerous." Yeah.

The reason it's so dangerous is the the uh storage problem whereby if you capture the cryptographic traffic going over the network, the key exchange, and you store that data, right now you can't do anything with it. Uh it's all encrypted. The the algorithms are all safe. Go a few years down the line or as Google is saying 2029, which is not very far away, and someone may have a quantum computer that can then reanalyze that stored data and crack the key exchange. Once you crack the key exchange, all of the encryption is open and it you might as well have been using Telnet or uh communicating.

>> I I this this is sci-fi come true. I I didn't come prepared with the movies, but there's two recent movies, right, where there's literally a fight for the magic key, right, uh the magic uh post-quantum algorithm that could unlock all the keys in the world, right? >> Yeah. Yeah. Pretty neat. Oh, and you know what? Um this is something I read and this is where it really hit home for me that it's not just um the storage and decryption later, but once this is actually running and bad actors can, you know, uh enable it, they can decrypt your password as you are typing it. So, this is not something that would even happen after.

As you are typing your password, if they have access, they can decrypt it as you are typing it. They will get enough information and with uh post-quantum computing, they will be able to figure it out. And >> Over SSH, yes. If you got the key strokes going over the network, yes, theoretically you could do that. >> Yeah. Yeah. We'll we'll see what happens, right? Um So, next, let's talk a bit more um about Bri- one of Brian and my favorite topics, RLC Pro Hi- Pro Hardened, right? Um So, Pro Hardened in particular, let's talk about um the work that it moves off of uh organizations. How does it help relieve uh some of their compliance burden?

>> I'd I'd love to uh let uh Dave comment to that because he spends his entire day interacting with customers or or using it to do that. >> All right. >> so it Let's talk about the the end user for for a second. So, from a language standpoint, the the individual who's actually doing the work. Um when you're when you're inside of these organizations, you either have the people who have the knowledge and and time, um so the resources to be able to go and and achieve these compliance requirements um with with what you have already. So, you got to work with a vendor in order to have your FIPS uh portion of it, but now to get to STIG um and to meet those requirements, that is hours, days, weeks of time that's being done and then maintaining it going forward that you have to go and do.

Um And if depending on where you're selling into, um who you're working with, what the compliance requirements are, um that's where a lot of the challenges end up being. And and frankly, what we keep hearing over and over in the field is you know, the budget problem is not just buying new hardware, buying new solutions, having to cut costs. It's also on people. Um there's an expectation for the individuals who are doing the work to do more with less. And the last time I checked, we all have the same 24 hours in a day. Um and especially for those who are are building solutions that have to support another user farther down the chain, um you don't want to necessarily spend your time maintaining and meet and reaching compliance requirements.

You want to build new things. You want to address uh other other fires that are um you know, more interesting and and more pertinent. So, you know, being able to deliver a solution that checks these box checks these boxes um right away uh makes life dramatically easier for them. Uh and that's again at at that end user where it's being deployed standpoint. Now, if you go a step further up from that and you talk about a solution provider, uh so somebody who's taking a um a product of of their own and shipping an appliance, um they can they may be using the operating system that they're pulling from um from the open source uh whether that's Rocky or or another option.

Um and if they have to be able to deploy FIPS, well, as Jeremy spoke to, you have to spend the time going and achieving a FIPS certification, which is again resources from a time standpoint, also financial costs. Um and then you have to go and continue to maintain it and make decisions on what versions you're going to build around and behind. And those partners that we work with, what I keep hearing over and over again, I don't want to be an OS vendor. Um there's a lot that's involved with it. There's a lot of risk that comes along with it. Uh in my uh you know, 10 years of uh working in the storage industry before this, um the golden rule was never lose anybody's data.

Um whatever solution you put forth, make sure you don't lose anybody's data. Uh Um, in in this world now, it seems to be I don't want to be an OS vendor, go and trust somebody who knows how to do it and can achieve these pieces. >> Yeah. Yeah. And I I So, so, you know, with Dave laying out what we have seen, he and I together, I mean, all of us really kind of first hand, is um, that uh, customers are in a crunch. Now, we have this deadline. So, there's a clock on not, hey, we need to eventually do this, whether tight resources, um, but this has to happen by November, uh, 10th, right?

Um, so, uh, how does Pro Hardened help? Why do I love talking about it? Why do I think Dave loves talking about it? Jeremy, it's cuz we put together something that really does truly, um, address a major chunk of that problem, to the tune of six or even seven figures, when you consider the cost to achieve certification, as well as the cost of the head count. So, RHEL C Pro Hardened gives you out of the box FIPS 140-3, and make no mistake, we've invested heavily on behalf of the community and ourselves to get ahead, to be ready for this. That also ships, uh, with post-quantum computing readiness, um, cryptography, as Jeremy just talked about, but then, uh, moreover, the time that you would spend, let's talk worst case quickly, right?

I just I go get community Rocky, which I'm not knocking, but if you are in a you have to run in a certified environment and comply, um, I first, um, have to, uh, pull that, uh, down. I have to get, uh, the correct modules installed and put into place. I then, if I want them to be certified and compliant, I got to go go all the work that Jeremy did, which takes a span of years. Next, I'm likely going to run a scan to see if I'm cool and compliant. What I'm likely going to find is that I'm no more than 60% cool and compliant. I then need to take the hundred and something other controls and go through a trial and error sort of experiment, tweaking, cut testing, tuning those, deploying them, testing workloads on them, coming back and doing it again, right?

And then, as soon as I lay that down on a system, I got to come back and do it again in a week or a couple of months because of drift. So, the Pro Harden gives you the fits, it gives you the remediation, and then it also adds something we call proactive security modules. Um Harden modules like LKRG or Linux kernel runtime guard, um hardened OpenSSH, hardened Glibc, hardened memory allocators that also say, "Hey, worst case, if my system gets compromised, I have what we call some proactive um protections in place um to prohibit um um exploits at the exploits at the kernel level. Um so, long story short, right?

Um Pro Harden, I think, gives a customer uh the baseline that they need to save uh not even hours, weeks, if not months on their path to meeting this compliance demo. >> Well, and to expand on that, too, Brian, the other thing that we're seeing in the field, and I'm glad you hit on the proactive security measures that we we built into it. So, it's one thing to take a a baseline operating system and achieve uh your compliance requirements.

It's another thing to take a step back and address some additional security concerns and actually harden the image um and have these proactive security features baked into it uh because one way uh some of our our customers in the federal space are are using it, um they're treating RHEL C Pro Harden as a golden image uh that they can build from Uh uh because there are times where a deployment will go into the field and may not have internet access. Um and there is a real risk that comes along with that deployment. So, they're not getting patched. They're not getting those security updates for other pieces.

So, how do you ensure that that um deployment is is continued to be protected against? OKRG is one of those feature sets that are are being used as that. So, now um any of these these engineers Jeremy to your point of okay, you've done the work, you've built the application, uh you've achieved compliance. Well, now what broke? What doesn't work? What is the What is the upstream one to support and whatnot? These engineers that are building these applications that are going um on these uh deployments um that would run on Pro run on Rocky or run on on on anything, um they start to ask the question, "Okay, well, will my application work with, you know, X package that's in there?" And building up to compliance and keeping every engineer as well as the security teams happy is very difficult to do.

So, rather than that, the teams uh that we're working with are taking Pro Harden and treating it as a golden image to where, "Okay, let's build the application off of this and if something doesn't work, tweak, you change, and maybe you continue to maintain compliance." Uh and if you're continuing to maintain, then there's no reason to write a a poem, there's no reason to make any adjustments and call things out. You're good to go. And you know what? If you do have to turn off a lot of those pieces, you still have proactive hardening that's been pre-built in, pre-deployed that everybody can go and run with.

Uh so, again, you have a a stable baseline, a secure and compliant baseline that everybody can start with. >> And I And a key thing to add Sorry, Jeremy, I'll just add real quick. The phrase is uh as our counterpart in uh Fed said is we're used to building up compliance. The good thing with Pro Harden is I just have to turn things down. Um I start complaining. Sorry, Jeremy. You're over to you. >> No, I I was just going to say I I wanted to drill into to the the features that um I'm sorry. Should have turned my phone off. I apologize for that. Uh the features that um uh uh RLCH provides um so there there are two layers of protection.

One is that when you're looking at a compromise when you're looking at a security vulnerability, there are usually two ways it goes. One is that for in some way manages to corrupt system memory or an application memory. And that's where um libhard malloc comes in. Because when you're running with that, all malloc is checked both on allocation and free. And if there are any overruns whatsoever, that will take out the application. It will It will catch it. It will crash it. So that's usually the first layer of vulnerability that that attackers try and access. And then after that, once they've gotten into an application, um if they manage to get past hard malloc, then they try and leverage that into getting kernel credentials that they're not supposed to have to become root on the system.

And that's where the LKRG runtime protection in the kernel steps in. So you have basically this multi-layer uh set of protection uh that that makes you have a more secure base to build your products on top. Now, it's not perfect. You know, the people working on LKRG and all this all this stuff is open source, by the way. None of this is uh you can look at everything that's been done. There was uh some guy who basically decided to try and create a kernel rootkit that was explicitly immune to LKRG, the protection. And so then this triggered a war between the LKRG developers and the guy doing the rootkit.

And and I think the LKRG developers are winning. But we track that, maintain it, we work on it, we participate in that. And so everything we learn um from these hostile environments gets funneled back into the product and improved, which is a really, really good thing to have. >> Mhm. Mhm. Excellent. Um So now we're in our free-for-all section. >> Yeah, that's lk.org. Yeah. >> Yeah, yeah, yeah. But um the lk.org is is quite impressive and we do have someone on staff solar designer who uh if you don't know about solar and the work he's done, it has been a major contributor um if not the contributor uh to to getting that uh implemented um in CMMC.

Um so one of the points also to make is when we have talked about cryptographic compliance. We've talked about FIPS, we've talked about PQC, we've talked about 800-171. And a lot of people believe uh this is only impactful to the defense industrial base or some of those that are defense adjacent. Um it is only impactful um to government organizations, but this extends beyond that to many, many uh other industries. Um Have any of you and and we you know, we don't we're not going to necessarily name names, but have you worked with any customers or prospects in other industries where you think this is particularly impactful for them?

>> You're on mute, Brian. >> We'll just start the bidding with. So first and the reason you know, I'm I'm jumping in I think the team has other concerns. It's um pro hardened wallets gotten a lot of traction in DOD and Fed. Um There are many regulated industries and even unregulated industries that need to mitigate the catastrophic effects of a breach via any of these vectors that we've just talked about. Zero days that weren't patched. Cryptographic, you know, post quantum computing. Exploits of services and ingress. So, you know, we've looked across industries and I'd say first we'll go out just to this conversation here.

We've talked government entities or what you would think traditional government contractors, but keep in mind that a lot of even medical and other research are actually handled by higher education and universities that are subject to the compliance to the rule regulation of these compliance mandates. Another place that you look that is a regulated industry, but traditionally under different regulations is going to be communications or telecommunications. Right? If you think about the catagro- the catastrophic snooping and spoofing that can happen if you crack the cryptography in telecommunications. So, I'll stop there and I'm sure that the the group has some other ideas or other references. >> So, I I'd call out that every company needs to be thinking about this.

And And you think about how security has changed over time and where fears and concerns were like my my grandparents to the end of the day would tear up their mail and put it through the shredder because if somebody gets your address, you know, it's over with. They're going to get to you. Well, we've we've moved to a time where we are watching vulnerabilities become known live um, without being embargoed, um, to where we have to go and address them as as quickly as possible. And as we move forward with more powerful machines, more powerful algorithms, you have to raise your baseline, uh, in how you you address this because it may not, uh, be just the data that you have.

And And I'll give you an example. I was talking to one, um, uh, one head of security at a at a company who had said, "You know, uh, if I can make all of our, um, company data available online for anybody to go and use it as they will, I would." And the reason why is people trying to breach my environment to get access to that data because I don't own any IP. My company has zero IP. But if they can get access to that data and use it as they will, operations won't break. I don't have to worry about taking systems offline. I don't have to, uh, worry about, um, any other slowdowns in in the company that I'm responsible for maintaining.

But I can't do that. I have to protect this, uh, this information. So, even if the information that you have is probably been breached from 13 other areas and, um, doesn't necessarily matter, your operations of your company, you need to be able to go, uh, and address, um, uh, from that from, uh, from that standpoint, too. So, you know, what we're talking about here is is not just for the regulated environments, um, for these industries where you are required, um, by by law, by, um, by some other form in order to meet. Even if you don't fall into that category, you got to raise your baseline of as to how you're protecting everything.

Um, and you're being asked to do more with less. We all have the same 24 hours in a day. Um, there's new technology constantly coming out that you are trying to learn to up your game, um, for both your company and as an individual. These baselines, we're helping companies and individuals achieve them faster, um, with less effort and energy. >> Mhm. Okay. >> I'm we're doing it in the open, too. >> Yes. >> And we're doing it in the open. That's That's That's another big point, to be able to go in and review everything that that we've done. >> It When When you get When you get our repositories, you don't get given a big blob of a patch with all the changes in and work it out yourself.

You actually get each individual patch. You can see with the commit messages, and so you can see what we did and why. >> Mhm. Um so, any any parting words before we close this out? We have We have a couple of more minutes. Any parting words, anything we didn't mention that you think is important for our our contestants to hear about? >> Um so, we're track We're tracking. We're doing FIPS certification on some of the advanced Linux kernels, some of the upstream kernels. We're We also have kind of a skunkworks project to try and separate out the FIPS certification pieces of the Linux kernel, so this can be done separately as a module.

If anyone's interested in that, please feel free to ping me, and I can point you at the repository, and we can work together on this. We have plenty of ideas how to do this. You know, if you want to do it yourself, you don't have to start just from the the base Rocky packages. You can You can download our source. And at least At least that gives you a baseline to work on top of to do your own certification. Having Having said that, one of the unpleasant surprises I I had when I was first doing this was I saw another vendor had certified a particular version of one of our packages, and I went to the lab and said, "Hey, this already got certified.

I don't need to do anything, right?" And they're like, "Rules have changed." It got harder. There's a bunch of extra stuff that you have to do that the previous vendor didn't. Oh, thank you. So, yeah, uh the I mean, they they keep tightening the requirements all the time, which is good. I mean, that's the whole point is is to keep uh the security keeping being improved, but it doesn't mean you can't just take something that someone else certified and say, "Hey, I'm good." >> Right. >> Yes. >> Um and that will lead into mind, Jeremy. I think I'll generally use an old adage um that we are moving into a world to say that if you're on time, you're late.

Right? And that that's both in terms of compliance. I'm looking at a stat here that says the FIPS validation time, if you chose to take it on for yourself, is it increased from an average of 367 days for 140-2 to 542 days for 140-3. And that's not to accounting for necessarily other changes um that happen in the rules and regulations or within your org along the way. Um but we're also dealing with that with the vulnerabilities we've seen recently with copy-fail, with kind of the world that will say sort of demonstrated by Methos. Right? If you wait to react to a compliance request or a security vulnerability, you are late.

So, my final words if you're on time, you're late. >> Yes. >> Yeah, and to add to that, um you know, don't be your own OS vendor. Um that is I honestly that is what I keep hearing over and over again. Is it something that you can do? Yes. Are there other things that you would rather do? Definitely. Um I'm sure most people uh listening to this can change their own oil in their car. Would you rather go do something else with your Saturday morning? Um >> Yeah, what are our own OS vendor in itself? >> Yeah, absolutely. >> So, this has been a great conversation.

I appreciate it. Um as a reminder to the audience, three things that you want to check into, hopefully before, well before September, verify your FIPS certificate status. Check whether your Linux environment is running validated cryptography or you just have FIPS mode turned on, which is really not going to help you. And if you want more help, more information, someone to take a look at your environment and help you work through it, we at CIQ are always happy to help info@ciq.com. You can also get more information on our website. This recording will be available on YouTube shortly and again, thank you Brian, thank you Dave, thank you Jeremy for making the time today to have this conversation.

It's very important. >> Thank you, Hope. >> It's been a lot of fun. Thanks. >> Yeah. >> Okay, thank you.