Encryption, FIPS 140, and Compliance

Cole French:

Do you ever feel like data is unmanageable or like you have no idea how to at least protect it? Then you won’t want to miss today’s discussion on the intersection of encryption and compliance.

Welcome to the Cyber Compliance and Beyond podcast, a Kratos podcast that brings clarity to compliance helping you leverage compliance as a tool to drive your business’ ability to compete in any market. I’m your host, Cole French. Kratos is a leading cybersecurity compliance advisor and assessment organization providing services to both government and commercial clients across varying sectors, including defense, space, satellite, financial services and healthcare. Now let’s get to today’s episode and help you move cybersecurity forward.

Some recent estimates have postulated the data is now the world’s most valuable asset. Unlike other assets like oil, for example, data proliferates on a staggering scale. In other words, it doesn’t seem to be finite subject to the law of scarcity.

This hammers home the importance of answering the question that each of you are probably wrestling with: How do I protect all this data? A simple answer to the question is encryption, but any simple answer has you immediately asking more questions: what encryption should I use? How should I configure it? And perhaps most importantly, how can I be sure it’s adequate? I’m excited to dive into this topic on today’s episode. From the Enigma to the FIPS standard, to the possibilities and threats posed by quantum computing, encryption is a fascinating topic that affects all of us on a daily basis.

I’m joined by Evgeny Gervis, the CEO of SafeLogic, a leading cryptographic solutions provider. Evgeny shares his expertise on the technical aspects of encryption, while I add some expertise and commentary where most of you sit at the intersection of encryption and compliance. We hope you enjoy this episode.

Evgeny, thank you for joining us today and providing your insights on this important topic. Let’s jump right in. Can you start off, just tell us a little bit about the FIPS 140 standard and why does it matter?

Evgeny Gervis:

Sure. Well, first of all, Cole, thank you so much for having me. Really appreciate it. Yes. So, FIPS stands for the Federal Information Processing Standard. It’s a standard from NIST, National Institute of Standards that basically governs how encryption algorithms have to be implemented, what kind of algorithms you can use, and so forth. The reason it’s important is because it’s not only what algorithms you can use, but it’s also how they’re implemented. There’ve been plenty of issues in the past where poorly implemented encryption can be broken. So, it’s not necessarily that there’s an issue with the underlying math, but poor implementation can lead to problems.

So, NIST really wanted to make sure that there is a standard, and it’s a very rigorous process to get the cryptographic module tested through the labs and through NIST to make sure that it meets the requirements. It’s particularly important for the U.S. public sector. The government organizations, they pretty much want to see that when they purchase a solution that uses any cryptography and that’s pretty much everything these days, using some cryptographic control that actually meets those NIST standards, FIPS 140 standards, because otherwise they just don’t know. Somebody might’ve woken up one day and coded something and called it encryption and they just don’t know how good it is. So, for the government really, unless it’s FIPS 140 validated, they consider it to be essentially no stronger than plain text.

Cole French:

Right, yeah. Yeah, that’s really good perspective. I think speaking from a compliance perspective as an organization here at Kratos, compliance is what we do. Just to expand on what you’re saying, the importance of the standard is exactly that. It gives us something to measure against and obviously standards can be problematic, which I think we’ll get into and discuss. But yeah, to your point, that’s right on. The importance is that it gives everyone a standard to which they can comply and a standard to meet, so that hopefully, like you said, we’re not having configuration issues. Because yeah, you can have all the encryption you want, but if it’s not configured properly, it’s like you said, as good as plain text. Jumping back to the FIPS 140 specific, we hear terms in the compliance world, validated and compliant. So, are those the same things? If not, what are the differences?

Evgeny Gervis:

Those are different things and people sometimes use terms interchangeably and it’s very important to define what they are. FIPS compliant, people sometimes use it in different ways. Sometimes people just say, “Well, we have something that we believe meets the requirements. We’re just going to call it compliant.” Well, somebody other than this thinking that it’s not really good enough. So, sometimes people will use somebody else’s module that has gone through validation and they say, ”Well, we’re compliant because the module that we use has gone through validation.” It’s a stronger argument. However, the strongest argument that we find, what we would call the gold standard is FIPS 140 validated.

It’s actually when you’re using a module that has gone through the validation and you also have a certification in your company’s name with NIST. So, NIST actually has a website called CMVP, the cryptographic module validation program. You can actually go in there and you can actually search for all the FIPS 140 validated modules. It will show you that module is active, which is what you want to have. It means it currently meets the standards versus historical, used to be validated at one point but not anymore. So, all those things are listed. So, really, as a company, what you would like to have is FIPS-140 validated module, which again means that it’s gone through validation and you have an active certificate that can be found on the NIST website. This really provides a lot of confidence for say, a procurement officer, where you go through a public sector procurement situation.

A lot of people can claim compliance, but if you can say, “Yes, I’m validated. Here’s my module that I’m using, and here is the link to the NIST website that shows that has my product name on it, the module name, operating environments and systems where it’s been tested,” that really is the gold standard. That really ends all conversations to say, ”Yes, you are using cryptography that’s FIPS 140 validated.” So it’s actually pretty important distinction.

Cole French:

Got you. Yeah, it makes perfect sense. Just to be clear, you can be FIPS 140-2 compliant. You can be declared compliant before that compliance being validated.

Evgeny Gervis:

Yes, that’s right. So, if you do use a module that is FIPS 140 validated, that has active validation, even if you don’t have your own certification, you can claim compliance. Your argument becomes stronger when you actually have your own certification in your name for that module.

Cole French:

Got you. Okay. So, explain that process a little bit. How do you take a FIPS validated module and get your own certification?

Evgeny Gervis:

The traditional path to achieve FIPS 140 validation is quite a long one. The traditional approach is really you have to first of all, most likely hire a FIPS consultant, because FIPS is a very specific, rigorous standard. Most organizations don’t have a lot of in-house expertise to really fully understand. So, they would hire a FIPS specialist and then they would help them design their module, implement the module, and also provide or create a lot of documentation that really shows how you are meeting the standard. So, that can take a while. That’s a particularly involved process, because one of the things you want to make sure is that when you are defining the cryptographic boundary around the module that it’s very tightly defined around cryptographic functions.

Because if you define that boundary a little bit too widely, the module can become very, very difficult to maintain. So, there’s a lot of considerations like that into actually designing the module. So, that will take some time and some expertise, obviously some money as well. Then what you would do is you would go work with the lab. So, there’s about 12 labs or so across the U.S. and Canada that have been essentially blessed by NIST, certified to do this type of testing. So, there you’re likely looking at four to six months, maybe longer depending on the quality of your submission to actually go through what you’ve submitted. So, the lab can actually test it to make sure that it meets all the requirements. After that, it has to go to actually NIST CMVP. So, NIST actually has to do their own review.

Right now, if you’re looking at going to NIST, you’re probably looking at least two years before you’re going to be able to come out with a validated module, because there is a queue. It takes a lot of expertise to review, right? There is a line, and then it depends on how good your submission is. If you’re not crossing all the T’s and dotting all the I’s, it may be coming back. Ultimately, you’re not guaranteed success in that process.

Cole French:

Correct.

Evgeny Gervis:

So then you go and you get that certification and you want to celebrate, because okay, well, it says I have a certificate that’s good for five years. The reality, unfortunately, that’s probably not going to be good for five years, because what’s happening is the bad guys are not standing still. The crypto analytic techniques are continuing to improve. As the result, NIST has to continue to evolve the standard, the FIPS standard to make sure that it stays up to date with that. Certain algorithms become disallowed. Certain key sizes need to be increased, padding schemes change and so forth. It’s actually constant work actually to be able to keep your module in good standing. If you don’t, about every six months on average, there’s a thing called a transition with FIPS.

That basically means that if you haven’t done the necessary to keep your module updated, it’ll go historical. So, it’ll go from active to the historical status. Historical status is not a great place to be, because what it really says is you used to comply with the requirements, but you don’t anymore. So, the traditional approach is very painful. At SafeLogic, 10 years ago, we revolutionized how this approach works. We used to be those consultants that would help companies to go through this process through the labs and then go through NIST. It would take a year and a half, two years. It’ll be a really long process, but then we realized, look, we’re doing the same things over and over again. So, the big idea at the time was look, why not have a library of modules, which we call CryptoComply, and they already have been validated by NIST. So, our libraries are essentially drop-in replacement for popular open source, whatever people may want to use. So, it’s easy to integrate. Once you integrate one of our modules, you’re immediately FIPS 140 compliant and you can point to our own certificate to prove that. But we take it a step further. We have this process called RapidCert, which we can actually get somebody their own certification in about eight weeks, and that actually makes them validated.

So, think about this process that used to take two years, a lot of expertise working with consultants, with labs, with NIST. In eight weeks, we can actually take somebody from zero to being FIPS 140 validated. So, not only they have FIPS 140 validated modules, they’re using their environment. They’re easy to use. They actually have their own certification on the NIST website that’s active, that lists their product, lists their operating environments, all of that. Then the third pillar of what we do is called maintain search. So, as we talked about with all the transitions that are happening, every six months or so, we’ll not only maintain the software, but we’ll actually maintain the certification and keep it active.

So, when NIST has the new requirements with FIPS, we’ll make sure that our modules are continuing to adhere to that, provide our customers with updates. If their certification needs to be updated, we’ll do it on their behalf. So, it’s a white glove they don’t have to worry about. So, this is the approach that we take, but there are different approaches to this, but it’s a complicated topic for sure.

Cole French:

Yeah, for sure. Just to piggyback off of that, from a compliance perspective, there’s a lot of confusion around these terms, which is why I wanted to discuss them with you, particularly the compliant and validated, right? We talk to a lot of customers and they’re like, “Well, my encryption’s running and it’s FIPS compliant.” We have to remind them, yeah, I mean, that’s fine. It can be FIPS compliant and probably is FIPS compliant, but from a compliance perspective, it needs to be FIPS validated. As you just eloquently described, there’s a lot more to it. There’s a lot more to the validation than there is to it just being FIPS compliant.

Even more to what you were saying, a lot of times we run into customers. They’re struggling because a particular product they’re using was leveraging FIPS 140-2 compliant and validated algorithms and now they’ve updated their product or this particular organization isn’t able to update to the updated version of this product. So, they’re stuck in this middle ground where they’re technically not compliant, but it’s also out of their control, because they’re not able to upgrade to the version that the-

Evgeny Gervis:

Absolutely.

Cole French:

... vendor is actually pushing out.

Evgeny Gervis:

From that point, we actually see this all the time. Some people come to us sometimes and panic because they might’ve gotten a cure notice from DOD or something. Yes, they used to be compliant and they were relying, let’s say, maybe on something that came with their operating system or some other open source package that for some reason became historical, because ultimately, that operating system vendor or the open source project, they didn’t really have any contractual obligation to that customer to really make sure they survive all the transitions and do what’s necessary in a timely manner. So, that can be a big problem. So, with us, when they work with us, it is something we basically do for them. It’s maintaining that whole thing. It’s built into the service.

Cole French:

I know we’ve talked about, I guess, one of the biggest challenges is just maintaining compliance, but what are some other challenges you see with the FIPS 140-2 standard? That could be anything, right? That could be an implementation perspective, that could be maintenance. I think really from our perspective, it’s where organizations get tripped up with implementing FIPS 140-2. So, if you could just talk a little bit about some of those particularly challenging areas aside from just maintaining compliance.

Evgeny Gervis:

Yeah, no, absolutely. Well, right now and I’m sure we’ll talk about this a little bit later, but there is this big push to transition to FIPS 140-3, right, the new version of the standards. FIPS standard has been around for over 20 years. 140-2 has been around for quite some time, but now we as an industry are moving to -3. So, right now, if you wanted to get a new validation and you, let’s say, which we’re just talking about, wanted to go through that whole long two-year process, which I don’t know why you would want to do that, but if you wanted to do that, you can’t actually now submit for 140-2. You would have to go to 140-3, right?

Cole French:

That’s closed.

Evgeny Gervis:

So 140-2, you can maintain it, but no longer can do brand new from scratch validation. So, right now, for organizations that are looking at that, it’s like, “How do we get to that next version?” So that is certainly a big lift. If you think about 140-3, it’s even more encompassing than 140-2, because it’s not just about the module itself and all the requirements for implementing, but you also have to meet a lot of other requirements such as around your software environment, your secure software development practices. There’s a lot of things that go, because NIST now wants to make sure it’s not just the software product, but it’s also the process that was used to create it.

So, this is, again, a complicated topic. A lot of the time people begin to look at it, and they’re not necessarily cryptography experts. They’re not necessarily cryptography geeks. So, they’re not necessarily thinking about this all the time. So, the first question is often to figure out, where do I even use cryptography today?

Cole French:

Exactly.

Evgeny Gervis:

Where do we actually have the cryptographic control? So sometimes we have early conversations with customers who are trying to be proactive and trying to get a handle on this problem. The first thing is really to take a look at the architecture to figure out where are all the places, and the answer is usually everywhere. It’s data in transit, it’s data at rest. What makes it particularly difficult is that encryption is going to be used across a variety of architectures and variety of platforms. So, you may have mobile devices. So, you might have a very secure cloud environment and internally maybe you’re using something that came with AWS or Azure, but then it has to talk to the different devices at the edge. So, you have your mobile devices, you have your iPhones. Okay, how are you securing that TLS connection? Because that also has to be FIPS 140 validate encryption, or you have some embedded use cases, or you have again all the different places where encryption has to work. Then you may have different operating systems, and you probably have different programming languages. So, here you have Java, here I have C++ here I have Go, here I have Python. You got to have encryption that interoperable works across these environments. That can be tough, because you may have a module, but it may not work across all these environments, but you do need to cover your whole infrastructure.

Cole French:

Exactly.

Evgeny Gervis:

You need to get that going in the first place and then how to maintain it with all of those things changes, operating systems changes. Vulnerabilities get announced all the time, because again, the bad guys are not standing still. So, you need to have a method to update all this stuff, because like we mentioned before, there’s a cryptographic boundary. If you ever touch your code inside the boundary after it’s been validated by labs and NIST, guess what? It has to go through the validation again. So, anything that you touch inside-

Cole French:

So, any updates.

Evgeny Gervis:

Any updates. So, you really have to think about this. So, what we’re finding a lot of our customers are pretty major technology vendors, folks you would know, certainly have the capability if they really wanted to go and build up a practice to do this on their own. They decide they don’t want to do. It’s just not worth the headache. It falls in the category of do what you do best and outsource the rest.

Cole French:

Exactly.

Evgeny Gervis:

Few people really want to be those cryptography geeks and live in this world continuously because it’s really a nonstop effort. So, there’s a myriad of challenges for sure.

Cole French:

Yeah, that’s one thing I want to point out on that is what you mentioned with you could have eight different programming languages and all iPhones and mobile devices and all the different devices and the configurations require different types of encryption. I think from a compliance perspective, it’s really important. Setting aside FIPS 140-2 for a minute, any compliance standard is understanding where is encryption required and what kind of encryption is required. So, from a CMMC perspective, for instance, what we tell customers is, “Look, FIPS 140-2, think of that as anything in my environment in this secure enclave or environment or if I’m looking at my entire organization, anytime information may leave my organization, it needs to be FIPS 140-2 validated”, right?

Evgeny Gervis:

Correct.

Cole French:

So VPN connections, mobile devices, anything like that, anything where data could be traversing outside of that controlled boundary. Same with information at rest. I have USB storage devices. They need to be FIPS 140-2, because somebody could pick it up, take it outside the office, drop it somewhere, whatever, but things that are inside my environment and are going to stay inside my environment, encryption obviously needs to be a key component.

But that FIPS 140-2, from a compliance perspective, there’s a little bit more wiggle room and you can leverage different encryption techniques and things like that based on the technologies that you’re using. One other thing I wanted to come back to, so the FIPS 140-2, so it’s a validated module. So, what you’re saying with FIPS 140-3 is it’s not just the module, but it’s also the processes and all of the extraneous that went into building that module, that’s also a part of that validation.

Evgeny Gervis:

Yeah, absolutely right. I mean, at the end of the day, what will get validated is the module, but as part of the process, you need to really document and explain how you develop the module and what does your environment look like. You have to really go through all of that. There’s a lot of push right now, not just from NIST, but in general, you’ve probably seen some things from the executive branch. So, the secure software attestations that in general, the intent is really to hold software producers more responsible for the software that they produce. Part of that is you don’t get secure software by accident. Secure software is a byproduct of secure self-development life cycle.

So, NIST is really taking some of the same principles and applying it as part of the FIPS 140-3 standards to say, “Show me how you actually are developing the software and what are all the controls that you have in place.” So it’s all part of the evidence package that you have to produce as part of the process. It’s a pretty rigorous process. So far, there’s only been a handful of FIPS 140-3 modules that actually have come out. Like we mentioned, there’s a long queue. Part of it is it does take a lot of human review and there’s only so many people available.

Cole French:

Sure, sure.

Evgeny Gervis:

Part of it is, well, there’s just a lot of modules to get through and the standard is still somewhat new, so it’s still working out the kinks. How are you going to test for all that just internally within NIST and CMVP? But the other part, if you listen to NIST, part of the problem is a lot of the submission they’re getting, they don’t believe are adhering to all the requirements and those requirements, again, they’re more extensive. So, all of this is, I would say, really not for the faint of heart. So, if in your organization, you’re like, “Well, I’m going to go and get my own module validated from scratch”, I would say you really should have a good reason why you’re going to do that.

Cole French:

Yeah, for sure. I mean it’s interesting. I mean, we’re seeing that movement across a lot of compliance frameworks from check the box, which sounds like FIPS 140-2 is a little bit more in that vein of really just focused on the encryption modules, whereas now we’re moving into it isn’t just about do you do this thing, but it’s about “Is it a part of your organizational maturity?”

Evgeny Gervis:

Absolutely. Absolutely.

Cole French:

Yeah. To your point, I don’t see why any organization would want to go do that on their own or add that on to whatever their actual business is. That would be very difficult, because not only now do you have to implement the technology, but you have to build a whole process around it. So, one other thing I wanted to circle back on is and something that we run into a lot when we’re working with customers, particularly when building out a boundary, what we’re going to assess.

Evgeny Gervis:

Correct.

Cole French:

I think you even mentioned this, identifying all the encryption that is in my environment. So, just talk us through what does it look like from your perspective? How does an organization go about figuring out what are all the encryption methods I’m using? Where am I using them? If you could just talk to that a little bit.

Evgeny Gervis:

Well, it is not a trivial problem for sure and we’re probably going to get to this topic later on, but right now, it’s actually coming up in the context of quantum resistant encryption. Obviously, you’ve heard about quantum computers.

Cole French:

Sure.

Evgeny Gervis:

The expectation is that they will be able to break a lot of the public key algorithm as we have today. So, the government and NIST is urging folks to really prepare for that and to migrate. SafeLogic, we’ve actually been collaborating with NIST and really working on this problem, because we’re a cryptographic software company. The quantum computers is a huge revolution in our space.

Cole French:

Absolutely.

Evgeny Gervis:

So we got to be ready, but the reason I bring it up now, part of that migration is going to be a huge migration, but the first step is really figuring out, “Where am I using cryptography today and what is it and is it vulnerable in this example to the threat from quantum computers?” So there’s a whole category now of cryptographic asset discovery tools that people can use to discover what their infrastructure is. I think a lot of folks would be surprised. All the places use cryptography.

Cole French:

It’s probably like software.

Evgeny Gervis:

You run those tools, maybe like thousands of instances. Oh, I have that, but that’s really step one to figure out is what you got. Sometimes companies come to us and this question of boundary to your point comes up. Where I think we can help them put their minds at ease a little bit is that in the context of FIPS 140, the boundary is really not around their whole solution. That’s why it’s so important to properly define the boundary, but really the boundary should be around cryptographic module itself. So, that when they say they work with us, they get the module from us. As long as they use that module in accordance with the security policy that it comes with, they’re using FIPS for a validated encryption. Obviously, they have to use it in their environment for data storage and transit and so forth, but the boundary is really around that module. It’s our job and our case to make sure that we keep it all validated for them. So, the worst thing you can have is have your cryptographic boundary be around your whole solution, because that means, again, any change you make within your solution whatsoever is going to require a validation that is just not possible. It’s just not practical in any shape or form. So, that’s why we tell people, if you’re going to attempt to do this whole thing by yourself, do your own module, make sure you’re very careful about the boundary. But in terms of FIPS 140, the boundary really should just be around the module itself.

Obviously, for regimens like FedRAMP, CMMC, others, assessors like yourself, they look at the broader. The boundary is broader for different controls, but it’s important for cryptographic purposes to keep the boundary very tight.

Cole French:

That makes perfect sense.

Evgeny Gervis:

That just makes it maintainable and will really make their life easier going forward.

Cole French:

So yeah, you did. You mentioned the quantum computing. That is an interesting topic. I’ve seen some articles actually just in the last week or two about people accelerating, I guess, if you will, their predictions on when we’re going to see quantum computing. So, just talk a little bit about, “What are you guys doing from a cryptographic encryption perspective when it relates to quantum computing and what’s the future look like there?”

Evgeny Gervis:

Yeah, absolutely. Look, nobody really knows for sure when we’ll have what’s called the first quantum cryptographic relevant computer, meaning powerful enough to actually be able to break algorithms like RSA. We don’t know. It’s not like sometimes people compare it to like there’s obviously Y2K problem, but you knew exactly when the year 2000 was going to happen.

Cole French:

Exactly.

Evgeny Gervis:

Here, people call Y2Q. It’s like how much time we have to that quantum cryptographic relevant computer, but we don’t know for many reasons. One is there’s a lot of physics problems that have to be solved, a lot of computational problem. It’s a hard problem, but the other thing is it is likely it’s going to be a nation state, right?

Cole French:

Yeah, because of the resources.

Evgeny Gervis:

Because of the resource required, but it’s not like they’re necessarily going to tell you about it. I mean, think about breaking of the enigma, World War II, what the British were doing... That was the biggest health secret, because that was such a powerful thing. If people knew that you had it, the Germans would’ve switched to something else. So, the thing is we don’t know. What we do know is that the migration will take decades, will take a very long time. If we look at the history, even migrating from a SHA-1 to SHA-256 or 512, that took a lot of effort and a lot of time. Migration from all the places where you use PKI today, right, so to quantum resistant equivalence is going to take a very long time. You’ve got to figure out where you use it, and you’ve got to update your infrastructure.

It’s got to work with all the protocols. I mean, it’s going to be a big thing. So, the point is the best time to start is now. And there’s also now a class of attacks called capture now, decrypt later. So, the idea is some data has to be protected for a very long time. Think health records that are subject to HIPAA or financial records. As a matter of fact, healthcare companies and financial institutions are leading the way thinking about how we protect all this data because somebody captures it now. Maybe they can’t decrypt it yet.

Cole French:

But it’s going to stay like that for a long time.

Evgeny Gervis:

But it’s going to stay like that. If it’s still sensitive-

Cole French:

So you just sit there and work on it.

Evgeny Gervis:

Yeah. If it’s still sensitive, when the quantum computers become powerful enough, it becomes a problem. So, NIST has really been leading the way on that. I mean, obviously, for a few years now, NIST has been running the competition for quantum resistant algorithms. Those are algorithms that are fundamentally based on different types of math problems. So, a lot of the PKI these days is really based on difficulty that classical computers have at factoring-

Cole French:

Factoring.

Evgeny Gervis:

... large numbers.

Cole French:

Reverse factoring.

Evgeny Gervis:

It turns out that that is not going to be such a difficult problem for quantum computers. So, we need different types of mathematics. So, there’s algorithms now based on things like lattices and so forth to really hopefully make it more difficult. Now, I say hopefully is because a lot of these things are still not mathematically provably secure necessarily. It’s really a matter of how many smart people looked at it over time, and were they able to break it? Now, that obviously provides some assurance, but just a little more than a year ago, one of the finalists that went through one of the later rounds in this competition for post-quantum cryptography a couple of weeks later got broken pretty badly.

They did not get broken by quantum computer or even a super computer. They got broken by a 10-year-old laptop. So, that tells you, one, you’ve got to prepare, but two, you’ve got to bake in this thing called crypto agility. It’s a big term in the industry right now, such that if you adopt an algorithm and you’re going to spend a lot of time migrating from say, RSA to something else, if that thing has a weakness in it and it gets discovered, you don’t want to have to spend the same amount of time and money to do the migration. So, crypto agility is ability to essentially be agile with your cryptographic algorithms. So, you have a layer of abstraction.

So, we’ve been working closely with NIST with a lot of other companies on this problem of how do you really help organizations think about migration to cryptographic, to PQC algorithms. There’s actually a couple of publications just in December that NIST has released. I encourage you and you listeners to take a look, a lot of great work that NIST has done. At SafeLogic, we’re actively working in our own implementation of quantum-resistant algorithms. We’re actually planning to make some early access program available to our customers where they can try that alongside of our FIPS 140 validated classical algorithm implementation.

They can do hybrid use cases, hybrid meaning that one of the defense in depth ideas is that you use your classical algorithm combined with quantum resistant algorithm such that if one becomes broken, hopefully, you still have another. But it’s going to take a lot of time and planning. So, we want to make something available for people to start experimenting now. When it becomes possible to actually get quantum resistant algorithms FIPS 140 validated, it’s not possible yet, because first, algorithm standards have to become finalized. Then NIST has to develop their own testing procedures, maybe later this year, maybe next year, but we’re actively looking at how we get those also validated.

So, that we can offer both classical and quantum resistant cryptography all within the context of FIPS 140 validated module. Because ultimately, the government is saying, “Go and think about how you’re going to adapt quantum resistant algorithms”, but they’re also saying, “We expect you to have FIPS 140 validated cryptography.” So if you put those things together, you’re going to see, “Well, you really need to have both of those in place.”

Cole French:

You need to have both. Yeah, for sure. So, I was curious from a quantum perspective, I guess, like you said, quantum computing is still theoretical, I guess you could say. So, quantum resistant encryption is still I would think that until we actually have real life quantum computing, it’s still theoretical coming up with quantum resistant encryption algorithms. Would that be fair to say that it’s still very much in development because of that? Because we don’t actually have quantum computing?

Evgeny Gervis:

Absolutely. Well, certainly because we still don’t have a cryptographically relevant quantum computer, we don’t have a test bed.

Cole French:

Exactly. Yeah. So, this is an interesting problem.

Evgeny Gervis:

So we’re testing that stuff still in classical computers. So, yeah, to your point, we have a lot of smart people. I’ve been thinking about this for years and working on this for years. Time will still show. Time will show how it actually develops, and that’s why when we talk to customers about that journey, the crypto agility and hybrid is definitely big discussion points. The other thing is really you need to have solutions that are going to be interoperable across the environment, because like we mentioned, cryptography is everywhere.

So, you’re going to need to make sure that it all works across different devices, different platforms. It’s one thing to get the cryptographic primitives right, but then all the protocol people like TLS and all those folks have to then roll it into all the protocols and make sure that both sides of the communication can speak the same language. Otherwise, you’re not really going to be communicating much.

Cole French:

Exactly.

Evgeny Gervis:

That’s not going to be useful. So, yeah, there’s definitely a lot of challenges for sure.

Cole French:

Yeah. So, as we wrap up this conversation, I just wanted to get your thoughts in the compliance arena. As we talked about at the beginning of this conversation, FIPS is a frustrating thing from a compliance perspective, both for organizations seeking compliance, but also for us as assessors. It’s just challenging. Like we’ve talked about, all the stuff we’ve talked about, you can see why this is a challenging topic and there are opinions out there. I was curious what you thought about this. There’s definitely opinions out there that by forcing everyone to this FIPS 140 standard, we’re not really emphasizing security. We’re emphasizing process and standardization over security. Actually, there’s better, more secure algorithms, encryption, methodologies, et cetera, et cetera. So, I was just curious, what are your thoughts on keeping the FIPS 140 standard? Are there better ways to do encryption outside of what FIPS is requiring, all that stuff, or do you think really FIPS puts us all in solid footing?

Evgeny Gervis:

I think FIPS is an extremely important standard. Cryptography is one of those areas where you really don’t want to be reinventing the wheel. You really don’t want to do that because it’s so easy to get something wrong, just a small little thing, a small little issue with how you manage memory. There’s problems. Even people who do this for a living and do this all the time, mistakes still happen and there are issues. So, I would say that without a standard and without a rigorous process to validate and as far as I know, I think if you look at just cybersecurity in general, I don’t know that there’s anything analogous to the rigor that goes into reviewing cryptographic modules with FIPS, with anything else.

I mean, this is a very rigorous process, but I think there’s a good reason for that, because cryptography is so fundamental. We often talk about really there is no such thing as digital privacy or trust without working cryptographic controls. I don’t think I’m overstating it. I think that really is the case, because cryptography, think about it like plumbing. It’s like the pipes in your house. Yeah, you want those pipes to be up to code, right? So it is important.

Now, what I think is also true, I think there are probably and I’m sure NIST would agree with that, there are probably opportunities to streamline the process of validation and especially maintenance. Because one the places where this friction between compliance and security comes is with updates and especially with updates that have to do with security vulnerabilities. For instance, when there is security vulnerability that gets discovered and no software is immune to have one.

Cole French:

Absolutely.

Evgeny Gervis:

You really don’t want to have any disincentives to the process of updating the piece of software.

Cole French:

Yup.

Evgeny Gervis:

Right?

Cole French:

That’s good.

Evgeny Gervis:

If that fix happens to be inside the boundary, well, right now, technically, the module is not valid anymore. If you made any changes, you can go through the process to revalidate, but the process will take a long time. So, there may be something that can be adopted there to streamline, because in the end of the day, my view is you always got to think about it from a risk management perspective. In ideal cases, compliance should really be a by-product of good risk management. So, that would be the ideal situation. Certainly, a situation where you have any friction between the two, that’s not great, but to me, that doesn’t mean that you should abolish the standard. Standard is very important. The code is very important. It keeps all of us more secure.

As a matter of fact, we’re seeing more industries outside of even the public sector looking like healthcare with HIPAA and so forth, looking at FIPS as the standard, but the way that modules are validated and maintained, I think there’s probably some room for improvement to reduce some of that friction.

Cole French:

Yeah, no, that makes total sense. I think it’s the classic security and basically every other function of an organization. There’s always some level of friction that comes with that, and our goal is to try to reduce as much of that friction as possible. Well, again, thank you again for taking the time to join us on the Cyber Compliance and Beyond Podcast today. Grateful for your perspective and contribution to this important topic. If people want to get in touch with you, what’s the best way to do so?

Evgeny Gervis:

They could just email evgeny@safelogic.com, E-V-G-E-N-Y@safelogic.com. Happy to hear from anybody who wants to reach out.

Cole French:

All right, great. Thanks again. Appreciate it.

Evgeny Gervis:

Cole, thank you so much. Appreciate it.

Cole French:

Absolutely. Thank you to all of you out there for joining us for today’s episode. The Cyber Compliance and Beyond Podcast is dedicated to answering as many unanswered questions as we can. If you have a question you’d like answered or you’d like to offer some feedback, we’d love to hear from you. You can find us on Twitter and LinkedIn, @KratosDefense, or you can shoot us an email at ccbeyond@kratosdefense.com. Be sure to check out the show notes for additional material related to today’s episode. We hope you’ll join us again for our next episode. Until then, keep building security into the fabric of what you do.