AWS Security Profiles: Ken Beer, General Manager, AWS Key Management Service

In the weeks leading up to re:Invent, we’ll share conversations we’ve had with people at AWS who will be presenting at the event so you can learn more about them and some of the interesting work that they’re doing.

How long have you been at AWS, and what do you do in your current role?

I’ve been here a little over six years. I’m the General Manager of AWS Key Management Service (AWS KMS).

How do you explain your job to non-tech friends?

For any kind of product development, you have the builders and the sellers. I manage all of the builders of the Key Management Service.

What are you currently working on that you’re excited about?

The work that gets me excited isn’t always about new features. There’s also essential work going on to keep AWS KMS up and running, which enables more and more people to use it whenever they want. We have to maintain a high level of availability, low latency, and a good customer experience 24 hours a day. Ensuring a good customer experience and providing operational excellence is a big source of adrenaline for service teams at AWS — you get to determine in real time when things aren’t going well, and then try to address the issue before customers notice.

In addition, we’re always looking for new features to add to enable customers to run new workloads in AWS. At a high level, my teams are responsible for ensuring that customers can easily encrypt all their data, whether it resides in an AWS service or not. To date, that’s primarily been an opt-in exercise for customers. Depending on the service, they might choose to have it encrypted — and, more specifically, they might choose to have it encrypted under keys that they have more control over. In a classic model of encryption, your data is encrypted at storage — think of BitLocker on your laptop — and that’s it. But if you don’t understand how encryption works, then you don’t appreciate the fact that encrypted by default doesn’t necessarily provide the security you think it does if the person or application that has access to your encrypted data can also cause your keys to be used whenever it wants to decrypt your data. AWS KMS was invented to help provide that separation: Customers can control who has access to their keys and enable how AWS services or their own applications make use of those keys in an easy, reliable, and low cost way.

What’s the most challenging part of your job?

It depends on the project that’s in front of me. Sometimes it’s finding the right people. That’s always a challenge for any manager at AWS, considering that we’re still in a growth phase. In my case, finding people who meet the engineering bar for being great computer scientists is often not enough — I’ve got to find people who appreciate security and have a strong ethos for maintaining the confidentiality of customer data. That makes it tougher to find people who will be a good fit on my teams.

Outside of hiring good people, the biggest challenge is to minimize risk as we constantly improve the service. We’re trying to improve the feature set and the customer experience of our service APIs, which means that we’re always pushing new software — and every deployment introduces risk.

What’s your favorite part of your job?

Working with very smart, committed, passionate people.

How did you choose your particular topic for re:Invent this year?

For the past four years, I’ve given a re:Invent talk that offered an overview of how to encrypt things at AWS. When I started giving this talk, not every service supported encryption, AWS KMS was relatively new, and we were adding a lot of new features. This year, I was worried the presentation wouldn’t include enough new material, so I decided to broaden the scope. The new session is Data Protection: Encryption, Availability, Resiliency, and Durability, which I’ll be co-presenting with Peter O’Donnell, one of our solution architects. This session focuses on how to approach data security and how to think about access control of data in the cloud holistically, where encryption is just a part of the solution. When we talk to our customers directly, we often hear that they’re struggling to figure out which of their well-established on-premises security controls they should take with them to the cloud — and what new things should they be doing once they get there. We’re using the session to give people a sense of what it means to own logical access control, and of all the ways they can control access to AWS resources and their data within those resources. Encryption is another access control mechanism that can provide strong confidentiality if used correctly. If a customer delegates to an AWS managed service to encrypt data at rest, the actual encipherment of data is going to happen on a server that they can’t touch. It’s going to use code that they don’t own. All of the encryption occurs in a black box, so to speak. AWS KMS gives customers the confidence to say, “In order to get access to this piece of data, not only does someone have to have permission to the encrypted data itself in storage, that person also has to have permission to use the right decryption key.” Customers now have two independent access control mechanisms, as a belt-and-suspenders approach for stronger data security.

What are you hoping that your audience will take away from it?

I want people to think about the classification of their data and which access control mechanisms they should apply to it. In many cases, a given AWS service won’t let you apply a specific classification to an individual piece of data. It’ll be applied to a collection or a container of data — for example, a database. I want people to think about how they’re going to define the containers and resources that hold their data, how they want to organize them, and how they’re going to manage access to create, modify, and delete them. People should focus on the data itself as opposed to the physical connections and physical topology of the network since with most AWS services they can’t control that topology or network security — AWS does it all for them.

Any tips for first-time conference attendees?

Wear comfortable shoes. Because so many different hotels are involved, getting from point A to point B often requires walking at a brisk pace. We hope a renewed investment in shuttle buses will help make transitions easier.

What’s the most common misperception you encounter about encryption in the cloud?

I encounter a lot of people who think, “If I use my cloud provider’s encryption services, then they must have access to my data.” That’s the most common misperception. AWS services that integrate with AWS KMS are designed so that AWS does not have access to your data unless you explicitly give us that access. This can be a hard concept to grasp for some, but we put a lot of effort into the secure design of our encryption features and we hold ourselves accountable to that design with all the compliance schemes we follow. After that, I see a lot of people under the impression that there’s a huge performance penalty for using encryption. This is often based on experiences from years ago: At the time, a lot of CPU cycles were spent on encryption, which meant they weren’t available for interesting things like database searches or vending web pages. Using the latest hardware in the cloud, that’s mostly changed. While there’s a non-zero cost to doing encryption (it’s math and physics, after all), AWS can hide a lot of that and absorb the overhead on behalf of customers. Especially when customers are trying to do full-disk encryptions for workloads running on Amazon Elastic Compute Cloud (Amazon EC2) with Amazon Elastic Block Store (Amazon EBS), we actually perform the encryption on dedicated hardware that’s not exposed to the customer’s memory space or compute. We’re minimizing the perceived latency of encryption, and we all but erase the performance cost in terms of CPU cycles for customers.

What are some of the blockers that customers face when it comes to using cryptography?

There are some customers who’ve heard encryption is a good idea — but every time they’ve looked at it, they’ve decided that it’s too hard or too expensive. A lot of times, that’s because they’ve brought in a consultant or vendor who’s influenced them to think that it would be expensive, not just from a licensing standpoint but also in terms of having people on staff who understand how to do it right. We’d like to convince those customers that they can take advantage of encryption, and that it’s incredibly easy in AWS. We make sure it’s done right, and in a way that doesn’t introduce new risks for their data.

There are other customers, like banks and governments, who have been doing encryption for years. They don’t realize that we’ve made encryption better, faster, and cheaper. AWS has hundreds of people tasked with making sure encryption works properly for all of the millions of AWS customers. Most companies don’t have hundreds of people on staff who care about encryption and key management the way we do. These companies should absolutely perform due diligence and force us to prove that our security controls are in place and they do what we claim they do. We’ve found the customers that have done this diligence understand that we’re providing a consistent way to enforce the use of encryption across all of their workloads. We’re also on the cutting edge of trying to protect them against tomorrow’s encryption-related problems, such as quantum-safe cryptography.

Five years from now, what changes do you think we’ll see across the security and compliance landscape?

I think we’ll see a couple of changes. The first is that we’ll see more customers use encryption by default, making encryption a critical part of their operational security. It won’t just be used in regulated industries or by very large companies.

The second change is more fundamental, and has to do with a perceived threat to some of today’s cryptography: There’s some evidence that quantum computing will become affordable and usable at some point in time — although it’s unclear if that time is 5 or 50 years away. But when it comes, it will make certain types of cryptography very weak, including the kind we use for data in transit security protocols like HTTPS and TLS. The industry is currently working on what’s called quantum-safe or post-quantum cryptography, in which you use different algorithms and different key sizes to provide the same level of security that we have today, even in the face of an adversary that has a quantum computer and can capture your communications. As encryption algorithms and protocols evolve to address this potential future risk, we’ll see a shift in the way our devices connect to each other. Our phones, our laptops, and our servers will adopt this new technology to ensure privacy in our communications.

The AWS Security team is hiring! Want to find out more? Check out our career page.