 So good morning. My name is Natalie Fisher. I am a product manager at VMware in the office of the CTO. And first, I have a question. How many people here are crypto agility experts? You guys have volunteered to answer any questions. Thank you very much. I'm just kidding, obviously. But the reason that I do mention that is because this is a 101 session, so I want to make sure that you guys aren't disappointed by the topics that we're covering today. So why don't we get started? I'm going to go over the agenda really quickly. We're going to talk about what is cryptographic agility, why is it important, why do you even care about this, and some suggestions on how to prepare. And then I'm going to give a quick overview of what VMware's plans are. And because I'm doing the VMware plans require a disclaimer, don't purchase anything, don't buy more VMware stock because you think something super awesome is going to happen because this may or may not occur. So the first area that we are going to cover is what is cryptographic agility? So crypto agility is defined as the ability of security systems to be able to rapidly switch between algorithms, cryptographic primitives, and other encryption mechanisms without the rest of the system's infrastructure being significantly affected. And this is especially important when it's in response to changes in security needs or invulnerabilities. Essentially, it's the ability for an organization to have complete control over its cryptographic mechanisms and processes without involving intense manual effort. So what are the advantages of being cryptographically agile? One is the ability to more easily transition to new algorithms as they have been created. Change your libraries on existing implementations when new features or algorithms have been added. Modify key configuration parameters without having to make adjustments to your architecture. Having the ability to retire and deprecate algorithms without making a significant impact as well. Compliance standards, so this isn't just about being able to easily standardize your compliance and security across your enterprise, but it's also the ability to easily migrate your crypto from two defined standards, such as FIPS or ISO. And of course, remediate your libraries when issues or vulnerabilities are discovered. And it's important because cryptography is a critical aspect of security. And it's often necessary to update the algorithms used in response to advances made in cryptography, such as new attacks or discovery of weaknesses to existing algorithms. It's going to allow you to also improve your overall security and resilience. So let's take a look at what is the most common architecture setup in the current landscape. So today, the majority of enterprise systems have their cryptography so deeply embedded in their systems and their applications that it's increasingly hard to make changes. And the reason is because back in the day, when crypto was initially created, it was simply used. And it was acceptable to hard code into the operating systems themselves, which of course makes it near impossible to make changes. And a great or not so great example of this is when a large problem of vulnerability called Heartbleed came to be, if you will. If you aren't familiar with Heartbleed, it was a security bug found in OpenSSL Cryptography Library, which is a widely used implementation of the TLS protocol. And that vulnerability allowed an attacker to not only capture credentials, but also read the memory of the system, such as emails and keys and transaction data. And this was discovered in 2012. And we all know how quickly things move in security, particularly in the verticals of secure of government and health care. And it was patched finally around 2014. And then organizations had a couple of options, right? They had the option to either replace the OpenSSL libraries with the patched versions of them, or the second option was to replace them altogether. However, both options are kind of difficult because many organizations lacked the visibility into where OpenSSL was being used throughout their environments. And not only that, but because it took so long and it was so difficult, a lot of organizations were incredibly slow to respond. And so hackers managed to actually steal about four and a half million health care records. And even in 2019, over 200,000 systems were still unpatched. So you might be thinking to yourself, you know, WTF, or why was it so hard? Or maybe you're not wondering that because you know why it was so hard. And maybe you're thinking, this was a huge distraction for the engineering teams, having to fight fires because something was insecure and there were vulnerabilities. But to be fair, it's difficult to change or update protocols for a variety of reasons, especially when you're not set up to do so. One of the areas that I kind of talked about was being aware of your encryption and what you're using, which applications are using it, or how it's actually being used. So you have that lack of visibility. There's no unification. There's no unified way for customers to transition between cryptography standards, keys and certificates, libraries, things of that nature. And this is one of the hardest ones. Re-architecturing is required. To date, to make changes, often costs hundreds of developer hours as it may require re-architecturing portions of an application. Because if things are hard-coded, then the apps and the crypto are specifically working with a particular API that's used in that implementation. And that means that any changes to crypto will require complete changes in the app itself. And it's highly unlikely that the new versions of the app and crypto are gonna be compatible with any of the legacy versions that exist. And of course, anytime you have to do anything manually is incredibly time-consuming and error-prone. And there's more. So the current landscape doesn't take into consideration all the different stakeholders that are involved. And if you're not too familiar with cryptography, I don't wanna make it sound like nothing exists. Obviously, something exists, right? The traditional building blocks show that organizations have a layer that is represented by engineers, developers, et cetera, that are responsible for the platforms and will be updating the libraries themselves. But what is missing from this story are the other stakeholders. For the enterprises, the framework is missing for the operations teams. And by the operation teams, I mean the top green box right there for enterprise consumers, looking at the InfoSec, the IT infrastructure teams and things of that nature. And they work with the green box, right? They work with the developers or engineers for the changes which takes time or sometimes developers have to make decisions on when things have to be patched. And I don't want you guys to misunderstand what I'm saying. Of course, developers need crypto, but the consumption of that cryptography and management needs to be operationalized. And so the other stakeholders that I'm mentioning at the top are just as important to be part of that process, if you will. So, because you have to think about like how does an entire organization come to understand their cryptography footprint? How do organizations transition to new algorithms and standards? So we also need to have to take into consideration these other consumers. So let's move on to future landscape. While it's true that we do have some agility in our cryptography. For example, many OS vendors, such as Microsoft and Google, have agility integrated into their software update process, which comes in place of you downloading large packets of data and rebooting your system. But for the future, if you kind of imagine it this way, it's a world where the crypto agile framework is independent from the app lifecycle itself. So it's simpler to manage your application and your cryptography transition configuration and compliance without having to rewrite your application or to reboot or reset your infrastructure. So there's additional benefits to this, right? It means that you know how crypto is being used, of course, right, you're gonna have that visibility. You are also, it's also gonna be easy to do standards migration, like I talked about regarding FIPS and ISO. It also means it's gonna be easier to meet your compliance requirements and establish clear policies around crypto and best practices. And it's gonna encourage good engineering practices. Most developers aren't security experts. So once all the stakeholders, as I had mentioned in the previous slide, have gained visibility over their cryptographic infrastructure, they can now replace their outdated crypto as necessary and along with instilling some automation as well. So I know that was kind of a lot, but now it's kind of why do I really care? So obviously crypto is everywhere, right? It's used every time you make an online purchase. It is used anytime you do online banking and transactions. Every time you open your phone and use an app, it's there. It's always working in the background. It secures all transmitted information in our IoT world and it's working there to authenticate people to devices, device to devices, et cetera. Another reason to make sure that you understand and care is because of implementation flaws, right? So here I have like these three images to kind of represent some of the really big ones that are pretty well known. The first one is the Heartbleed example that I gave earlier. The other two are Spectre and Meltdown, both of which are classified as side channel attacks. And there are other forms of side channel attacks. And can I just say that I really love the logos that they create? I'm just gonna throw that out there. I think they're super cute. I really like Spectre, okay, moving on. So other forms of side channel attacks include timing attacks, right? Where the observable movement of data in and out of memory betrays just enough information about the secret keys to narrow down the potential range of keys, which means brute force guessing is a pretty practical way to kind of figure things out. But the point is here that we can go on and on and on about what could be found, what has been found, what will be found. But the reason that you really should care is because do you really wanna take two plus years to update your vulnerable systems because you aren't cryptographically agile? The other big one, of course, is quantum computing. So scaled quantum computers can break our encryption. Quantum computers are getting more and more powerful and it's really exciting and it's awesome to see in our technology world, but it's bad for, but it's bad because it can break your encryption on most enterprises and digital infrastructures and things that economies are relying on, which would basically render today's encryption methods pretty useless. So you may think, that's fine, we can just let future Natalie or insert your name here, deal with that and worry about it. However, you don't have that much time, right? Because it's not like quantum computing is like a decade away. And on top of that, there's a type of attack called harvest now, decrypt later, where it's essentially this attack where the bad actor collects the encrypted data and holds on to it, waiting for the point in time that they're able to be able to decrypt that information, which can be things like trade secrets, government agencies, social security numbers, but I mean, everyone's social security numbers out there, but you know what I'm trying to say. So I know this all sounds pretty bad, but I also kind of want to emphasize on how important all of this is. And for the threat of quantum computing for the last five years, NIST has been working on new standards and that are resistant to the types of quantum computing and these new algorithms are called PQC or post-quantum cryptography. And you don't need a quantum computer to make use of and it's gone, okay, and it's back. You don't have to make, you don't need a quantum computer to make use of these algorithms, but we will have to transition our existing applications and our infrastructure to support them. And while there are draft standards out there, they are of course going to be updated, more will be added to it. That process is gonna continue on. And then of course last year, a memorandum around PQC was released because of the critical security implications and the magnitude of the effort that's gonna be required to switch to new algorithms which enterprises will need to comply to. So how do you prepare? For what I've clearly outlined is like totally the end of the world. So I want you to put your head between your legs and kiss what you think is strong cryptography goodbye. Obviously I'm kidding, but it's gonna make RSA 4096 look like Route 13. So from this talk, you've learned that being crypto agile is complex and it will require a multifaceted approach and to prepare your organization to be agile, these are a few suggestions. Number one, you're gonna wanna inventory and identify all your crypto resources such as certificates, keys, algorithms, libraries, et cetera. Try to group them logically by expiration dates for certificates, for example. You wanna communicate your organization policies with your internal and external stakeholders and provide ample education and training on what these policies are. You also want to identify your most valuable assets and have plans on how to secure them. And then plan and build for change because big changes like adoption of PQC aren't the only problem that you're gonna be running into. Even changing your applications to support changing compliance is also gonna get value from being crypto agile. You also wanna create backup plans for certificate authority compromise so being able to arrange with alternate vendors and having the ability to carry out quick CA migration. Now I'm gonna talk about what VMware is actually going to be doing and the project that we've been working on. So there is a project called Project Newcastle and it is a policy-driven approach to implementing cryptographic agility in secure communication contexts. And the goal is to support cryptographic library extensibility and the ability for internal and external customers to create their own policies. So the project is looking to support these five areas which I've talked fairly extensively about, right? The observability component which is to understand what crypto is being used and how and where. Being able to define your cryptography policies and having that ability to install and implement that cryptography without having to reinstall or reboot your systems automate your reconfiguration so being able to change libraries out when they are updated. Support PQC transition because I've talked pretty extensively about why that's important and that will be important in the next coming couple of years. And then of course to audit and attest cryptographic compliance. So that is actually it. I put some chat to BT jokes up here because I think they're funny. Okay, I think some of them are funny. I particularly like the yoga one and the banner and because I kind of feel like this talk is very intense so I wanted to not make it not exciting. And then QR code if you even remotely liked my talk and enjoyed my jokes and if you didn't, here's my dog don't look at the QR code. And that's it. I hope you guys have a really awesome time at the rest of the convention. They are open for questions but yes, okay, for PQC. Yeah, so just in case nobody heard him the first question was are people starting to look into how to solve this problem and start becoming more crypto agile? And then the second question was what do I believe the timing will be for PQC to become a thing, if you will. So the first answer to your question is yes. There are a lot of companies out there that are actually starting to sell ways to make your environment more crypto agile so this is definitely something that has been in the works for quite a while. It's actually some research that's been done on for like over 10 years where people have tried to figure out how can we do this and how can we improve the way that we manage our security infrastructure. So definitely yes for that. Second one in regards to when will quantum computing endanger us and kill us all? There's a lot of arguments and discussion along that but we're probably looking at about five to eight years. I had jokingly said a decade because that was what people said five years ago. So we're looking probably about 2028 is what we're looking at. Yes, the last thing. Yeah, because quantum computing is also gonna mess with that as well. It is a big, that's why I kind of made that joke about the whole ROT 13 thing, right? It's like things that you thought were super secure are no longer secure. You are not allowed to have questions because you are an expert, but go ahead. Yeah, sure. So we don't have any, so VMware itself doesn't have anything right now not to try to sell our, oh God this is recorded, not to sell our products, like not sell our products but there are other companies that are doing that now but what we are planning to do in terms of what we're going to be implementing, you won't need to implement something brand new. The hope is that it'll end up being more of a plugin to your existing security infrastructure is the goal. Yeah, yes, yeah. Yeah, so that's a really good question. I don't know if everyone heard that but he's basically asking, how do you trust new things that come out? Much like anything new that comes out. I mean, unfortunately it's hard to say because I feel like it's gonna have to follow like standard SDLC and the sense of like testing it, making sure it works in your beta or your test environments prior to deploying to GA but I mean this is gonna be new for all of us, right? It's not like anyone has already solved all these problems and they're hoarding it, maybe they are, but not that I know of. So it's just gonna be a journey that we're gonna take as a security community. Yeah, I feel like this also kind of goes back to your first question, right? Like how do you trust something that's gonna be new and that's gonna exist and I think it's kind of gonna be like, you know how when DevOps first started and you had your CIC pipeline and it's gonna like, how are we gonna do this? Why is this taking so long? And now it's pretty easy to change stuff out. I kind of see it sort of going in that direction where it's like, it's just gonna take time to get there but we'll get there because we kind of have to. You're not gonna like any of my answers but yes. Yeah, so I mean that's kind of the problem I think that's what everyone's kind of fear is about the whole quantum computing that's gonna be happening. I think it's gonna be more about specific vulnerabilities to be honest with you, yeah. But you know, experts, I know he jokingly was an expert but yeah, yeah, so he is an expert and doesn't really want to answer questions. That's totally cool too, yes. Yeah, so that's also a really good question. The answer is both. So I've met with quite a bit of customers and they are concerned about the NIST protocols particularly on the federal side. They're very concerned about it but they do want it, but crypto agility is definitely high on their list at least for the Fed offices that we've spoken with because they're concerned about expediency on being able to support what's gonna come down the pipeline. And I didn't want to say this part because I felt like I already sort of was like, hey, the world's on fire, right? But people are already harvesting data and they're just kind of keeping it and waiting, right? Like that's the legit thing that's happening. Yeah, I did not expect to get any questions so this is kind of fun. Anything else? I didn't think my presentation was gonna run so quick but I guess I talk really fast. Cool, thanks, feel free to confine me.