Amazon CSO Steve Schmidt preaches fungible resources, MFA

From a security perspective, Amazon has changed drastically during the past decade, as the retailer has become the world's biggest cloud provider.

Perhaps no one knows those changes better than Steve Schmidt, who was named CSO of Amazon earlier this year after several years as head of AWS security. During the keynote at the 2022 AWS re:Inforce conference last week, Schmidt discussed the enormous security challenges AWS has faced as the company has grown, tracking quadrillions of events each month across its cloud infrastructure. And, while the company once again added more security tools and features to its ever-growing suite of offerings, Schmidt said some of the smallest steps, such as enabling multifactor authentication (MFA), can have the biggest impacts in terms of shrinking attack surface for customers.

SearchSecurity editors Rob Wright and Arielle Waldman spoke with Schmidt about the transition to his new role, the shifts he saw during his time as AWS CISO and an evolving threat landscape for cloud providers and customers. In part one of the Q&A, Schmidt discussed how AWS is spurring MFA adoption, Amazon's shift to more fungible IT resources and the security benefits of that shift.

Editor's note: This interview has been edited for clarity and length.

What has the transition to the new role been like for you?

Steve Schmidt: It's been fun. I was in AWS for a long time -- for 14 years. And what's really enjoyable about my new role is I get to learn things because I don't know anything about how you build satellite systems, or robots, or self-driving vehicles or any of that stuff, so it's so much fun to learn about that business and to see what we do there.

Are there any overlaps in the roles or lessons you've learned at AWS that you can take to the new position?

Schmidt: There is absolutely a lot of overlap. When you look at security, it's really something that has a bunch of fundamental underpinnings. Can you see everything that you need to see to understand what's there? Can you measure how it's doing in comparison to what your security goals or requirements are? And can you affect change when you need to in that environment? And change can be something as simple as are you able to patch [a vulnerability] to something a little bit more dramatic like Log4j -- what do you do when something giant comes along? And there are a lot of similarities across all of the businesses. One of the other things that we've got as a company, of course, is that most of the company runs on AWS. There are relatively uniform tools that we can apply across a lot of those different pieces.

What was it like going from the FBI to Amazon?

Schmidt: It was really interesting. The way I landed at Amazon is kind of a fun story. In 2006, I was running a team that did intelligence analysis. If we picked up a laptop in a cave in Afghanistan, my team's job was to compare the content on that with everything that we had on intercept systems to see if there's linkages and if somebody's communicating back and forth. We were a big customer of all the disk storage vendors, and we kept filling up file systems, and it was a pain. We saw this thing called Amazon S3. We said, 'That is what we need!' We approached Amazon and said, 'Would you build one of these for us, please, because this will relieve a lot of headaches that we have.' And it turned into a conversation where they said, 'You guys seem to know something about distributed systems -- do you want to build these things, as opposed to being a customer?' And we said, 'Well, that sounds fun, but we don't want to move to Seattle.' And Amazon said, 'Alright, we'll open an office in Virginia for you.' And so the team that came over here that I ran built software. We built virtual private clouds; that was our first gig. And I did that for about a year and a half. And then we started looking for someone to run security for AWS. Andy [Jassy, Amazon's CEO] did that for a while, and he got tired of it. And he pointed to me and said, 'You're it.' I said, 'I don't want to do it.' He asked why, and I told him it's because security teams slow down companies; I've seen that having worked in the government.

And his response was typical Andy, which was: 'Interesting and congratulations -- you're it.' His response exactly was that I seemed to have a good handle on the problem, so go fix it. And it's been absolutely fun because I got to do two things that I love. One is building an organization. And the second is building tools. Nobody's built things that operate at the scale we have, from a security perspective. You can't buy stuff off the shelf that works on the number of systems that we have. And it's a lot of little things that people don't even think about that make a huge difference. If you look at those agents that are sitting on your laptops, the vendors are saying, 'I would only use this 5% or 6% of the memory.' When you look at our fleet, 6% is millions and millions and millions and millions of dollars. It really, really matters. And stability, of course, matters for anything else for that kind of environment. So, that's the story how I ended up doing this job -- basically, I failed to duck. But it's been a lot of fun.

What kind of security evolutions or shifts have you seen at Amazon during your time with the company?

Schmidt: The company has really focused a lot on using fungible resources now. When I first got to the company, you would ask for a specific type of machine, and that machine will be yours for a period of time; you get a piece of hardware that lasts for three years or five years or whatever. And the company is now pushing towards operating using functions, as opposed to even something like containers. A lot of people are thinking, 'Oh, I'm going to move from an on-premises machine to a virtual machine, and then maybe I'll go to a container." We push really hard to keep going the other direction and go all the way down into functions because it allows us to spread the load much more effectively. It allows us to not have the developers worrying about updating all the software that runs underneath it because there's a whole infrastructure team whose job that is. That results in not only faster development and more secure development -- I am the security person -- but also happier developers, which is a really interesting outcome because they don't have to do all the heavy lifting with the muck of maintaining all the junk underneath.

But, just to play devil's advocate, does that approach create more stuff for the security team to manage? Doesn't that just lead to more individual assets and permissions that need to be monitored?

Schmidt: Think of it this way: If I'm doing something on a laptop, as the security team, how do I understand what's going on there? I have to go dig around that internal laptop; I have to run software on there from a variety of different vendors. I've talked to some of my peers here today, by the way, and people were saying they were running about 14 agents on their laptops. It's out of hand, whereas you can make one API call to see all of your functions. You don't have to go digging around the basement of somebody's laptop to figure out what's going on there. The visibility is better, the auditability is better and the control is better. It does take a transition in the way you operate a little bit because, if you're used to writing and deploying software on a physical machine, it's a change to write something for a container or for a function.

On the subject of your keynote, I know you talked about the importance of MFA and urged the audience to adopt it. Why do you think we still need people like you, in your position, to get up on stage and say, 'Guys, we need to do this. Please, please, please enable MFA,' instead of people already doing it on their own? Why do we have to keep having calls to action on MFA?

Schmidt: You have to keep doing it for two reasons: One is because it's something different that requires change. Is it the most important change for people to make? Most of them, when they're making that evaluation, don't think it is. But those who have a problem realize it is. And what we're trying to do is to get ahead of people having to hit their thumb with a hammer to say, 'Don't swing the hammer at your thumb; here's a way to avoid it.' As an industry, I think you'll hear more and more of us saying the same thing. I talk to [Cybersecurity and Infrastructure Security Agency Director] Jen Easterly all the time, and we're both on the same page there. Please just use MFA; it stops so many problems.

The irony is most people don't realize that the single biggest attack vector for nation-states is stealing an identity, an authorized username and password set, and using it to exploit things. They don't use super whiz-bang tools and lasers from space -- they just steal you and get access to what you have. MFA breaks that. It's a really, really solid defense. Now, it has been cumbersome in the past, which is one of the other reasons that it was not well adopted. When you think back to those tokens, where you had to type the number in the token, the number changed every whatever type of time -- they're a pain in the neck. People didn't like them, and the battery always went dead when you least needed it to occur. But we as an industry have moved beyond that. If you look at Amazon, as a company, we've required the use of hardware multifactor authentication tokens for years. Initially, employees said, 'Ah, the world's going to end because you're going to make me use these tokens!' People don't even notice them anymore because you can design them in such a way that they're totally innocuous.

And, when you do it right, it's fine. My bank now sends me an SMS code when I log in to my app; that used to be a pain in the neck because you had to copy and paste it from messages. And now, Apple got smart. And my phone just says, 'Do you want to use this code? Yes.' That's the kind of little enhancements that make it from a pain in the neck to something that's much more manageable. We have been giving away MFA tokens to our qualified customers for a while. And we've given away a lot of them; I don't know the number off top my head. But it's so important that we will pay for the hardware and give it to you, just hoping that you can use this to help protect yourself. By the way, the tokens that we give away are not only useful on Amazon; they're useful on anybody who supports the FIDO [Fast IDentity Online] standard, so you can use it for a lot of different places.

Do you have any insight into the adoption so far?

Schmidt: We can see which customers choose to use MFA on their account. We watch that and, when we have customers who reached certain spending or usage thresholds, will proactively contact them and say, 'You don't have MFA enabled on this particular set of accounts. Please enable it, and can we help you?'

Do they enable MFA after you contact them directly?

Schmidt: Almost always. It's quite often that they say, 'Oh yes, absolutely.'

It seems like you as their cloud provider might carry more weight for that kind of recommendation than, say, standalone security vendors that actually specialize in these MFA offerings. Do you feel like AWS is in a better position to make those kinds of recommendations?

Schmidt: Well, there are a lot of things that customers need to do for their business. And, quite often, they just don't see that as the highest priority. We try and help them, and we try and encourage them in the right direction. And I think, if you look at those who have problems, they get religion really quickly. But I would love to prevent that from being necessary.

Learn more in part two of SearchSecurity's interview with Steve Schmidt.