 Starring us off this morning is Marie Fromm. She's going to be talking to us about cloud encryption, how to not suck at securing your encryption keys. Take it away, Marie. Thank you. Yes, that's going to be the goal of today's talk, how to suck less. So anyway, a little bit about who I am. I work in InfoSec, cryptography, and I'm trans. I've done a lot of stuff over the years, incident response, security testing, reversing, security architecture. And for the rest of my career, I really want to fix things. I see there's a lot of people that throw bricks through windows and stuff, and I want to work with builders to actually fix stuff. And I think it's really important because right now there's a lot of really negative things happening because we are failing at security so badly. So I want to see things suck less. Now, what kind of got me thinking about this talk was something that affected probably most of the people in this room was the Equifax Neighborage. And they had the CEO up in the stand and they were asking, one of the questions was obvious, it was, well, was your data encrypted? He actually said he didn't know, which was amazing. So I was just stupefied by that first off. And then the thing that really, really, really upset me was after they kind of issued some clarifications that said, well, maybe someone was encrypted, maybe someone wasn't, but encryption doesn't really help. And then you saw the pundits in all the columns and stuff about, well, yeah, encryption doesn't really help prevent. And I just, I know that for the people in this room, I would almost guarantee that most of you would be able to encrypt something that I couldn't read. So I mean, that's kind of a basic thing and it makes statements that, well, encryption doesn't really help prevent data breaches is a really bad message. And it's partly due to the way things are being done, the way cryptography has been used, both on ground and prem and data centers and in the cloud. So I'm gonna talk through a few different areas. I'm actually gonna start on ground and talk about data center encryption that's oftentimes kind of typical. Here's a big storage frame, you'd find in a big IT shop. And the product slick, it's got all these cool things, strong data at rest protection, it talks about. And they go on and they say these are protected by AES which will protect top secret government data. So I mean, they make these claims and the EMC dude makes a huge sale, the execs feel good, our data's encrypted at rest. And, but let's talk a little bit about how these work before we get into the cloud. So system operation, it boots up, big hurricane machine. And actually I should make a, I started out this slide writing data written to Rust and I thought, oh wow, so for younger ones, in the old days we had these spinning rusty things that we wrote data to and now it's all flash, but yeah, you'll have to Google that shit, it's really great, great. But you know, it's, but the main, so these systems boot up, they're written in encryption key that's, you know, they try to protect it. And then all data written is transparently encrypted as it writes in the storage media. And then on reads it's transparently decrypted. And so there actually is no awareness to the server or the application that this encryption's happening. Completely transparent, you know, systems connected via, you know, NAS or SAM, they just, they think they're reading and writing data and it's cool. And it's, we're encrypted at rest, right? You know, that sounds really good. So one of the things about this, if we look at this and say, how well does this kind of encryption protect our data? Let's say, say we had something like this and you know, it does meet compliance requirements, we check that box that, you know, hey, it's AES encrypted at rest. But what happens if we have a data breach? So attacker comes in, we'd actually do a flowchart, a real simple flowchart. Attacker tries to access the data. Was the storage frame on? Ah, bummer. The encryption did not protect our data. Was the storage frame off? Hey, we win. We protected our data. So you have to, you know, that's one of the things that when people say encrypted at rest, you really have to understand what kind of threats that protects against. So, you know, we look back at the storage frame example on the ground, you know, it protects against a pretty narrow model of threats. Like say, you know, I have some bad drives and the EMC dude comes in and to replace them and he's taking them back to the depot and a couple of fall off of his bicycle. You know, that's, you know, I can say, you know, those drives were encrypted at rest. They were powered down. They weren't spinning. So this form of encryption, if you think about this, this thing that people say, oh yeah, it's encrypted at rest. You know, it just protects against this very narrow threat. So when somebody says this, hey, my data's encrypted at rest, whether we're talking cloud or ground, you really need to dig a lot, lot deeper. So let's dive into the cloud. Now, first of all, I'll say, you know, not all data should be in the cloud. You really need to think about risk modeling, about, you know, understanding what your threats are, your compensating controls. And I'm not, I'm not here to bash cloud. You know, I think, you know, AWS, Azure, people are using it successfully in a lot of cases, but a lot of people are not thinking about cloud implementations of cryptography that actually protects data. And you know, so AWS, it gives you all this amazing functionality to do all sorts of stuff. It's almost, it's staggeringly complex. There's so many different things you can do with AWS. It's like every week I get an email, the new things they're adding to it, and it's like, wow, wow, wow. And it's like, I don't know how you can stay up on it. But, and actually I'll say AWS does give you some primitives that can apply a certain level of encryption to do things reasonably well for certain use cases. But you really have to do proper systems engineering in this because if you don't, this stuff is not gonna be encrypted against the threats you care about. Like, you know, somebody actually trying to take over your system and steal your data. Now, you know, there is some interesting differences like in AWS, I don't know if you looked at it, but they've got different, they offer different geographies. And I'll just say some of them are kind of interesting like China has stripped out all the encryption, even the encryption built into the platform. It's got no IAM or two factor authentication. And so that might have some security implications in what you're building. So, so as we get into, let's take a really simple example. So a simple building block is S3 encryption. It's used for user for all sorts of stuff. It's a basic fundamental piece of technology for storing a chunk of data. Now, a lot of people don't necessarily realize this, but there's actually quite a few different ways you can encrypt S3 data. So there's a server side encryption options include server side with the key managed by S3, server side with the key managed by KMS or Amazon's key management service. And you can also do server side encryption with customer managed keys that you manage, say in a variety of ways, it could be outside of KMS. And then there's actually client side encryption options, which can make a lot of sense to encrypt data before I ever stuff it up in there. But just this very basic primitive of quote, encrypting data and S3 has got a whole bunch of different ways to do it. So like say I'm a dev and I'm trying to figure this stuff out and I look at S3 and here's this default encryption. It's a checkbox. That looks really good to me. I love doing stuff with checkboxes because I can go on, I can think about the application development, I can think about all this stuff, the wonderful things, the business benefits, my app's gonna do and I can check that box and security folks are gonna be happy. And there are some kind of interesting things about the way Amazon does this with the S3 encryption. They actually encrypt each bucket with a unique key, which is good. You don't have this shared key that unlocks a whole bunch of stuff. They encrypt the key itself with a master key that it rotates regularly. Yeah, that's kind of cool. Key rotation, critical part of controlling your encryption keys. Again, it uses one of the strongest block ciphers available. This is right from the marketing material, AES-256 to encrypt your data. So this looks really easy to me. I can check a box and I'm done. But it's not really that simple. And so for an analogy, I would like to talk about physical system. So taking this context of an S3 bucket where it's doing this automated encryption, if I apply it to a door, a door that I want to secure in a room that's got some stuff in it that I want to protect, I can go out and I can buy a really nice deadbolt. These are really good deadbolts. There's probably somebody in Lockpick Village that knows a way of opening these, but for most of us, I know I can't pick that deadbolt. I probably can't saw it. It's designed to not be beatable open. And imagine this deadbolt in front of this door and it's protecting people from going in, grabbing the stuff I'm trying to protect and walking out. So this is kind of similar to our S3 bucket. We want to make sure the right people are going in and getting our stuff. But I would kind of assert that that last example of saying apply the default encryption to S3 is a little bit like having this massive door, this really nice deadbolt, but leaving the key in the door. Now that doesn't really protect that data, right? Because anybody that can walk up to that door, they see and they can turn the walk. So I mean, they may have to do some positioning to get in front of the door. Maybe to take it back to the controls you might have in a web application. Maybe they tunnel up through the floor, cut through the ceiling or punch in a wall. But if they can get in front of that door, that key's there, they just turn it and walk through. Grab your stuff and walk out. So this is kind of a design pattern that is not so great. Well, we can actually point to it, we can say it's encrypted, we can sign a paper that's encrypted at rest for this code encryption. But it's actually not really very effective in stopping people from walking out with our stuff. So there's a principle, the Kirchhoff's principle, that's kind of famous and says any crypto system should be secure if everything is known about the system except for the key that that can all be public knowledge. Well, if we're not managing our keys correctly or properly or securely or we're leaving them in the door lock, we certainly aren't really controlling this system from a cryptography perspective. We're failing. So just maybe I'm saying that if we check that little checkbox and say using S3 server-side encryption with keys that are managed by S3, which sounds so easy because it's just a checkbox, maybe that isn't the protection that we wanted or needed. So let's go on to the next way of encrypting data in S3. And remember, I'm just talking about one service in all of these different ways of encryption. I can use server-side encryption, but instead of having S3 managed keys, I can put those in AWS KMS, which is their Amazon's key management service. Now that comes with some kind of interesting things that I'm gonna dive into. There's a lot of different ways. You can set up Amazon KMS and I'm gonna get into those. So here's, I just changed the checkbox and I select the key that I provisioned in KMS and I'm off to the races. Sounds pretty good, right? Now, maybe I'm a dev and say, okay, well, now I just got to generate a key thingy and now I just encrypt and now I'm good. Now KMS can be used for a lot of things. They've designed it to integrate with all their services. You've got S3 buckets, EBS, Glacier, do long-term storage. You've got RDS for relational database services. So it is pretty cool. I can build this simplified infrastructure, somebody that's trying to build cloud apps and I'm just trying to get my thing out the door. I can use this KMS thingy to hold the keys and that sounds kind of good because well, because it says it manages keys and it's like, well, it's gotta be better, right? Well, let's dive just a little bit into KMS and see if some of the problems that we had with the key in the lock with the deadbolt if we can see how we can stay away from those. Well, Amazon's key management service is pretty interesting. And actually, as in everything Amazon, there's like five ways to do things. I can, in key management services, I can use AWS managed customer master keys, CM keys. And these are keys that are created, managed and used on my application's behalf by the AWS service that is integrated with AWS KMS. I can also use customer managed keys. So rather than just letting Amazon just kind of do it automatically, I can actually use a customer managed key and I can do some extra things with that. It's kind of cool, some extra controls that I would argue maybe wise on applications with very critical data. So these things, these include things like enabling and disabling the CMK, which actually is an important thing to come to later, is if something's bad's happening and you can detect it later on in the stack, I can disable that CMK and actually prevent it from being used. So I can re-rotate it's cryptographic material. I can also set up IM policies or identity and access management policies that cover access to that specific CMK. I can use that CMK and cryptographic operations and I can do encryption as part of my code, which is kind of cool. And but the important thing is I as a customer maintain control of that CMK. Now there's data keys and those live outside KMS. KMS doesn't manage or control those and there's customer master keys, key encryption keys and data encryption keys. So we've got a little bit more complex in that dev that just wanted to click a box and say, yeah, I want this thing encrypted. Now there's a whole lot of things to talk about or think about or design into. Multiple ways of encrypting with S3 and then if I use KMS, multiple ways of managing KMS. So some things you might be thinking about. It's like, well, what does this give me using doing customer managed keys? Well, I named a few of the benefits. Like I can do my own rotation, I can actually disable and there's some kind of cool things that I can do. It gives me a little more fine tune control and I'm gonna go into the permissions in a bit, which is even maybe better. But some of the things, when I'm generating keys, one of the things that's really critical to me is using a known good source of random. I think I believe KMS has got FIPS 140-2 rating and they're working on certifications, but picking random for a key generation is a really big deal. And in cryptography, we've seen this fail over and over and over and over again. It's like a long list of failures of poor random being used to generate a key and the system gets owned. So this thing about generating a key, you wanna really be careful or understand where your random comes from and that may give you a reason why you should be generating your own keys. There's also kind of another thing that another reason maybe to do this in customer generated keys is if you think about the clouds, sometimes they turn dark and stormy and violent. And if you don't have your cryptographic key material for your applications stored somewhere safe on ground, you could set yourself up for a pretty significant availability issue because now you've got encrypted data and no keys to access the application. But the selection of random and cryptographic key generation as I'm sure everybody knows here is a really, really big deal. So I'm gonna go slide back into the KMS and on that second option, customer mastery, CMKs that are customer managed. Wow, that's a hard one to say. Customer master keys that are customer mastered, managed. So there's, again, it's everything in AWS. There's a variety of ways. So we were talking the multiple ways of encrypting S3 and multiple ways of using KMS. And now we're gonna talk about multiple ways of applying controls to these keys, which is kind of interesting. There's three things that I can use to apply what controls access to these encryption keys. There's a key policy document that describes usage of the key I'll show you in a second. There's IAM policies or identity and access management policies. And these, you can use those in combination with the CMK key policy to allow access to a CMK. This actually gets kind of complicated to simulate. There's an IAM policy simulator tool that Amazon has provided to kind of help figure this out because I've been in the position of trying to review like what has access to this key and it is non-trivial to dig into sometimes. And then the third way of applying controls to this key is grants. And these are kind of cool because you can then specify with a high degree of granularity exactly what service and what thing can use use a key for and how. And that's really important. There's, and I'll show a couple examples of the key operators and how they can be different with grants, which is kind of neat. And they're an alternative to the key policy. So we started the S3 in multiple ways of encrypting, KMS, multiple ways of doing KMS. And now we've picked this one option, customer master keys, we've got multiple ways of doing this. There's a lot of permutations here and a lot of minefields for devs. Here's a simple key access policy and don't believe me, this is not real. So yeah, you own my system. So nothing about this, this is all fiction also. But this would be typical for a key administrator or a custodian. So this in key management, one of your principles is you want to have a separation of duties. You want to have people, maybe DevOps people and developers that are putting applications together and they have a permission to have an application, tie a given key to an application and that application has permission to use a key to do something. But then you typically have another team if you're doing it right, with a separation of duties that has management capability on those keys. And so this has got some things like disable, delete, schedule key deletion, cancel key deletion, revoke. So these are some more administrative level things when you have that separation of duties for key management. So this is, oh yeah, it's also possible to constrain a CMK so it can only be used by a specific AWS service through the use of a KMS via service conditional statement. So I can actually really nail this key down and say, this can be used for this one thing period which is pretty cool. I can kind of limit the usage of that key. Now here's kind of a couple of slides showing some differences of key access grants. Now I may wanna bisect my application and say, I have some internet forward-facing logic where people enter something into a form. And that's what they do. Random people connect to the internet, enter some stuff in a form and it goes in. There's an auth function, some other stuff. And then I got a separate team of people that work for the company that connect to the same system and they need to do some management functions. They need to do some lookups, maybe some edits, check some stuff. So if you bisect your application so you have the internet-facing logic and you have configured it, for instance, to where that internet-facing logic can only have access to the encrypt function of that key. That's all it can do. It can encrypt, period. It can encrypt. So even if that application gets owned, it doesn't have the rights via this grant to decrypt any data. So the attacker that got root on that box, they do not have the ability to decrypt data with this grant. Now maybe you have a separate network, maybe through a direct connect or a VPN where your people doing the management on the system, the maintenance of it or the application owners, they maybe, they quite likely need the decrypt function. So this is an example of using these different grants to give different parts of the application different permissions and help build a little bit more defensive depth into your app and say, the internet-facing stuff, we don't want them to ever be able to decrypt any data. So I've been talking, I was working my way through S3 buckets and encryption. Now there's the last one, server side encryption customer with keys that you manage, maybe outside KMS or with a different system. And then there's also client side encryption options. And I really do like those because you get a fine grain control over your data of what you're encrypting. If you think about it, if I control the encryption, I get data encrypted before it's ever stuck in S3, I don't have to worry about what happens when somebody screws up permissions on that bucket or changes on ACL or something like that. I think that's consistent with ISO 27040 using encryption to actually create these partitions of who can access things. And I think that that client side encryption, if you encrypted before you put in S3, you won't be in the headlines about, and you manage it, you keep those keys secured and that full process that encrypts the data and acts on it, you will not be in the papers, which is really good. So, you know, there's also not just the door. And I think one of the things, you know, to extend this a little bit and kind of the story I'm building, if you know that first story I talked about that door and I've got that awesome deadbolt on, I can point to it, say that's my FIPS 140-2 rated deadbolt and you know what, I can't beat this thing open, I can't pick this lock, but I'm gonna leave the key in the door and people walk in and out of my stuff on screwed. Now, you know, I don't know how many of you have been to a commercial data center, but the process to get in is typically a little more involved. You walk up to a bulletproof window and you provide your identification. They perform visual identification against your ID. They then look in the computer and see if you're authorized to be there and say, yeah, you have a ticket to go in and do X and Y and Z at this time, this all looks right. And then rather than you going and turn the key in the lock, they buzz a door into a man trap and you're going that, and you stand there and to get out of the man trap and to proceed, you need some additional credentials with some badging and some two-factor token and stuff and then that gets you out and then you're in. Now, there's also, there's a human involved in these logging stuff that you went in there, you had a ticket to go in and do X, Y and Z. And hopefully they're, you know, and they're typically awake enough to say, yeah, you come in here every three months and you do a thing and you leave. Now, if I come in and I've made four trips in and out in a day, that's unusual. And if I try to hold boxes out, that's like double unusual because we're not supposed to be hauling boxes out. So it's like, that's a detective control built around that, you know, the authentication, the authorization check and all that. And so we've built a little bit more controls over whether I can walk out of the stuff. Now, with AWS, those are some of the things we need to be thinking of as we're building applications. It's not like, is, are we using strong encryption? It's not doing bupkis to actually protect the data. We need to build these controls, these additional things, these additional layers around the application to do this properly. So, there are other ways of managing encryption keys in AWS, of course, there are. There's many, many different ways to do these things. So, whoops, I just lost, oh, scared me. I thought, oh no, I went dark. I'm panicking. It's like my laptop's plugged in. It's like I was freaking out for a second. But oh shit. So, Amazon actually has had a variety of things for doing key storage that aren't KMS. They had Cloud HSM V1 or the Classic HM. And that's just a, just a simple Gemolto hardware security module. A hardware security module, if you don't know, is this specialized box that's designed to have secure random generated encryption keys and protect them in hardware and tamper proof kind of systems to ensure that these keys can't be compromised. So, HSMs are used for serious key management, for keys that have some pretty big implication if they were ever to be compromised. So, if you're not familiar with an HSM, they had Amazon, they still support it in a couple of the regions. Cloud HSM V1, which is the Gemolto Luna. And they also, they produced an HSM V2, which is kind of interesting. They've kind of produced their own. And they submitted it for a FIPS review. And then, you know, there's third party key management solutions. I listed one, there's a bunch of different ways to do this. There's different HSM vendors, there's different key management solutions. And this is, you know, if I had like a data do this, I could talk about a whole bunch of different ones, but I got an hour or so and I kind of focused on one. But that's another thing that can keep keys securely. So, this is kind of interesting. You know, this Amazon is submitted for FIPS validation, their cryptographic module validation. And it's, they got the stuff on it. It's got some interesting design aspects to it. I really encourage you, if you're storing encryption keys and you're doing it in hardware, should actually read these module verification documents. They're fantastic, they're a wealth of knowledge. And how these things are protecting encryption keys. And what kind of threats? And what was their threat model? What's the security boundary? And how are these tested? And what do they protect against? And if you dive into these NIST documents, it's a really cool way of understanding a lot better. And you can also ask some interesting questions when you're talking to the AWS people, for instance. So, as I talked about that option, you know, there's also HSMs that we use for key management from Jamalto, from Talus. Jamalto is a big player in this stuff. If you've got a cell phone or a US passport with a chip or a credit card, yeah, technology was made by them. I'm not a shill for the company, but they do make a lot of stuff. So, there's, this is an example of a pin entry device that's used with Jamalto equipment. And there's an important principle, it's sort of two-factor, we all gotta use 2FA now, that's kind of common sense. But there's some additional things in here and that we can use K of N or M of N operations. So, we say, we've got these five people on this team and we wanna have at least three of them come together to do this operation. You can specify that and say, we wanna do this operation to transferring these keys to this one to this other thing and we wanna make sure it's done in a very controlled manner, we wanna make sure there can't be collusion or an individual just can't go off the rails and say, I'm gonna steal all the encryption keys and go sell them to the Russian black market or something like that. So, with these kind of systems, you kind of get beyond the Amazon, hey, I have a key, I can do a thing and you say, we not only have a key to do a thing, but it takes multiple of us to come together to do a thing. And then, because we can set it at any ratio we want, say we need three of five or four, seven or whatever it is we want and to solve the, oh my God, Marie got hit by a bus problem. So, if I get hit by a bus or something like that or just have too much fun at DEF CON and never go home, there are people that can carry on. So, this is kind of cool. Having more than one user request required to do critical encryption operations of such as transfer of keys and backing up of keys. Because remember that this whole confidentiality, availability, integrity, if we lose keys, that data is like gone. So, we've seen that in a few, being weaponized as a service now, but causing encrypting data and hiding your keys for ransom. But, when we're hosting stuff in the cloud, we really have to think about that. It's like, we wanna make sure that we can get this back, assuming an asteroid hits a data center or something like that. We wanna be able to get the data back. So, having a way of replicating keys across geographies in a secure way under a very controlled environment between like three trusted people or something on a team is a good way to do it. This concept of crypto officers versus crypto users. And, just, this is a total I chart, but there's actually some kind of cool things I'll talk about that, as we get into some of these third-party solutions that I think are neat. And actually one you can do is you can actually say, you know, maybe the keys, and you gotta use this, you gotta throw up all of your application, you gotta understand what is your data, what is your trying to protect, what is the blast radius if this is breach? You may actually wanna keep your keys on ground. You may not want them in the cloud. And so you can do things like say, you know, we wanna have a Gemalto or, you know, for that matter, you know, the other with Azure, a Tullis, HSM on ground, and we wanna do our key management on ground. We wanna have our hot apps call for those keys. That gives us a little bit more control. We can see what's happening. We can rack a little quicker. We know there's, you know, we know we own the keys in there. They were never up there. So, you know, push comes to shove, we can cut off access to it, and that stuff's encrypted. And nobody can get at it. But there are some kind of cool things. You know, if I've got my key management on ground, I can go into the data center and I can love it and touch it and watch it's blinking lights. It's just neat. It's cool. And know that it always right in the universe that my key is protected in a very safe environment. So, you know, that gives us, also gives us a fallback, you know, when the cloud turns stormy and black and parts of it evaporate because of whatever, we actually have our critical encryption keys. We maintain control of them. There's some kind of cool things we can do this as we start applying these third party solutions to encryption problems. So, let's take a database. And everybody's, you know, God, how do we encrypt a database? And, you know, running through a couple examples like, you know, if you use SQL Server Enterprise, last version, you'd use transparent data encryption. Sounds super easy. It is. It's really easy. It's turn it on and just use it. Just works. And your data's encrypted at rest, which is just pretty cool. Now, if you think about that threat model earlier and say, you know, well, what are the implications of this? It starts to analyze it. Well, one thing now that that's given me is by using the prior version of SQL Server data encryption, data encryption, transparent data encryption. So, I make a copy or if I make a backup of that database and throw it somewhere and leave it and don't set access permissions to it, that's actually encrypted. So, it keeps a person from getting at a database backup, which is awesome. Now, cloud introduces an interesting problem because, you know, on the prior version, you know, the transparent data encryptions, they may get the whole VM. You know, the whole running instance in the cloud. If they do that, you're kind of screwed because they got the encrypted data, which is in the database, and they got the key, which is in the registry. So, if they got a copy, snapped the VM, they had everything they needed to reconstruct that, which sucks, sucks for you. And so, you don't want to suck, you want to suck less. So, one of the things you can do with the new SQL Server Enterprise, you can do key offloading. So, you say, I don't want to store the key in the registry, I want to store it in this strong key management system. Now, this can be actually in the cloud or actually on ground. And then with solutions like, with the gemalta solution, they take it a step further and they can say, they can apply an encryption, for instance, so you can say, these stored and stored procedures get privileged access to be able to utilize this key for a decryption. So, maybe I got a customer by lookup name or something and it has access to be able to get to this decryption key to this key to actually perform this customer lookup. And so, I've got these stored procedures that are defined in this application that can actually utilize this trusted connection to a strong key management and use these keys to perform operations. Now, when somebody does, somebody pops your app and they're doing a SQL injection, select stored users, one equals one. Hopefully, you didn't define that as a valid stored procedure, just saying. If you didn't, that won't be one of the stored procedures that can be used. And instead of vomiting up the unencrypted user table, it will vomit up the encrypted data and the attackers got this. There's some other things too, like with protect file, I can do things like apply some extraordinarily fine-grain permissions on files. So, I can say, I've got these files that have this really important data in them and I don't want to be able to get at them. And I can say, this service account ID running this binary from this IP, this machine, can transparently read and write these files into that application that looks like they're decrypted. But if I pop a root on the box and my shell is bash or whatever, I've got nothing, I just get, I get that data back in an encrypted form. So, I mean, those are some of the extended, more deeper layers of encryption we can apply to stuff. So, why would, why should I manage my own keys? I mean, Amazon's got a thing, they managed keys. There are some standards bodies and some frameworks that say, you know, maybe we should be kind of hanging on to our encryption keys. You know, this is a good one, high trust, you know, it has some verbiage in it. Well, you need to use validated cryptographic modules, that's kind of a no-brainer. You need to store keys separate from the data. And key management and key usage need to be separation of duties and keys shall not be stored in the cloud. There's also the new NIST that's the 853-5, which is in draft and I love the wine, maintain exclusive control of cryptographic keys. And remember, when you're in the cloud, you're running on someone else's computer, your keys are up there and I kind of parse this because there's ways of keeping Amazon from getting at it but there's, you're putting the keys someplace else where people that have access to that application tend to have access to it. So it's kind of a complicated question about, you know, it's not like Amazon gives away your keys, but by provisioning an application to use those keys, you can allow an attacker to utilize them as well. And they're way different than you intended that application to work. So you intended the application to a certain thing for a people and he's using that same application to suck out all your data and sell it. So again, maintain exclusive control of cryptographic keys, I love that line. And so if an application makes sense to use Amazon KMS, again, you've got to look at your threat modeling, your application, what is the risk of the data you're storing up there? There's a lot of cases where it makes sense to use KMS. This extra stuff I'm talking about just, it doesn't fly, it's not worth the expense, the time, the configuration. You know, there is this whole continuum of data risks, you know, some data is low risk, some's high. But you should use, if you're using KMS, you should only use the FIPS 140-2 certified endpoints. And they've got a table of them. That's one of the things people screw up on is they don't realize that not all endpoints are FIPS 140-2 certified. You have to design your system and architect it. So you've got a separation of duties and hopefully some, using split keys, K of N, Shamir is sharing secret, it's really cool to split up a key into eight parts so any four people can come together and rebuild that key. So no one person has all the information needed to own the thing, and you have Marie got hit by a bus problem. And then employ key usage, monitoring, alerting and responses. So right now AWS has best practices for using KMS. They actually say to do some things, but nowhere does it actually say how to do it. And this is really kind of, this is the hard part. You should be monitoring for data plane operations and control plane operations, but like data plane operations, quantitatively saying, you know, this application normally calls this decryption key 200 times an hour. It just called it 2,000 times in five minutes. Something very different's happening. So if I'm using those grants for instance, I can actually detect that and say, I don't know what's happening, but I think a lot of data is leaving the building and you can actually flip that and revoke access to that key until you investigate, do an incident response, figure out, hey, did somebody just breaching me and at least stop the bleeding. There's also control plane operations. So somebody, somebody, sand attacker gets in and they want to, you want to start deleting some of your CMKs. I would argue you should definitely know if something's happening to your CMKs. You know, delete key, schedule key deletion. It's kind of a big deal. You know, you do want to do that as part of normal key lifecycle maintenance, but that is a big deal. Also, you know, building systems to do this alerting. It's really hard work. It's frustrating because people say, well, just use Splunk and shit, you know, which is like, that's not really an answer. You know, this is kind of a, this is a really kind of a complex problem. I guess, you know, my approach, I have a girlfriend who has a PhD in statistics and she's really awesome at figuring out this kind of stuff. If I can tell her, these are the things I'm kind of looking for that I think represent a problem and she can help me build stuff. You know, this is the math. This is how we'd apply a statistics solution to look for that. And so I would advise all of you you're doing this stuff, get a girlfriend with a PhD in statistics. I don't know, just saying. That's, you know, I want to produce some additional stuff and you know, this would be like a full day workshop instead of a one hour talk, but there's kind of some principles on there. But anyway, encryption and key access controls, you really need to design a plan. I'm amazed at the number of devs that, or you know, when I analyze applications, we're made by third parties. It's like, you know, do you have the documentation of how you assign, you know, grants and I am policy and KMS policy? You're going to obfuscate all this stuff, please do. But do you have any documentation? He said, well, no, I guess the dev just did it until it worked. It's like, that's, I guarantee you, that's going to be a problem. I've seen that in third party apps, which is suboptimal to say the least. So you really need to build out that, you know, plan this, build out those I am policies, encryption usages and the context. And this really needs to happen in the application design phase. This is not something that I can just swoop in and fix some stuff later on. So in conclusion, encrypting data in the cloud, it's very complex. And I just led you through just something really simple. I want to put a thing in an S-free bucket. You know, there's all these different kinds of choices you have to make. And there's no, it's complex. There's no magic answers. But encrypting data to actually protect it in the cloud is more than just a checkbox. And you know, we tell devs to never write their own crypto, we've taught them that. But now with the complexity of cloud and some of these encryption solutions, a large number of design choices, we need to embed with devs and we need to help them implement cloud cryptography architecture. And that's gonna be really critical. I think that this is, we're not gonna get ahead of this problem unless we sit down with the devs and say, let's talk through some of the aspects, what we're trying to do. And multiple completely different ways of encrypting something, like a simple S-free bucket and a multiple ways of using KMS or external key management. So you need to think about the threat model. That is so, so, so critical. So we wanna make sure that attackers can't decrypt our data by virtue of standing in front of the door and turning the key. We wanna add some additional controls like that guard station, authenticating, you know, understanding your authorization or monitoring. We have to engineer these cloud cryptography solutions properly to protect the data. And just to recap, there is no magic crypto fairy dust that I can parachute in with at the end of a project and somehow sprinkle that stuff on there and secure an app, it can't be done. I wish I could, I'd be a millionaire, but you know, I do have glitter, but that's, I don't know. So anyway, I'm not sure where I'm at on time. It may be getting close. Yeah, we have about 10 minutes left for questions. If you have a question, please come on up to the mic. And if you don't feel comfortable, you know, we're recording this. So if you'd rather not be recorded on the mic, please approach Marie after the talk is over. So we have 10 minutes, come on up. And first let's give a big hand to Marie for an awesome talk.