Moses, who has worked at AWS for nearly 15 years, previously led the technical analysis of computer and network intrusion efforts for the FBI’s cyber division and was a computer crime investigator as a special agent with the Air Force Office of Special Investigations. At AWS, he spent more than five years running and building its secure government offerings, including AWS GovCloud and the U.S. Intelligence Community cloud under its Commercial Cloud Services (C2S) contract.
Now as CISO, Moses is responsible for security across AWS’ cloud platform, leading product design and development, security engineering and strategy. He hosts a weekly security review meeting with AWS CEO Adam Selipsky and his senior vice presidents and select vice presidents.
“This meeting is the mechanism that enforces the culture that security is ‘job zero’ at AWS,” Moses said. “People are held accountable for resolving open issues, and strict timelines are adhered to for resolution.”
Moses also holds weekly application security review meetings with all of AWS’ service team owners. New services will not launch if there are any known security issues open, he said, but delaying a launch is very rarely required.
“Our security teams are deeply engaged with new services and new feature development from the beginning,” he said in a recent interview with Protocol. “A highly collaborative, as opposed to oppositional, culture when it comes to security reinforces the trust between service teams and security teams.”
This interview has been edited and condensed for clarity.
What are your duties as CISO?
It really comes down to making sure that we have the right tools, techniques, processes and people in place from the start, shifting as far left as we possibly can — meaning that security is part of the design of the things that we’re making. And not only security in mind from the design standpoint, but the protections that you can put in place, detective or otherwise.
If you have a scanner that’s running across your code after it’s already been written, that means that you didn’t catch it in the design or the initial coding phase. Every possibility that you can have to move further and closer to where code is being written by individuals or even further into the design phase means [reduced overhead], both from a development time as well as from a security perspective, to the overall process. Finding an issue after something’s gone into production and is public, and you have a CVE and all of that process, it’s very expensive to then mitigate that and to patch. We’ve moved as far to the left as we can and mechanized things.
One of the things this year that we found is that moving a lot of the code analysis straight into — before there’s ever even security reviews officially — the builder space, into the developer environments that they use, so that things are getting fixed before security officially would kick in and do reviews of the software. The good part of that is the developers are then catching it as it happens and then changing it is an education for them. They’re like, “Oh, it caught that I did this. This is an anti-pattern that I shouldn’t do,” and then they don’t do it again. And the percentages of increased capacity, if you will, is huge there because, once again, further left that we can shift stuff.
My goal, in the fullness of time, would be to put our operations or responsive operations out of business. It’s not a real possible goal, but as much as we can to move things to the left so that we’re finding them earlier, remediating them when they can be most impactful and people learn from that so that you don’t have them happen again, the better situation we’ll be in across the board.
[The] last thing that any software development engineers like to do is repetitive, boring stuff. And the more that we can make it an automated process earlier on, the less impactful it is to their timelines of developing and deploying innovative new services or features. So far, the feedback from the teams themselves is positive. And that’s really what I like is that you’re making a security impact, but you’re also making the developers and the teams themselves that are trying to build new capabilities for AWS users, you’re making them happy. It goes back to … making security the path of least resistance.
What is AWS’ security strategy? Microsoft seems to be throwing things at customers all the time, and Google Cloud has said it wants to provide end-to-end security.
Overarchingly, we’ve always wanted to work backwards from the customer. We don’t want to tell the customer what they need to do. We actually want to work backwards from them to understand what their needs are. And we’re hearing from customers on a regular basis that … they see our cloud as being the most secure cloud there is. But they also want the ease of use to be able to be secure in the cloud as well. [At the AWS re:Inforce conference last month, vice president of AWS platform Kurt Kufeld] announced a lot of features and functionalities moving towards making it even easier, rather than only having these services that you can put together in order to have a comprehensive environment — to pull those services together into solutions that meet business needs without having to have a lot of the work in the customer space.
What you’ll see from us more going forward, and you have kind of seen already, is creation and bringing together of security services on top of the normal AWS services that we have in order to create that “easy-button” experience of being able to deploy and operate in AWS and do so in a fashion that is the path of least resistance. It’s make it easier for our customers to be innately secure when operating in the space.
Many times we get asked from customers to share our threat intelligence with them. Obviously, at scale, it’s very difficult to pick up the phone and call a million-plus customers to say this is what we’re seeing. As threat intelligence — things we learn by operating in the space — is found, we’re pushing those things directly as near real time as we possibly can into the services we’re offering to customers. GuardDuty, as a threat detection service, is an obvious one; Security Hub and others, as part of that, are there. The idea is that as we’re finding stuff, there shouldn’t be the lag or delay to our customers of taking that intelligence that we’ve gathered or that experience … and pushing it into those products.
So these days, when I get asked, “Will you engage in a threat intel sharing agreement,” I say, “Turn on GuardDuty — just turn it on and use it.” And then all of the back-end process of sharing and then figuring out how you get it in your system and your own network, it’s just not there anymore. You don’t need to do that. We’re going to do it for you. The model that works going forward is automation mechanizing. And that’s, from our big picture, continuing to move down that path of having AWS be not only the most secure, but the simplest to be secure by default.
AWS isn’t always known for being the easiest service to use.
I know. But the reality is that we are the blank canvas that allows you to create the Mona Lisa. And what we want to do now is to be able to allow you still to paint the Mona Lisa, but in this case to be able to do so in a secure fashion.
You bring up the simplicity. I think that you’ll see across AWS that the focus is to continue down the path of being the most capable cloud provider in the world, to have the most ubiquitous security and other capabilities, at the same time, increasing the simplicity of being able to do so. There’s a huge capability that we have there, and we’ve focused on having all the features and all the building blocks for so many years.
There was no other cloud provider that’s ever had that kind of capability built from day one by the paranoid group that we have, with the expertise, that have been chasing hackers around the world.
There has been a transition. Security Hub is a good example specific to the security space, trying to cordon in to where it makes it easier for the security professional to be able to go to one place and see the alerts and things of that nature without having to go to consoles for each of the different offerings. And you’ll see more and more of that over time across AWS, not only in [the] security space, but overall — being able to focus those services towards solutions. That’s one of the things that you see a lot of our ecosystem is strong at. You have providers that are our partners that are taking our services, putting them into very easy-to-use, press a button to provide a solution across the board.
You mentioned customers saying that AWS is the most secure cloud. Do you believe that and why?
I have no doubt in my mind that it is. I came from the FBI to AWS because I was a potential customer. Back when AWS was one region, five services, the security that AWS had day one was the log-in password and user ID from the bookstore — from Amazon’s website. We had a business need at the FBI that we were supporting, and it was a counterterrorism effort, and we had essentially what they call big data today — mining that big data, basically looking for the needle in the needle stack in order to keep bad things from happening to good people. We had a lot of vendors that were out there that wanted to support and did support us. The “gotcha” was that no matter how much of the same stuff we bought, we never were able to make that scale function or that step function [for] Friday at 4:30, [when] the digital truck would back up with more data. And you want the definition of “keeping yourself up at night”? That’s the job, because you know that if you don’t find that needle that bad things are going [to] happen to good people, and it’s going to be your fault.
When EC2 was launched by AWS [in 2006] … the idea of saying, “OK, I can use 1,000 computers for an hour rather than having one computer for 1,000 hours” — the time to value is huge. So we [at the FBI] had some meetings with [AWS chief evangelist] Jeff Barr … and said, “Hey, this is the mission we have, you guys have this,” and they were like, “We want to be able to do that, but we’re not in a position today. We don’t have the infrastructure, the security, the background, all of the features that you’re going to need to do that kind of business on top of us.” The discussion went on for six or eight months and subsequently [former AWS CEO] Andy Jassy, a visionary that he is, said, “Hey, there’s only one way we’re ever going to get to that business, and it’s having people like you join us, bring us into the enterprise out of just individual developers and startups, build those capabilities and take us forward.”
The security story was very weak [on] day one. A handful of us — (former AWS CISO) Steve Schmidt, myself, Andrew Doane and Eric Brandwine — joined in late 2007, and our job was the dedicated utility computing team — the DUC team, also known as the feds [because] you had a bunch of us coming from the FBI. We weren’t given a distinctive thing we had to do other than move us towards the enterprise. We thought about the mission that we had previously and how we could build from scratch the environment that we needed to have in order to be able to do the highly secure work that we were doing. We were paranoid, but we were paranoid for good reason because we did know, in our previous lives, that they were out to get us. So we came into AWS with that mentality and built from scratch day one that foundation. There was no other cloud provider that’s ever had that kind of capability built from day one by the paranoid group that we have, with the expertise, that have been chasing hackers around the world. Built it from bare bones.
Talk about shifting left. We shifted left 15 years. Started with EC2, rewrote basically EC2. The virtual private cloud that’s spoken of today, we created VPC, and it was our first product. We went from being dedicated utility computing to virtual private cloud. We wrote the underpinnings — the virtual network overlay protocol — so we run our own protocol on the network in order to be able to maintain isolation between all of our customers. We started with that and then grew, work, scale, created.
The security culture that you see today is based upon us taking our security mindset and Amazon’s ownership culture, jamming them together in the idea that you have single-threaded owners that own their business beginning to end and including security as part of that, such that at the end of the day, there’s no finger-pointing. If EC2 has a security issue, the owner of EC2 knows it’s their responsibility. It’s also my responsibility to enable them and make sure it doesn’t happen. So we share that responsibility, but straight up, they know that is theirs to own, and they’re going to be the ones … answering to that. That mental model, that starting from scratch building and continuing to do so and never wavering … that model is why we are the most secure. Other cloud providers have created capabilities that really are add-ons to things later on. We started from scratch, built not only the underpinnings of the technology, we built the culture, and every one of the service teams thereafter were built on the security culture that we have created at AWS.
To this point, I think that we’ve represented ourselves pretty well. There’s been a lot of threats and adversaries and other things out there, and we have the longest track record of operating on the internet with all of those things attacking us. Not to mention, we’ve won some pretty big contracts with government entities that are known for being able to identify what is secure and what is not.
What’s the biggest threat to cloud security right now and how do you stay ahead of all these bad actors?
You have to think of it this way: Humans are behind everything that happens. And in cyber threat, you look at it from the standpoint of every threat that comes at you, every adversary there is, there’s actually a human on the other side of that keyboard. I learned this very, very near and dear to my heart chasing hackers around the world.
During the [buildup to] Russia invading Ukraine … you could actually see, from threat intel, known ransomware actors in Russia that were essentially extorting money from people to restore their infrastructure. During that buildup, all of a sudden they went from being ransomware to just “delete everything.” The humans’ intent behind the scenes changed. So from a threat-actor perspective, you have to understand the adversaries and then … put in the protections in order to be able to not only … prevent, but in the case of anything that gets past the prevention, to detect them.
Understanding how those actors act and types of things that they do is important to understanding how you get in front of [it]. Don’t look at what’s going on today, look at what’s going to happen not only tomorrow, look … into the future and build the capabilities there. The idea that we are thinking that far in advance, understanding the long game, allows us to get in front of those threats.
What are the biggest security mistakes that you see enterprise customers repeating?
I don’t think that there’s huge trends and things that customers or enterprises are making. Essentially it comes down to that customers need to be focused on making sure that they’re doing the things that are within their control within the cloud or within the environments. Customers have to take responsibility for that which they have access to. We have created all kinds of tools — access analyzers and other things like that — in order to enable them.
The focus going forward is to be able to establish more and more guardrails. The ability to block all your S3 buckets from not being able to be accessed from the internet is a good example of one of those controls. And as we go forward, you’ll see more and more capabilities like that that you can add from an executive governance level that’ll allow those guardrails to be in place to allow customers to be able to have their developers have that ability to be free and do the innovation that they need to do while also putting the controls in place across the board.