Defending Enterprise Data Against Quantum Encryption Attacks

Matthew Rosenquist and Michael Fasulo discuss how quantum computers will break today's encryption through "harvest-now-decrypt-later" attacks, where adversaries collect encrypted data now to decrypt it later. Organizations need crypto-agile systems and NIST's new post-quantum algorithms like Kyber, starting immediately with data inventory and re-encryption.
Chapters
Welcome to Cybersecurity Insights. I'm your host, Matthew Rosenquist, CISO, industry cybersecurity strategist and advisor. And today we're going to talk about upgrading enterprise data backup and recovery ecosystems to post-quantum cryptography standards. And I'm going to be talking with Michael Fasulo. Michael is the senior director of portfolio marketing at Commvault. Which recently announced a move to enable customers to transition to post-quantum algorithms. And such a transition is, well, it's absolutely needed across the industry, especially when it comes to protecting sensitive data from emerging risks that quantum computing brings. It is an inevitability as quantum computers gain in power and will eventually be able to undermine much of the encryption the world uses today. Welcome, Michael. Thank you for coming and sharing this journey.
Thanks for having me. And I'm gonna steal some of that talk track. I like the way you put it.
Go for it, go for it.
Awesome.
I mean, quantum is so, there's so much to talk about quantum, whether it's the hardware, whether it's the algorithms or the, oh, it's such a great topic. Yes. And we know that cliff is coming. So, you know, I alluded to it a little bit, but can you explain exactly what post-quantum cryptography is and why it's needed by organizations that specifically want to protect their sensitive information?
Yeah, sure thing. So PQC is really these cryptographic algorithms that are designed to secure against both classical and quantum machines. So they'll encapsulate both. Because classical compute threats don't go away. And, you know, these quantum machines do pose a significant threat, as you mentioned. So as these quantum machines and their associated algorithms become very efficient at processing large numbers and log mathematics, this is really where asymmetric cryptography falls short. So a lot of times you'll hear a harvest now, decrypt later as kind of the main threat that people are talking about. And this is really where threat actors will exfiltrate the data today. And hopefully they won't be able to, but in the future when these quantum machines and these algorithms get to a point where they'll be able to decrypt the data and then obviously hold the data for ransom. So for me, for us, like we talk to a lot of our customers where long-term, highly sensitive data has a really long shelf life, you know, these are the types of scenarios that we want to protect our customers from. And that's why we decided to provide PQC as part of our platform.
Got it. And you had mentioned asymmetric encryption, and yeah, I don't want to get too geeky here between symmetric and asymmetric, but can you kind of give an example of asymmetric encryption and what we use it for? Right? Some examples.
Yeah. So asymmetric encryption, and I'll, I'll probably provide a, a higher level, not to get like super in the weeds, but asymmetric encryption is usually where is usually used on the network to establish, you know, when you have a private and a key pair. So understanding that if you have an encrypted tunnel and that encrypted tunnel can be broken, then even if we're passing like symmetric keys like AES and encrypted data, if you can steal enough where you got the key, then you can decrypt something that even has, that's quantum resistant like AES. So, You know, super important that we protect asymmetric encryption from these types of threats because it would then expose the capabilities of exploiting, you know, the symmetric key exchange.
Got it. Got it. Now, NIST, the National Institute of Science and Technology, it's been working with the cryptology industry since, what, 2016? Really to identify those replacement algorithms that, well, all modern technology, right? The solutions they're really going to need. And I know they've got 5 so far. That number grew from, you know, originally just 4, 2, and 2 backups to now 5. How will systems and users determine if they need these new algorithms and then which ones to implement out of the 5? It seems very confusing. Yeah.
Yeah, totally. So you're exactly right. And you know, when we first started doing our research, we took the leap to be, to provide crypto agility, right? That's the ability for us to be able to provide these different algorithms for these different threats depending on, you know, how even the scenarios are gonna evolve. So having that flexibility provides our customers, you know, a lot of comfort in knowing that not only threats of today, but threats of tomorrow, we could have some type of resistance against them. And I would say this unpredictability is putting a lot of vendors on their toes to make sure that they can deliver their products. And, you know, we encourage our customers to be vigilant and prepared for this space that's gonna continue to evolve. So getting back to the comment about, you know, NIST going back 2016, they really consulted with the top minds in cryptography at the time to come up with these better ways to prevent these types of threats from happening. So there's a lot of gravity to that scenario. But what I would say is these new algorithms, as they're created, it's really important to vendors to be able to provide them to their customers. And if for some reason, you know, these mathematical calculations can be cracked, there needs to have backups So you mentioned the fifth algorithm for an example, HQC. I'm not gonna try to say its name because it's really complicated and it's a tongue twister and I always mess it up. But HQC was really the backup that was created, uh, that NIST is recommending, uh, to provide a backup to a KEM or Kyber. And why that's important is because it uses error correcting code mathematics instead of lattice-based mathematics. Yeah. So if someone happens to crack the lattice-based mathematics with quantum and quantum-based algorithms, then there's already a backup in place. So you can even see that NIST, even though, you know, think about the foreshadowing they did back in 2016, they're still doing that today and making sure that there's no single point of failure. So really, really crazy time that we're in. And, you know, there's a lot of current events that I think is really trying to accelerate how quantum machines are utilizing different technology so that, you know, they don't need supercooling. You know, the algorithms are improving, you know, their error correcting codes are becoming, you know, really efficient. So lots of things happening in the space. So that unpredictability, I think, is allowing people to react and be overly cautious. And that overly caution is actually a good thing.
Yeah. And I love what you mentioned, right? Crypto agility and the fact that back in 2016 when they reached out to the community, there were dozens of algorithms that were put forth. And through that time, many have been tested. And even some of the top ones that they were going to go to started showing some cracks. And so they did, you know, have forethought and say, okay, we're going to need backups. And even the ones, the 5 that they've approved now, we don't know around the corner, it may, you know, one of them may get cracked and having that agility to be able to adapt to that and then quickly swap that out and swap something in. I mean, that's in my mind, that's going to be paramount moving forward. We've always had to replace algorithms in the past, but typically there was enough time, people, you know, there was a transition about it, but it's a brave new world. It really is. So these new algorithms, they can be power hungry. I mean, they're important because they provide more precision. Protection, but they can also consume a lot more compute power. So, how do organizations then manage that trade-off between, "I want advanced security and protection for my most sensitive data, but at the same time, I don't want blistering overhead and cratering of my systems"? It seems like a scale that you have to manage. I mean, what are your thoughts in this space?
Yeah, so like you said, there's a balancing act that you're going to have to do. And we recommend our customers do like deep data discovery and classification of their data to not only gain awareness of the data and the silos that they have their data in, but also the sensitivity of it. And then apply these techniques and different encryption levels and things to just that subset of data. So for Commvault customers, we have a product called Risk Analysis, and that does data discovery and classification. We recommend our customers use that across all these different silos to really understand and apply these controls. And then obviously we have policies and automation and other things that make it really easy to adapt and adopt these technologies to protect that ultra-sensitive data and to keep an eye on these things. And one of the other cool things about Risk Analysis, which is kind of unique to it against the rest of our portfolio is that it functions not only on backed-up data but also live data. So you could do deep data discovery and classification, you know, relatively fast, but get a real good snapshot and then apply these controls as necessary.
So you're almost talking about a paradigm shift, right? Where it's not one size fits all. We're not just going to use this standard and all our data's going to be encrypted. What you're talking about is variances because of dealing with that trade-off, which means you're moving away from that manual set-it-and-forget-it. You need tools and policies and processes that are automated to then be able to manage that once you've determined, you know, this type of protection for this data but not this data, and this data flow needs to have a certain, you know, encryption protection. It sounds like it gets much more complex for organizations that haven't kind of thought it through or have the capabilities to manage this. Is that going to be a barrier for companies moving forward?
It depends if they want to take the hard way or the easy way. What I would say is, look, my father used to say this. He used to say, "Right tool, right job." So, you know, use that strategically. And if you think about, you know, encryption in general, I mean, modern compute is so fast that I think, and it's offload, the compute is offloaded to an extent. The amount of cycles it consumes is not that great. But when we talk about PQC, it's gonna be noticeable. And what that translates to, like if we're talking about cloud instances, is having to go to the next, to scale up to the next instance, that's actually double the price. So if you think about it, it's really important to responsibly think about where you're gonna apply these things. And these are the types of tools that we have in the product to kind of allow you to balance that. And then the other thing that we recommend besides really understanding the data is understanding where you're using encryption and the different key lengths and the different techniques that you're using. So we have another product called SecurityIQ that kind of gives you that bird's-eye view of where is encryption being applied, what are the keys, what are the techniques, key sizes, and all those things so that people can really get an understanding of how secure their data is, their pipelines are, and even how their compute and memory is being used because we also protect data in use security cases.
So you mentioned, you know, an ugly aspect of all this, right? The price, the cost. And, you know, if we accept that switching to stronger algorithms is the natural order of things, do you think vendors should charge customers for the upgrade to quantum-resistant algorithms? Absolutely not. Come on. Don't speak from a shareholder position, but from the customer position, because it sounds like there's already going to be more overhead that we have to manage, uh, more complexity we have to manage, right? We have to find the right tools and all that.
Yeah.
Should they be charged for this natural upgrade?
Yeah, so I, I would say absolutely not. And, you know, with Commvault, it's part of our platform security pledge, so, you know, our customers get it for free. But in general, it's like, who charges to encrypt data? Like, just having good data security or even network security is like super important. And everyone, I mean, with the proliferation of threats in today's landscape, it doesn't even make sense for vendors to charge for these types of things. So with Commvault, we don't charge for it. And I would advocate that, you know, vendors that are thinking about charging for PQC should think about, you know, really building PQC as a crypto agility framework in your product, reduce your burden for developing and an upkeeping PQC in the future and provide it to their customers free of charge.
I like the idea. My concern is there's going to be a lot of vendors that see that bag of money on the table and go, "No, it's a significant investment to go do this and to enable the customers, and it's a tremendous value. We should be upselling this, right? Here's an add-on." So, Anyway, I'll move on from that one because I'll just get frustrated. But, you know, the move to quantum-resistant algorithms, it does represent a significant shift in the underlying architecture. So, I mean, I can understand why service vendors are going to say, yes, we have to invest in this and this is going to cost it. But, you know, it is essential for data protection. When we look at that, and you mentioned crypto agility, when we look at this problem, not just being a problem and you apply a fix and you're done, but you have to maintain that agility moving forward. Is now the right time in understanding the chaos that we're now getting ourselves into to design in forward-looking capabilities to easily manage and update and integrate future algorithms and deprecate others into all of these tools. Is now our moment to do that in the tech industry?
Yeah, if there's one thing I learned at Commvault in my 2+ decades here is like timing is everything. And there's been stuff that we've built that, you know, was premature and we put it on the shelf. But this is not one of those scenarios. The time is now. And I think, people should start to gear up, take inventory of their data footprint, understand and make sure that they can see all of the data across, and then determine, you know, where they should apply PQC. I think that's a really important first step. The other thing that I think is super important in a topic like this is even early on when we used to have these conversations internally, there wasn't a lot of key stakeholders that really wanted to pursue these types of things. So it's really important to be a good internal advocate, you know, kind of cut through the hype, provide like the ground truth of the scenarios that we're in, where data is affected or it is not affected, and really have like executive buy-in on these types of things. Because although we talk about harvest now, decrypt later, there's other threat vectors. And I'm sure if you've been watching the news last couple weeks, people are talking about crypto and, all these other scenarios with certificate authorities. So, these are real threats and it's a looming threat and there's so much uncertainty on how fast this is gonna accelerate because not too many months ago people were saying this is 20 years out and now people have revised this to be the next 5 or 10 years. So, I think people are finally having the right conversations. But internally, whether you're a customer or a vendor, you should really be having these internal conversations have some executive buy-in, and then proceed with what is known. And we're all blessed that NIST is really giving us a lot of good guidance on where to apply these things, how we can get this into the product, and talking about crypto agility. So, you know, it's not everyone's discovering uncharted land. Some of these things are relatively well-defined, and people should be adapting and adopting to that. And, you know, I would say the other component to that is if quantum does hit a GenAI-like stride, people better be really careful on sleeping on this type of technology to protect themselves.
Yeah, I mean, we're moving towards a cliff and timing is everything. You want to get there before the attackers can decrypt all your data, undermine everything that you have, you know, and NIST has done a great job with the algorithms. But let me ask kind of a side question here, because I've worked with lots of companies and encryption in the hardware and firmware and OSs and apps. History has definitely shown that implementing encryption can be really easy. Oh, let me just slap something together. But implementing it securely can be really problematic. It can be extremely difficult. So, you know, from the perspective of people thinking, oh, I'm just gonna slap in some new libraries and I'm good to go. Right. What kind of advice would you give with your background and history in building this at Commvault? What are some of the challenges in doing it right?
Yeah, so I think first of all, like people need to be fixated on the customer experience. I know we haven't gotten into like super deep in this particular conversation, But like quantum is a pretty abstract thing to most people that are outside of this space, and even cryptography is. And then if you start to unpack like some of the mathematics and other things, like this is a super complicated thing. And the idea is that even if the implementation from a vendor standpoint is not complex, we shouldn't be passing that complexity to our customers. So implementing PQC and using some of the tactics that I've already mentioned really remove a lot of that friction and complication so customers don't have to worry about, am I using the lattice-based one? Am I using the error-correcting code one? How do I make sure? Like, the whole idea would be it should be checkbox simple, like we've implemented it, and then have a policy that gets applied that is rule-based so that as we use these tools to discover the data, to discover things that have high sensitivity or severity, it's really important that these policies allow to drive this automation so that our customers can set it and forget it. And not have to worry about all the complications that come with quantum. And then as we get new guidance from NIST, you know, as a vendor, we provide, you know, very smart defaults to our customers and we remove again that friction of having to upkeep and understand, do I pick X, Y, or Z? We always provide, you know, a best practice default. And then we do provide the optionality if someone wants to use one of the other ones for some specific use case. So super, super important that not only people think about it from a data protection standpoint, But as I mentioned before, there's other attack vectors that are going to be exposed in an environment. So it's, it's super critical that people take not only inventory of the data, like I'm saying from my standpoint, but also their key stores and all the other things that may be vulnerable. Because an environment, it's only going to be as strong as its weakest link. So super, super important to have that internal stakeholders to talk about these things so that not only do you admins, backup admins, infrastructure admins, but everybody else is contributing to really understanding how quantum threats may evolve and protecting them, you know, full sweep throughout the entire environment.
Well, you mentioned all those stakeholders, right? And unfortunately, especially the larger organizations, that matrix gets very complex, right? It's not just cybersecurity. It's not just IT. It's legal and it's all the different product groups and third-party vendors, and right, it starts getting extraordinarily complex. So how should these stakeholders partner together to make sure that all the necessary internally developed systems as well as third-party vendors are integrating quantum-resistant algorithms properly and in a timely manner? Any insights there?
Yeah, super important. And I think it really, it really becomes a question of be inquisitive and ask questions. I think that that part's super important. And one of the other things, and I was, I was on LinkedIn earlier today and I noticed you were having some dialogue, uh, on some subject matter, you know, aligned to cybersecurity. I think that level of transparency is ultra critical on a global stage. Having, you know, all this type of rich conversation, whether it's in LinkedIn or Substack or any of these other locations where you could have a one-to-many conversation with some level of transparency to say like, look, you may not be hearing this in the news, but these things are happening. And sure, like breaches are a shielded thing. You know, these types of threats are a shielded thing, but it downplays the severity and the frequency in which these things are happening. So I think as stakeholders, both internally and on the global stage, it's super important to have really transparent dialogue about these things. Talk about the frequency, talk about how catastrophes, how we could avoid these catastrophes, and then really have a good level set and cut through the hype so that people can really understand, yes, this is a threat that I should be concerned about, and here's what we need to do. Here are some of the vendors that are implementing this the right way, the quick way, so that I'm protected. Here are some examples of ones that may not be be doing it as good, but provide them with those good examples to provide some of that further guidance so you can remain protected is super paramount as far as I'm concerned.
Yeah, I agree. So in that kind of discussion, that communication, the most important aspect in this whole ambiguous discussion is one, you want to beat to the finish line the attackers. In getting your algorithms updated and implemented beforehand. So the question kind of comes back to, if I'm a product owner or if I'm an IT or somebody that owns the budget, when is it going to happen? So my last question to you, and I know it's a crystal ball, right? You got to pull that out. You got to make some guesses, but you're neck deep in this. You've talked about the attackers out there. You've referenced nation states that have billions of dollars that are thrown into this. That are developing their entire, their own quantum technologies, their own farms, right, to be able to do this at scale, that they've been harvesting data for over a decade, right, that they want to then decrypt later. Where does your crystal ball say that we need to have this in place? Not start thinking about it, not, oh no, let's get it done tomorrow, but You know, when do you think the world, the critical infrastructures out there really need to have this in place? What is your personal deadline for this?
Now. It's that simple. It's now.
Wow. That's a very short, concise answer. Okay. Yeah. Would you like to elaborate on why now?
And as you said, right, it's not, we're not worried about the script kiddies and the lone wolves., right? The, these, these quantum machines are not gonna be accessible to people like ourselves for nefarious reasons, right? Like, look, you can go get quantum hours in the hyperscalers or through IBM, like right now. Um, but obviously there's tons of safeguards and you'd have to know all these things. But in a couple years, you're gonna see these organized, uh, cybercriminal syndicates and nation-state actors like exploiting this. And the reason why that's so critical is because these orchestrated attacks are gonna be very purposeful and they're gonna be very damaging. And if you already know that you're in possession of like super long-term sensitive data that could do irreputable damage both financially to brand, to governments, uh, to weapon systems, like that stuff has to be protected today. It has to be, and it probably should have been before, sometime before. So like super, super critical that, you know, people start to do this now. And if you have older data that would also fall into this footprint, having a platform like ours that allows you to re-encrypt would also be very helpful, especially if it's going to be in infrastructure that could be exposed. And obviously usually sensitive data isn't, but You know, these are, again, these considerations that people should be taking. And, you know, it is also worth mentioning that PQC is a layer of your security posture. It doesn't replace anything. It's just another additional layer. So you still have to prevent breaches. You should still be looking at network traffic. You should still be looking at, you know, multifactor authorization, multi-person authorization for things like, All of those things should still be in place. This just becomes an additional layer for this particular attack vector of how we know it's going to function today. And if it changes tomorrow, this is why the crypto agility is super important. This is why it's still important to have all these additional layers.
So I think those are— it's just incredible insights. Michael is the senior director of portfolio marketing at Commvault. Check out what the brilliant people at Commvault have done to embrace post-quantum cryptography and empower their customers to easily benefit from the next generation of secure algorithms for data security. Michael, thank you for sharing your insights today.
Appreciate you having me. Appreciate the questions too. Awesome chat.
And thank you all for watching. And a big thanks to Commvault for sponsoring this episode. Be sure to subscribe and catch all the Cybersecurity Vault episodes where we chat with industry leaders to dive into the most relevant and interesting cybersecurity challenges. Perspectives, and best practices.
More from Matthew

The Future of Cybersecurity: How AI Is Exploiting Technical, Behavioral, and Process Vulnerabilities









