"Preparing for Cybersecurity Risks in the Post-Quantum Era," Davis Wright Tremaine Webinar
Quantum computing promises significant scientific and commercial advances, but it also threatens the cryptographic protections that secure modern digital activity, including encrypted communications, financial transactions, authentication, and digital signatures. The risk is not just future-facing: adversaries may already be collecting encrypted data today with the goal of decrypting it once sufficiently powerful quantum computers emerge.
In this webinar, panelists explain the basics of quantum computing, why cryptography is foundational to cybersecurity, and how quantum capabilities could compromise widely used encryption standards. They discuss the development of post-quantum cryptography (PQC), emerging standards, and government and industry efforts to transition to quantum-resistant algorithms. By the end of the webinar, attendees will understand practical steps organizations should consider now—including inventorying cryptographic assets, prioritizing high-risk systems and data, engaging vendors, and planning for migration—as well as key legal and regulatory considerations moving forward.
This webinar is the second installment in a two-part series co-hosted by DWT and FTI Consulting on emerging technologies and cyber threats. Part one of the series examined how AI-driven vulnerability discovery is reshaping the threat landscape.
Speakers:
- Michael Borgia, Partner, Davis Wright Tremaine
- Ankur Sheth, Sr. Managing Director, FTI Consulting
- Greg Berkin, Senior Advisor, FTI Consulting
Click to download presentation slides.
(On-demand versions are not eligible for CLE credit.)
Webinar Transcript
The following transcript was created using AI-assisted speech recognition and formatted for publication. Readers should be aware that automated transcription may not capture every statement with complete accuracy.
Michael Borgia: Welcome, everyone. This is a webinar we've been excited about for a long time. We're going to be talking about preparing for cybersecurity risks in the post-quantum era. Jointly hosted by DWT and FTI, this is a second part of our webinar series. We did the first part over the summer on AI and vulnerability discovery, and here we're talking about another emerging, foundational cybersecurity issue, which is quantum computing.
My name is Mike Borgia. I'm a partner here at Davis Wright Tremaine. I lead our information security practice.
We do all the things that you think that might entail: incident response, incident preparedness, compliance, and, most relevant today, compliance and strategy, helping companies think through how to comply with government contracting regulations. How to think about what reasonable security is, how to deal with supply chain and vendor types of issues, all of that stuff we're gonna hit on today.
It's gonna be really interesting.
Ankur Sheth: Great, thanks, Mike. Good afternoon, everybody, or good morning, wherever you are. My name's Ankur Sheth, I'm a Senior Managing Director here at FTI Consulting. I lead, as part of our global cyber practice, our Cyber Risk and Resilience Advisory Team. So really, all the upfront work that we do with our clients, thinking about how do we help them build, secure, and plan, you know, their cyber programs, not so much on the crisis and the responsive side, but really more upfront planning and preparation.
And as part of that, quantum, of course, AI kind of falls into the realm of my team, so we're gonna be talking about that today, and how that intersects with cybersecurity. Greg?
Greg Berkin: Yeah, hi, I'm Greg Berkin. I'm a Senior Cybersecurity Advisor for Quantum and AI at FTI Consulting. I work with Ankur and a team, working on cybersecurity, ransomware intrusions, spyware, cryptocurrency, the whole gamut of cybersecurity issues, but my current role is also a fellow at Stanford, focused on quantum computing, technology, and startups to move quantum forward.
I'm happy to meet everyone.
Michael Borgia: Great, and a quick housekeeping note, we do have a Q&A. You can put questions in there. We will address some as we go if we can. We'll do others at the end if we can. If we can't, we'll follow up with you, as best we can, unless you submit them anonymously. The first question was about other types of credits.
Unfortunately, this is only for continuing legal education credit. We don't have other credits available right now. Okay, so, we're jumping into our overview of our session. Quick overview.
We're gonna talk a bit about… there's a gamut of people on this call that joined today, some very technical, some lawyers, some, you know, all different levels of technical proficiency, so we're going to talk about what is quantum computing, what are the opportunities and the cyber risks, what is it a risk to, why is it, why does it create a risk?
Try to do that at a very general level that everyone can understand, and come away with some understanding of this. Two, we'll talk about legal frameworks, Both for government contractors in the U.S. in particular, and more broadly, for everybody. Are you required to do this? Under what theories? What's the… what are the risks?
We're going to talk then about FTI's readiness domains, the way our FTI colleagues here will think about, ways that you should conceptualize how to get ready for quantum, and different categories of that. We'll focus on several in particular that we think are kind of relevant, particularly relevant for everyone.
And then, for practical responses, we'll go through some checklists that we have, some thoughts about what can you, from different perspectives, if you're a CISO or an InfoSec, if you're in-house counsel, if you're GRC, what can you do, what can your org do right now in a practical way to start preparing for this? Okay, so, to get into our actual substance, I will first kick it over to Greg to give us an overview and background about what is crypto, what is quantum computing, how does it affect cryptography, etc., so…
Please, Greg, take it away.
Greg Berkin: Thanks, Mike. Yeah, so quantum is pretty much the hottest topic today, and quantum computing comes from quantum mechanics, quantum physics, and it's applied that to information technology to be able to look into how to process data, decisions, and many other areas. Quantum's actually a very, very broad, category, but We care about it today because of the quantum risks for security.
It's the underpinning of our cryptography that keeps us safe and secure. Every transaction we communicate through is based on cryptography. And the current public key cryptography is potentially vulnerable to a quantum attack.
And the way that quantum has evolved, we're more and more concerned about these vulnerabilities undermining our networks and our transactions, and everyone is concerned about asymmetric encryption. Which is the basis of our current system today, like RSA and ECC, elliptic curve cryptography. Those are vulnerable to a quantum attack, and the question is how quickly that is evolving, and what do we need to fortify our network so that we're not exposed and, you know, under threat.
You've seen recent headlines like these for cryptographic keys that have been stolen in, SSH connections, and 248-bit RSA has been, known to be under threat, could be broken by a quantum computer in as soon as 8 hours, so everyone's concerned about the timeline, and the strength of a quantum computer, and just how fast our networks are potentially vulnerable.
And so that's what we're talking about today. Next slide. Thank you.
Michael Borgia: For those of us who have not brushed up on quantum physics in a while, what is quantum computing?
Greg Berkin: Yeah, so… Quantum computing from a basic level differentiates from classical computers. Classical computers look at bits in a binary way, zeros and ones, yes and no's, you know, sort of very, very binary practical decision making. Qubits, the new basic units of quantum information, look at things in a sphere, and they consider many, many multiple states of information that you can assign to the quantum particle, or the quantum basic unit. That is being used to do decision making.
And so, quantum bits allow for multiple states for decision-making in what we call superposition. And this is a very novel concept so that you can consider multiple states at multiple times. That's not what we're used to in decision making, but with a quantum computer, you can measure those states and consider those states to flatten the decision model to have very, very, likely outcomes for any kind of information processing.
And so, superposition is one of the concepts, and the second one is quantum entanglement, which is also another sort of bizarre concept from quantum physics and mechanics, that you can have a relationship between the qubits that, and that relationship is held at any distance. They say in the universe, or across networks, or to basically extend the model and have this quantum entangled state allow you to process information regardless of distance.
And that's very, very novel, and changes the way we do information processing. And the foundation of that is the number of qubits and just how many decision states we can hold at one time. And so, it's very novel, but it's coming on fast, and those developments are greatly accelerated today. And at the heart of this, and what we care about from a vulnerability standpoint, and as a cybersecurity firm, we care about encryption, cryptography.
Public key cryptography is potentially vulnerable to a quantum attack. And public key cryptography relies on asymmetric encryption that is the basis for all of our secure connections and our digital signatures. There's sort of two elements to it, public keys and private keys. To derive the code that you need to unlock the encryption.
And one is a derivative. The private key is often a derivative of the public key and is only available to the secret holder or to the transmitter. And that is what you need to keep safe. And is potentially vulnerable to a quantum attack under Shore's Law, which is reverse factoring. RSA is based on factoring of numbers, and is known to be something that a quantum computer can accelerate the derivative of to figure out what the combination is, and it is under threat.
So, RSA and elliptic curve methods rely on math, more so than any other approach. We've used all kinds of different methods in the past to provide secret keys, but it's really about protecting the exposed keys and making sure that signatures are not forged. And so, those are the two areas of the secure infrastructure, but it's really about keeping signatures safe and the encryption safe with respect to public and private keys.
Michael Borgia: Even for those of us who are nontechnical, I mean, you can't overstate this, right? I mean, what we're seeing on the screen is why we feel… we can be confident that internet communications are secure and secret, right? So, the threat just can't be overstated, because it's undermining the very… that very assumption, which is, even if… even if the math makes your eyes crossed a little bit, you can appreciate, just how dramatic that is.
Greg Berkin: Absolutely. And now I think we'll turn it over to Ankur about the next level of this Harvest Now, decrypt Later, which is a huge problem in data stores. Go ahead.
Ankur Sheth: Yeah, and I think… I think, just… just final comment on that last slide, right? I think we're not trying to say that everything you do is susceptible, right? I think the point is that some stuff you do will be and is susceptible, and we're going to talk about what that means as we go down the road, but…
A corollary to all this is, as Greg mentioned, the Harvest Now, Decrypt Later acronym HNDL, which you may have heard, kind of goes, you know, hand-in-hand when we talk about quantum and the risk it poses. in the cyber world. But again, as the name kind of alludes, right, or highlights, it's capturing something up front for an exposure down the road, right?
So, an illustrative example is someone has a, you know, a confidential research file, right, for whatever industry you may be in, that has a lot of business value, right? Not just for today, but also 10 years down the road, for whatever it might be. Maybe it's a patent, maybe it's something else, right?
If a bad actor can actually capture this, right, quantum hasn't been developed as of, you know, October 29th today, but maybe in 5 years it is. And it has an algorithm that is susceptible to quantum computing and to breaking that cryptography, it can now be potentially broken into in 5 years, right? Or whenever that actually becomes available.
So… The harvest now decrypt later is actually bad actors collecting information, collecting data, whatever it might be, holding onto it, retaining it over time, and then using the future state of quantum computing, which we expect to be there, and we'll talk about timelines in a little bit, to actually break into those and then use that data down the road, right?
You probably noticed, or you may have noticed on, I think, the first slide that we had showed that Greg talked about, there was a highlight in a news article that said, crypto keys were stolen, right? That is an example of also HNDL, where they're capturing these crypto keys because they're going to use them down the road, ideally, or potentially, to break into all the transmission mechanisms that are used, specifically for those keys, right?
So, when we think about HNDL, we're really talking about the lifetime of secrecy, right? And the migration time to change that, right? So how long do you actually need to have this data? What are you protecting it with, and has anything happened to that data from the time it was incepted to, you know, the time you migrate to a post-quantum cryptography, you know, world, right?
So, this is something we're going to talk about a little bit more as we go into today's discussion, but it's a really important component to how we think about the risk of quantum computing to cybersecurity, specifically.
Michael Borgia: Yeah, we'll talk also about some of the legal implications of it, because they're kind of head-spinning. If you think about it, and again, we'll get into this a bit more shortly, our data breach notification laws in the US and other places as well have this assumption that if data is encrypted, at least if it's encrypted strongly and that the key wasn't compromised, it's not a data breach.
That makes sense, except what if it wasn't a data breach 5 years ago when it happened, but suddenly the encryption is broken, right? We've never really thought about data breaches as a thing that could occur later, far after the compromise, and we'll talk about what that means and some of the mess that could be created by that.
So, it's a good transition, because we'll talk about the legal framework. When we talk about the legal framework, we're going to talk about two groups of issues. The first is the one that is more directly on point, expressly, into quantum computing, and post-quantum cryptography. That is the federal government's transition to post-quantum cryptography, PQC, and we'll talk about this.
This is particularly relevant, obviously, if you're a government, but if you're a federal agency, it's going to be relevant. And we'll talk about why critical infrastructure as well, and then we'll get a little more broad, and we'll talk about, well, what if you're not one of those things? What are the risks in general, even if there aren't laws, and there aren't right now, that say you must adopt PQC, what do we do?
So very briefly here, if, the… the… I think that what's most on point expressly for PQC is the federal government's transition, as I said, that has implications for government contractors, and to some degree, critical infrastructure. There was a pre-existing deadline for the federal government to move… to adopt PQC by 2035. And there is a recent executive order called Securing the Nation Against Advanced Cryptographic Attacks, that was signed over the summer.
Order 14412 that accelerates those deadlines for certain high-value systems, particularly those related to one key establishment. And to digital signatures, and Greg mentioned the uses are of cryptography for both. Those have different deadlines. So… Quick overview: this has already been signed. In October, agencies were required to submit their migration plans. They need to move what would have been designated as high-value systems, for key establishment by the end of 2030.
Then, by end of 2031, high-value systems for digital signatures; everything by 2035, so it really just moved up a couple of those deadlines. The FAR Council, which is responsible for developing the federal acquisition regulation, the rules for government contractors, needs to propose a rule that will be incorporated into relevant government contracts that is going to require contractors to implement the NIST FIPS on PQC.
We'll talk about what those are, if you don't know what those are. Basically, technical standards around post-quantum cryptography, and the rule needs to be met by December 20th. The rule… what this executive order says is, the FAR Council, you have to go make a rule, the rule has to require contractors to implement these by the end of 2030, December 31st, 2030.
There's also some angle here for critical infrastructure. There's not a directive exactly, which makes sense. They're not… if they're not necessarily… if they're not a contractor, the executive order can't reach them directly. But it does talk about coordination with the federal government and critical infrastructure operators on developing migration plans for PQC.
There's a related executive order signed the same day that's more forward-looking about investment, facilitating investment in the federal government's development of PQC. We won't talk about that here, but it is interesting to read if you're interested. Another thing to call out here, by March 2027, so kind of soon, CISA and NIST must develop, guidance on a CBOM.
If you've heard of an SBOM, software bill of materials, we'll now talk about a CBOM: cryptographic bill of materials. And we'll talk a little bit more about what that is, and how those could be useful, in a later section.
Just to briefly kind of give you the overall framework here of the transition, in the dark blue box here, you see the EO we just discussed, and moving up some of the deadlines around high-value systems for key generation and digital signatures, but this is part of a whole framework, statutory executive orders that have been building this out, which this is all going to be developed over time with the end goal of 2035 for the federal government.
There is a different accelerated timeline for national security systems. In particular, the soonest deadline that I think is really relevant for contractors, if you support or provide national security systems, is January 1st, 2027. That's very soon. It is not a requirement for a full transition if you fall into this bucket, but it does say that procurements for new systems should be procuring systems that support PQC.
Or they should have a good, reasonable upgrade plan to PQC, so that procurements related to national security systems starting in two months should not be looking at new procurements of systems that cannot support PQC. Something else to keep in mind here is we transition to some of the broader legal framework. If you're not a government contractor, your eyes might be crossing here, switch screens and look at your email because you're like, well, this doesn't really apply to me.
But it kind of does. Something we have to wrestle with here is, like, what is the overall deadline? Let's just say you're a company, you don't even have government contracting, what's the deadline? Like, this stuff is all scary, we're talking about, we're talking about breaking cryptographic algorithms that are fundamental to certain parts of security.
So, like, when? Like, tomorrow? Do we have to do it in, like, 2 years, 10 years, 20 years? Like, what does this look like? The reality is we don't really know, because we don't… it's… we can only conjecture when these capabilities will be demonstrated. And in light of that, it's important for companies to look at this transition and think about how are other companies going to move?
For the government is going to move its contractors. Also, this is all part of an interrelated ecosystem. So, companies that offer both, to private sector and government are going to start to move, and then their suppliers will start to move. This is how these things work, and sometimes they're done intentionally, and the government will impose certain things, knowing this will bleed out in the entire ecosystem, which is what we want.
It's a policy goal. So even if you're not a government contractor, look at these dates, keep them in mind, because as we're going to talk about in the next slide, you want to do what's reasonable, and what's reasonable is going to be defined in large part by what is everyone else doing, and this transition is going to be part of that.
Okay, so India, moving outside of the federal government's transition. There is no law, at least not in the United States, that says you must adopt PQC. At all, let alone by X date, right? So, do you have to? And the answer is yes, at some point. Again, it's hard to say exactly when. But there's a few things to think about, and this is not by any means exhaustive, but… so, first of all, you've got board oversight in the Caremark line of cases, right?
Boards, as well as officers, have obligations to oversee mission-critical functions. Cybersecurity is one of those, there's a case on that. And given the… the kind of pervasiveness of this problem, and what's at stake, right? Some very, very fundamental pieces of internet security and communications. This is a risk that needs to be on people's radar, up there with AI and a lot of other things, right, that are emerging.
But even though this is technical and it's complicated, it's something that boards need to at least be briefed on it and educated about, to understand what are the risks here, how are we addressing those risks, what… do we have a plan in place, etc. Also, the FTC, Section 5, state UDAP laws, reasonable security, unfair trade practices, those kinds of concepts.
Those have been used for security for many years at this point, for security practices that are unreasonable, that are out of line with common practice, and absolutely that would happen here, too. This is where those dates I just… I've showed you get relevant, right? Do you need PQC now? No, I don't think so, right?
I think if you had a breach, and we found out, oh, PQC is here, and your algorithms were broken because of it, very hard to argue that today, or even next year, you're unreasonable. But 5 years? Maybe different. You look back at those dates. Now we're… other companies are transitioning, we have not. Is that unreasonable?
Right? And I would expect the FTC and others to be somewhat aggressive here. Because they understand what's at stake. Securities and Exchange Commission, you've got disclosure obligations for risks. I would expect to start seeing governance and management and risk-related disclosures. What's our exposure around PQC? How are we dealing with it? We'll mention here at the bottom this interesting comment from the Swiss regulator FINMA, which I think it highlights this whole slide.
Existing governance and existing laws already apply. They already govern this stuff. We don't need new laws, the new laws may emerge, and they're expecting a roadmap by mid-2027 for their regulated entities. That doesn't mean the financial institutions in Switzerland, that doesn't mean that they'll all be transitioned, but you can see, not just in the U.S, globally, there is this push to start transitioning now, very soon, over the next few years.
Even without new laws that say you must do that, right? Built in these reasonable expectations. Just a couple other things. There are some laws that have encryption requirements. The GLBA safeguards a rule for non-bank financial institutions. There's also the bank, credit union, other financial institution versions of GLBA regulations. They have requirements around encryption.
They just say encryption, they don't say what kind, but eventually that's going to be interpreted to mean PQC, because it's understood now to mean encryption that is good and reasonable, in line with industry practice. There's also an interesting angle here with risk assessments. You have to do a risk assessment under GLBA, under HIPAA, under the New York Department of Financial Services Cybersecurity regulation, and as they often are, NYDFS has kind of gotten out ahead of this, wants to be a first mover.
They released some guidance about risk assessments in September, definitely worth a read, and they said your risk assessment needs to address emerging cybersecurity issues, like One, AI. Two, quantum computing, right? So, they're looking at this, and when they… and they don't mess around. When they say things, they then start looking into them when they're doing investigations, following breaches, and things like that.
Again, I don't think they're going to today say, why aren't you… why have you not adopted PQC? But I would not be surprised if they started asking soon, what's your plan? What were your risks? Have you been addressing those risks? Let's see the risk assessment. It's not on there. Why is it on there? I would expect to see that soon.
Finally, on this piece, the encryption safe harbors. This is what I was talking about with respect to, the harvest now, decrypt later, right? You look at state data breach laws and other data breach laws at the federal level as well. State breach laws in particular have an exception that says if the personal data, SSNs, driver's license numbers, medical information, whatever it is, is encrypted, and the key is not compromised, it's not a breach.
Makes sense, right? It's just a bunch of ciphertext gobbledygook, right? Can't see what the SSN is, or what the diagnosis was, or whatever. But this is going to get weird, if… when eventually, not even if, when, harvest now, decrypt later becomes a thing, and the later becomes now, and this stuff gets decrypted. And then all of a sudden, all this information is out there.
In particular, you're going to see… you will see… we've already seen this, not related to quantum, but we're going to see it more companies get contacted by a threat actor that says, hey, here's some data. It's all your customers. And it looks like this thing is, like, 10 years old, and nobody knows where this came from.
Is this from a legacy system? Like, where did… why… we have no… was this breached? Was it… like, how did… no clue. And this is going to happen a lot. We're going to see, I'm convinced of it, because of these… because of quantum, we're going to see it even more, companies getting Oh, here's all your… here's your data from 15 years ago, 10 years ago, 5 years ago, whatever.
It was encrypted at the time. You didn't know it was an incident, or you didn't call it an incident because it was encrypted. Now it's out here. What do we do? Do we report a breach that, hey, this breach happened 10 years ago? Do we even know this is our data? Do we know where it came from? Very, very difficult set of questions that companies are going to have to deal with.
Ankur Sheth: Hey, Mike, just one quick question for you, kind of going back to the legal aspect. Just like NYDFS is probably one of the first ones to start calling out quantum, do we expect other laws to now, similar to AI, start calling out quantum as being something that needs to be evaluated in whatever that regulation may be?
Michael Borgia: Yeah, I think so, and I think we won't necessarily see them in laws itself. Maybe we will. Maybe eventually the word encryption will be replaced with, you know, post-quantum, you know, crypto, things like that. But what we absolutely will see is regulators start to focus on this and understand AI has kind of taken all the oxygen, right?
It is clogging a lot of this discussion, because AI in general, is just such a huge issue in society right now, but… and so it has… it has the forefront, in a way, in many of these security discussions. Not necessarily for security practitioners, but in kind of general consciousness. But PQC and quantum computing will get there, as people start to perceive this risk and its immediacy.
And absolutely, we will see more regulators starting to say, look, when we say encryption, we mean encryption that works.
Or when we're talking about risk assessments, we're expecting this is a major issue, we'd better see AI in there, we'd better see quantum computing in there, and we better see… you don't have to have the answers, but you'd better see, look, we know this is a risk, we know these things are undermining fundamental assumptions that we have about security, they're undermining basic controls that we have that allow us to say we're secure.
So, because of that, you'd better start thinking about how to address that. And as an example, to go back to NYDFS, because again, they're almost always out front, they issued guidance over the summer about AI and made a lot of similar points, right?
That, like, you may have had for years. Certain SLAs, certain timelines for how you patch vulnerabilities, and those have always been good, and you can say for certain vulnerabilities, oh man, this thing is so obscure, you have to chain together, like, 5 different vulnerabilities, and it would never be exploited.
That stuff is all falling apart, because those assumptions are being fundamentally undermined when AI can figure things out that human researchers would take months or years to figure out, and they can do it in days or weeks or whatever. Similar idea here, and we're gonna see… we'll see regulators start to address that.
Ankur Sheth: Right.
Michael Borgia: Okay, great.
Ankur Sheth: Thanks.
Michael Borgia: Let's talk about readiness domains, and what to actually do about all this scary stuff.
Ankur Sheth: Yeah, yeah, thanks. So, want to be clear, one, this is something that, kind of, we've put together as we've been starting to get, we being FTI, starting to get requests from clients around, how do we actually think about this problem, right? Everything we've talked about so far is. framing the problem, right? We have what's the risk, how's it tied to legal and regulatory statutes, and now how do we actually start thinking about, you know, what do we need to do from an organizational standpoint?
So, you know, utilizing a lot of the stuff that's out there, CISA, NSA, NIST, ISO, right? We kind of put together eight big domains that we think organizations start thinking about as we think about PQC, right? We're gonna hone in on 3 of these for today, just for, you know, essence of time, but at a high level, want to cover the 8 that we think make the most sense, right?
Number one, governance and strategy, right? How are we actually going to manage this and build governance and accountability around this, and actually build a plan to address this issue? Similar to everything else, right? Everyone wants to move fast, we need to build some governance around this, right? cryptographic inventory, right? You can't change what you don't know about, right?
So, if we don't actually know what our inventory is, similar to privacy laws, right? Understanding where your data sits, we need to understand where our algorithms sit. And that inventory is really one of the first steps that we're going to talk about in more detail. Harvest now decrypt later risk. We already talked about this, but, you know, what is that risk?
How does that… how does that risk apply to each organization, and the data they hold, and the lifetime of that data, right? Crypto agility, number four, right? What's the agility and the ability to actually change algorithms pretty quickly, right? Obviously, what we're doing now and what we're going off of right now is based off of what we know today, right?
But that could change down the road. So how do we actually have that agility within our environment to potentially change additional algorithms if we need to, you know, in 5 years after quantum, or whatever it might be, right? Migration readiness, so we're gonna dig into this one as well today as our second one.
What is the roadmap? How should we be thinking about, how do I prepare for and actually start to migrate over, right? This has been a very common theme with some of the companies I'm working with, is actually putting this into practical steps, right? So, we're going to cover that one in more detail. And then third party and supplier risk, number 6, right?
Similar to just broader cyber risk, we've seen an extrapolation event over the past 3 years. of cyber events because of third parties and suppliers, right? That only continues to extend when we think about PQC. So, we're going to dig into this one as our third, you know, deep dive, if you want to call it, for today's webinar.
Seven, right, OT and embedded systems, right? These are old. older systems, right? They can't always be updated, they have to run on outdated software, and of course, that means outdated algorithms, so what do we do there? That's another area to dig into, if that applies to your organization. It may not for everyone. And then lastly, awareness, training, and IR, right?
So how do we actually uplift the human element around this as well? How do we teach people, just like we do with AI, just like we do with data privacy, right, about what this means? What are we thinking about, right? And actually recognizing potential risk, in the things you do in your day-to-day job.
And responding to that risk, right, from an IR perspective. So again, we're gonna dig into, inventory readiness and third-party risk, right now. So… The first is the inventory, right? As you may imagine, and as I kind of alluded to, you really can't fix a problem if you don't know what the issues are, or don't know where the issues are, is a better way to say it, right?
You need to understand what algorithms you're currently using, what tools, technologies, etc., use them, right? Where do they sit? Who owns them? You know, so forth, so on. So, think about those, like, again, I go back to the data privacy example, and even the AI example now, right? Helping a lot of companies build their AI inventory, helping understand what are all the systems we're using, how are they used, what's the risk, so forth and so on.
This is always true for any risk that kind of comes up, right? Do you know where the problem sits? And the cryptographic inventory is one of the first steps. That that needs to be tackled, right? How do you actually identify this and then build a plan to address it? So, what are you trying to capture, right?
I'm not going to read every bullet here, but what are you trying to capture, right? What's the business service that's actually using you know, this technology, or whatever it might be, and who's a technical owner to that? And then, of course, as you drill into that, right. what's the date of classification and the secrecy lifetime?
What algorithm is being used, right? And what is the key size, the protocol? What's the… what certificate set being used? What's the library around the provider, the version, etc., etc., right? What you'll find as you go through this inventory, is not everything's going to be applicable, right? We talked about this at the beginning.
Not everything is susceptible to this, so you may go through this inventory. come up with a huge list and say, hey, actually, only 25% of this needs to be changed, right? Obviously, I'm using a random example here, right? But actually understanding where the problem fits and what it is the number one thing to kind of be doing, right?
And once you get it, you're tracing all that back to internal and external dependencies, you know, what's the vulnerability around that, right? And building a plan forward. So, I continue to say that, of course, all those 8 domains we talked about are super important, but the inventory is one of the first things we need to be thinking about when it comes to migrating, right, and moving into the next step.
Greg Berkin: Ankur and the algorithm and the key size are probably the most important elements here to be sure that you're using something that NIST has approved or has been peer-reviewed. to be sure that it can survive a quantum attack. And so, taking inventory is the first step, but you really need to be certain that you're agile enough to swap in and out AI models or the quantum encryption models that, can survive a quantum attack.
Ankur Sheth: Yep. Thank you, Greg.
Michael Borgia: Now, of course, no two companies are the same, but for a typical company, like. What are some examples of where they need to inventory, where they would find these uses, particularly if they might, you know, maybe something you wouldn't expect?
Ankur Sheth: Yeah, it's actually a great example, Mike. We actually are gonna talk about that, but you know what I think to highlight before we jump into that is of course everyone's gonna think about the big systems they have, right? That have, you know, highly sensitive data, right? financial transactions, health data, whatever it might be, right?
But it's also all the underlying dependencies behind that that may also come into play, right? What's the infrastructure behind that? What does it connect to? How is data flowing to other systems, right? So, it's not just the… you know, the big things you think about, right? But it's also thinking about and digging into those additional layers that are going to be important when we think about the inventory, right?
We're going to talk about a few examples in a couple slides, but, you know, it's getting beyond that initial layer that's going to be important.
Michael Borgia: Yeah, certainly understanding the lead time, because the lead time, we've already started to see that sometimes it's not that long, but sometimes you realize, like, well, it's… okay, now we're talking about, like, firmware that we can't upgrade, and, you know, the whole system's got to be replaced. The system is fine, but it doesn't support PQC, the firmware, things like that.
Ankur Sheth: Right.
Michael Borgia: It can surprise you. So even though the deadlines can seem very far away, you can suddenly realize, like, oh, this is actually quite a transition.
Ankur Sheth: Yeah, and then as we think about, on the next slide, kind of the standards, right? Again, we're not going to go kind of super technical here. I know we have a wide variety of people on the phone, but just to highlight, right, you know, what has been established, right? So there are, you know, as the slide says, approved building blocks.
So, NIST finalized these standards, in August 13th, I believe, 2024, so actually 2 years ago. These three standards, FIPS 203, 204, and 205, right? 203 is a shared secret for use with symmetric encryption, and 204 and 205 are on digital signatures, right? So these are the approved building blocks by NIST, right, that we can use as we think about what we need to do going forward.
But… this is just the approval component, right? An approved algorithm does not mean that, you know, you can quickly implement it and you're good to go, right? There's a lot that needs to happen, right? And you know, as I think Mike was saying, just a second ago, right, doesn't mean every system can even support that, right?
So, there's a lot of work that needs to be done now that we know what we need to use going forward, right? An approval does not prove you know, protocol support does not prove latency and certificate handling, right? And there may be hybrid designs that need to be implemented in order to support, you know, even using some of these approved building blocks.
So, we're not going to go too technical on all these things right now, but just want to highlight this is out there, all this is public, you can look it up, and we have, you know, further in the presentation some links for resources for you to look up. But I just want to highlight, there is approved building blocks out there.
But a lot more needs to happen before, you know, we kind of get to that, which is… You know, our segue into, kind of, Migration readiness.
Greg Berkin: So, if we could just go back.
Ankur Sheth: Stop for just a second.
Greg Berkin: Wanted to point out that KEM, you know, key encapsulation mechanism, it's the way that the keys are stored and housed and kept secure, and so that's the key vulnerability point is the key mechanism, and so It's a little different than the encryption itself and how the data is scrambled. It's your key system, and so…
That's what you have to think about in terms of this, the world of key management and sharing of keys, and then the encryptors themselves, applied to digital signatures and other things. There's a couple worlds of, overlap, but NIST makes these recommendations. In the past, they've made, I think, 4 recommendations, and within a year, I think two of those were already considered vulnerable, and they switched them out, and so it's a very dynamic thing.
It's not, you choose this and you're set. You have to look at that, and that's why you need to be cryptographically agile in your approach.
Michael Borgia: And if you are… I'll say if you're an attorney, and you're like, man, this is very complicated. It is, this is extremely technical.
But this stuff's important, I think, even if you don't know all the ins and outs, to understand what does this landscape look like, because ultimately, and we'll talk more about this at the end with our checklists. You don't necessarily have to know in depth what this stuff is, or how it works, or anything like that, but you have to know it exists, you have to know risks come from it, and you have to make sure you're having the right conversations to say, are we covering the bases?
Do we have a plan? Does the plan make sense? Are there gaps in it? Are we not going to certain places where we need to go, you know, that's your job here, and so that starts with just even understanding what's covered, what's the landscape look like, even if it is hard for me to dig into it too deeply.
Ankur Sheth: Yeah. Thank you. That was great additional input.
Michael Borgia: Just trying to reassure everybody who's like, oh my gosh, this is so much… so complicated.
Ankur Sheth: Yep, yep, it's a lot. So, Domain 5, this is the second one we want to dig into a little bit more, and this is really around Migration readiness, right? So, what does that mean? Migration readiness means the organization can explain how a critical service is going to move safely into production using now these new standards that we just kind of talked about, right?
So, as we think about this, right, and we think about how do we prioritize, and how do we actually start to plan to move forward, we want to prioritize by a variety of things, right? Data lifetime, right? How long is this data going to be around? If it's gonna be gone before, you know, we even need to manage it, then it is a lower priority, right?
But it's gonna be around longer, we want to make sure we have the right stuff in place. business impact, right? The difficulty to actually do some of the hands-on technical, right? And what the agreed-upon architecture and supplier capabilities are going to be, before you can actually say, hey, I can meet this by, you know, January 1st, 2028, or whatever that might be, right?
So, what we talk about, and this is similar to a lot of you know, large technology rollouts that, you know, for those that have done that in the past have done, is you want to do some kind of representative pilot, right? Develop some clear boundaries around what we're going to focus on as a starting point, right?
Identify the owners, right? Identify both the business and the technical side, and figure out, what are the challenges you're gonna have to face, and how to actually tackle them in this, you know, rollout, right? There needs to be acceptance criteria, right? How do we say this was a success, right, once we actually do this, right?
And think about what does that mean for extending that now into the broader enterprise and the other systems and assets that you need to actually do, right? An important thing to think about is rollback, right? For those that have done large technology programs, if something goes wrong, how do you roll back? In this instance, right, a rollback could restore quantum vulnerable systems and algorithms, right?
So, you know, again, depending on when this happens and how far we are in terms of the timeline of PQC, you could be rolling back into a vulnerable system, right? Which is not what you want. So just stuff to think about, right, as you kind of go into this program. And of course. Doing a pilot is going to help prove your cause, right?
And actually show the path to a successful rollout and a successful migration across, hopefully, all these susceptible areas. That you need to cover off, right? So again. We want to think about… starting with that inventory, right? And then, from that inventory, prioritizing scope based on all the factors we just mentioned, and then starting small and building from there, right?
We don't expect everyone to do this in a month overnight, right? It takes time, and we'll talk about some of those timelines in a few later slides as well.
Michael Borgia: Yeah, I want to hold that, but I want to ask you about the timeline, because I think that's a common question we get is, like… again, because there is no clear date we're working towards. It's like a sudden thing. What is the… what is, you know, what date should we be working towards? Or perhaps more helpfully.
And again, we can talk about this a little bit later, like, okay, 2027's coming up, I'm budgeting, like, what should my priorities for 2027 be? So, we can make sure we get back to that with our checklists, for listeners to think about, alright, how do I know if I'm on, if I'm at least being reasonable here next calendar year?
Ankur Sheth: Yep, yeah, thanks. And yep, we will cover that, team, so don't worry. And then we have a couple… a couple things we want to talk about when it comes to supplier, right? I already kind of alluded to, and I think everyone probably on here understands, the supplier risk that we all face, right? You know, PQC is just another component of that.
But supplier readiness is also an important aspect of how we evaluate and work with our third parties, and now as it relates to PQC. I can tell you. I have an example right now for a client where, again, we are doing a quantum project, we're helping them think about, hey, what are the things I need to start asking them as part of my third-party risk management process, right?
I already asked them all these security questions, I've now added AI into it, and now what are the relevant quantum questions I should be… I should be asking them, right? So, we talked about this a little bit, and I think Michael had asked the question to me a couple slides ago around hey, where should we be thinking about, what should we be looking at, right?
And I said, yeah, you're gonna think about the big systems you have, the big, you know, cloud providers you have, things like that, but as you look around those, sorry, on the slide on the left-hand side. some of those bullets, those are some of the dependencies and things that you need to be thinking about in terms of where else could this vulnerability lie, right?
So, look at identity platforms and certificate authorities, right? As we think about digital signatures, we think about network equipment, VPNs, HSMs, right? software libraries, right, and how those are being updated, managed services and subcontractors, right? Embedded products, things like that. So again, we're not looking at the top layer here, we want to start thinking about and evaluating all the components, you know, that kind of hide behind it, right?
And I will say, this evidence worth requesting kind of thing here, right? You know, I think we all have been through the realm of asking all these questions, getting a lot of stuff back, right? But this is very much, you know, the concept in security that we always follow, which is trust but verify, right?
So, people are gonna say, yeah, we rolled out, you know, all these new, building blocks to be PQC, and, you know, we're good to go. But I would suggest that you actually ask some more probing questions around that, right? And that's what this is talking about. These are examples of evidence that's worth requesting when your third parties are saying, yeah, we've done our work, we're good to go, we think we're safe, right?
Again, don't need to read all these in detail, but, you know, availability dates, configurations, right, interoperability and performance results, things like that, right? Probe a little bit more, because again, if they're susceptible, you're susceptible, in many cases. And you can create a short evidence request list for this, it doesn't need to be super exhaustive, but definitely work with your procurement team, your legal team, and make sure we're asking the right questions here.
On the next slide, please. And then, right, as we think about, the supplier direction, right? We, anyone on this phone, right, has upstream and downstream kind of suppliers, right? So, you need to think about it from both sides of the equation, right? And as part of that, right, as we do, as we think about any of our suppliers, right? What is the risk of those suppliers, right?
Are they actually… do they actually have sensitive data, or are they just accessing public information that, you know, really doesn't matter when it comes to sensitivity, right? So which vendors have your data, but also, how long have they had that data, right? We keep going back to lifetime of data. That becomes super important, because again, the Harvest Now Decrypt Later component can… can rear its head here, right?
So again, and then this all kind of ties back into, right, you know, maybe some of your customers, suppliers are also part of the federal ecosystem, right? Which then, of course, has a number of other obligations you have to be thinking about.
Michael Borgia: Yeah, another place lawyers… this is a great place to be involved, and maybe the most important place in terms of the implementation, right? Understanding this, because so much is supply chain risk, and supply chain risk in cybersecurity is an extremely hot topic, and one that regulators of all types are paying a lot of attention to.
What contracts do we have? What kind of rights do we have? Have we mandated migration? By when? What, like, do we have audit rights? And then what… what obligations do we have? Because you would think, oh, these will get pushed down to us timely. Well, surprises happen, right? So, understanding what… what do our customers do?
What do we expect they may be pushing down to us soon, so that we don't have a last-minute, like, oh, by the way, you guys need to be migrated, like, next week? Things like that. Understanding that ecosystem from both sides, what your vendor management program is, and how you deal with that.
And also keeping in mind that there's a question about vendors that have our data, but there's also an important question that's often missed in supply chain management. about our suppliers, people that supply software to us, they may never touch our data.
And sometimes, for companies, they get left out of the supply chain and vendor risk management, but they're important here, because if they're providing you software, firmware, communications technologies, devices, and things like that, they are part of your compliance and your migration here, and you miss them at your peril, because they're going to be very important.
And you want to make sure your current program is going to capture that.
Ankur Sheth: Thanks, Mike. I'm gonna… I'm gonna speed up a little bit on the next two slides so we can make sure we get to the practical recommendations, before we log off, but real quick, provider fit, right? These are kind of the four questions you can ask, right, as you're talking to providers and suppliers, right?
You know, pace is really around working backwards from when they think they're gonna be done. Does that fit your timeline, right? Coverage, right? What does the actual coverage of those products and interfaces cover? Is it enough for what you're expecting from them, right? Evidence, we already kind of talked about, reviewing, evaluating the evidence that they're providing to you, and asking probing questions, right?
And commercial fit, right? As they continue to update and migrate and things like that, does that fit, you know, your costs, your commitments? And there are, and there should be, you know, no vendor lock-in, right? Do you have exitable options in case something goes wrong, right? An easy way to think about this is mark each dimension, you know, green, yellow, or red, using evidence, right?
And then figuring out, does this make sense for me from a supplier perspective? In terms of, you know, PQC specifically, and if they're gonna be ready for you, right? So, covering up that quickly, and then moving to the next slide, real quick again as well, right? And the last piece on the supplier side is oversight and audit evidence, right?
Oversight should detect changes in delivery risk and preserve evidence that remains relevant to the service in production, right? So again, because this is such an ongoing issue, and will continue to be until we have a better handle of this and timelines and things like that, right? You need to provide some additional ongoing oversight around these suppliers and what they're telling you, right?
You know, there's some examples here, but anything we do needs to be risk-based, right? So those suppliers are accessing the most sensitive data, the most sensitive information, right? They need to be maybe on a shorter leash, if you want to call it, right? Then those that may not be as sensitive or confidential in nature, right?
And then doing those on a periodic basis, right? Right? How have they made progress in their PQC migration, right? Doing those, you know, quarterly check-ins if it's a critical vendor, right? Annual if it's not, things like that, asking, again, for that evidence, retaining those results, right?
And checking in, I think, is going to be really important, unlike some of the other things we had to deal with to make sure that they are staying true to their word, they're hitting those timelines, because that is going to affect you, right? Again, supplier risk is still huge, and will continue to be huge for everything we do, just because of the ecosystem we work in.
We're not ring-fenced behind, you know, just our walls. We're interconnected with everyone we talk to and work with. So, I went through that pretty quickly, but I think you guys understand that third-party risk is still One of the ones that we want to focus on when we think about risk, and what that poses to your organizations.
Michael Borgia: Yeah, and this stuff is huge for attorneys, and regulators are all over this. They're asking a ton of questions. How often are you checking in with your suppliers? How do you know their security is good? Do you ask them questions? Do you get a SOC report? Do you have audit rights? Have you ever exercised the audit rights?
What kind of contractual commitments are you getting? And Ankur also mentioned exit, and regulators, we don't always think about that as a cybersecurity issue, but it really is. Regulators love to ask about that. What happens if you get way too tied down on a supplier, and they're not good, or they go bankrupt?
What do you do? Can you get out of it? Having those exit strategies, contractual and otherwise, is extremely important for business, but also for cybersecurity. Okay, so let's talk about practical responses, what you and your org can do right now, talk about timeline, we'll go back to that question about, well, what's 2027 look like, potentially, a good version?
Ankur Sheth: Yeah, and I think we want to get to some more, even more practical advice, but just want to start here really quickly, more broadly, right? Accountability within the organization, right? How do you actually manage that and keep moving forward? So, keep your internal team accountable, right? There's gonna be business owners and technical owners that tie that back to this, and you need to get funding for all this work, right?
There's also gonna be product providers, right? So again, get the information we talked about for third-party providers. Tie that back to individuals within the organization to stay accountable, right? Bring in specialists. I don't expect anyone or any organization to have all the right people in-house to manage this, right? So, bring in the right people to support you and help you through this journey.
And then validate together, right? Bring all the right parties to the table to actually look at this issue. It needs to be a committee, right? Just like we have AI committees or innovation committees, there needs to be a committee around this to kind of do this together. across the business, technical teams, suppliers, you know, and your vendors, right?
But I'll pass it to Michael and Greg to go into more checklist-focused items.
Michael Borgia: Okay, so here's my vision of 2027, right? You're not necessarily going to finish all of these, but things you're going to have to think about, and some of them which you'll do, right? So first of all. Understand, even kind of as a number zero. What is your company doing about this? Are you inventorying, right?
That inventory is vital. Okay, so they're inventorying. Now we need to build on that as in-house counsel. We need to map the key suppliers and assess their terms, right? So, to the extent we have third-party issues, what are they? What kind of obligations and rights and things do we have? What does that look like legally?
How do we exercise that? How will it be exercised by our customers? If you need to build a contracting playbook. How are we dealing with this with our suppliers, or how are we responding to terms from our customers about PQC? Then think about board advisory, right? How are we advising them? We're thinking about our Caremark duties.
We're talking about risks. Right? If we're talking quarterly, or biannually, or once a year, whatever it is, are we talking about AI? Are we talking about PQC? Should we… probably yes, at some point. What are we saying? How are we making sure that they're staying informed and they're meeting those duties? Think about your risk assessment, right?
Especially if you're NYDFS regulated. We know they've said that expressly, but even if you're not, if we're doing all this work anyway, it should be in the risk assessment. Let's take credit for it. Let's say we know the risk is here. Here's all the mitigations we're doing. We're inventorying, we're coming up with migration plans, right?
Make sure that's in there. If you have a breach, especially down the line, if it's a breach of data related to quantum cryptography, you want to be able to say, hey, this was reasonable. And support the transition plan. Help with inventorying, priorities, owners, things like that. So, Greg, more on the technical side.
Greg Berkin: Yeah, so we were trying to think about the best way to frame the next steps for CISOs and GRC. And we've been talking a lot about aligning the readiness programs of both cyber, AI, and quantum. Quantum is coming, AI is top of mind, and cyber should already be in place, but these are all readiness programs that, you know, require significant resources, stakeholder alignment, and transparency of, of, you know, all of the vulnerability issues.
And that's often, you know, the keys to the castle, if you will. A lot of that stuff doesn't want to be… isn't easy to be shared, but it has to come out because, of, regulations, because of, obligations that you have to, make your network, your operation secure. And so. We're trying to recommend that you align these readiness programs along with what you're already doing, but be really prepared for a post-quantum cryptography program.
And for a while. You're gonna have to take this, cryptographic inventory, and also apply it with AI in mind. You need to be thinking about cataloging your AI workloads, your vector databases, any model artifacts and repositories. And your training pipelines, which all store long-term data. The same implications of Harvest Now, Decrypt Later, for AI apply to what's, coming with quantum.
And so. All those things need to be aligned. You also need to be thinking about a dual agility architecture. Crypto agility is important, but it's really considering both of those domains to make sure that you're set with that. Also, on the, on the pilot side. You need to put in place a key exchange mechanism that's post-quantum safe.
But you're gonna be in a hybrid mode for a long time, or some extended period, because you can't just cut over, and it has to be tested, and make sure that everything is completely, you know, compatible. And so, and we mentioned embedded systems and model trust. You have to be sure that your model weight signatures and your zero trust update paths for OT and other edge devices are also… can survive a quantum attack.
They're also PQC compatible. It's very important. On the governance, risk, and compliance side, you have to make sure that you're thinking long-term and… but you're thinking with immediacy, because, you know, a quantum attack is something that has daily developments of exponential consequence. It's really coming on very quickly. And you know, a year ago, it was… the estimate was a million qubits to break RSA encryption.
6 months ago, it's 100,000 qubits. And so. The pace is increasing, but it's the hardware that's required to do the decryption is shrinking, and so the timeline is approaching quickly. We don't know the definitive date of when RSA 496 will be broken. But it is an imminent threat, and it must be taken that way.
And then, of course, you need third-party accountability. We talked about suppliers and that kind of thing. Transparency, they have to share with you their encryption methods and things under confidentiality, and of course, make sure that your delivery is fully funded and auditable. We look at logs and forensic data to see but it's very hard to, to think about a quantum attack in terms of testing that, because of, the emergence of quantum computers.
It's, it's, it's, it's… it's done in… in… virtually. It's not done… it's done in simulation. You can actually program a quantum computer today through Amazon. There are 4 different ways to… to go online and actually use quantum circuits to test your network, but again, it's all in simulation and virtualization, so we're still in the period of discovery for how to do this in a migratory way to get to a post-quantum cryptography state.
Michael Borgia: Yeah, there's a ton to think about, and I know we're at time, but I think we can at least agree: 2027 is a year to start getting your head around the scope of this problem. Maybe not necessarily to fix it, get it all done, but to feel like, okay, we can go into 2028 thinking we know what this looks like, and then that's a great goal.
This time flew by, but we appreciate everyone joining, and if you have questions, feel free to reach out to one or all of us, we're happy to discuss this further. We hope you guys found it… all the attendees found it super interesting, as interesting as I did, and there's still so much to learn about it.
Ankur Sheth: Thanks, everybody.
Michael Borgia: Thank you, have a great rest of your day, everyone, and again, thank you for attending.