- So I'm going to go ahead, and just dive straight in. So you both are responsible for security at Amazon and AWS respectively. Can you tell me a little bit about the mechanisms you use to stay aligned? - Sure, I think one of the things that we have to start off with is that all businesses are not the same. That's obvious to people out here.
But when you operate a large organization like Amazon, it's sometimes surprising the difference in the business operations within one company. We have some organizations which are extremely risk intolerant, some that are much more willing to push boundaries in certain circumstances. That largely depends on the business that they're in, the data that they're handling, et cetera.
And we've found that it's necessary to have a common set of metrics across the entire company that gives us baseline examination of how people are doing from a security perspective, and then business-specific, or tailored reporting for each organization that talks to the risks that they have and what they'd prefer to do in terms of managing the data that their customers entrust to them, the information that they have, et cetera. Common reporting though, is the most important thing to give us a uniformity of view, and so that when we go and have a conversation with anybody from the CEO of the company, Andy Jassy, all the way down, it's that we can speak in a common language. It's really quick for us to understand how one part of the organization is doing compared to another, and most importantly, it points out gaps to places where we're not examining things the way we need to, because we've learned a particular set of opportunities to improve in one part of an organization versus another.
And let's face it, all of our leaders in the company are competitive. So when you use common reporting that lists them against their peers, it motivates the behaviors that we're really interested in. It gets people focused in the right direction.
- Look, as much as I hate to call myself intolerant, we are risk intolerant within AWS. And so, we're one of the organizations that actually spends a lot of time on our business-specific metrics. Even internally to AWS, I find that these same approaches tend to work for us, that the competitive nature and taking advantage of that across organizations is incredibly powerful.
And to be very, very tightly aligned with the business, to understand that AWS does not have the same tolerance as other places might have for risk. To understand what we care about, and make sure that those business metrics stay tightly aligned with the business, and show up as part of our business review processes. - So Steve, you mentioned talking with the CEO, Andy Jassy. How do you communicate with the CEO and the board security updates? - So communication with the CEO, and should be, from my perspective, it's communicate with the CEOs, since we have multiple CEOs at Amazon, again, are tailored to the way their organization operates. For example, Chris operates a weekly meeting with the CEO of AWS because the security cadence there tends to be super fast.
It's something that we have to react to threats very quickly. We have to understand changes in the environment where we have around us. We have to be able to tailor our responses appropriately given the way the world is functioning around us. We also work with Doug Herrington, who is the CEO of the stores business, but in something that's more focused on his business, where the rotation interval tends to be a little bit different, whether it's a month kind of review, or things like that. Andy Jassy chooses to be in a security review specific meeting on a quarterly basis.
So every quarter, we go to him with both a set of common metrics and reporting that are consistent across time, but then also a section of our report, which is always changing. We call it current events, and it's something where we focus on what is the change in the environment that we operate in that's most significant to us. How are the Russians thinking about things right now versus the Chinese? How are they going after companies? What new methods are people using to cause problems, and how are we responding to that, or preparing ourselves for it? Now, you mentioned the board as well. Our board is relatively unique.
A lot of boards choose to place the oversight of their security organization either in the audit committee, or in a risk committee typically in a financial institution. Amazon has chosen to have a specific subcommittee just for security. And so, we have three members of our board who are focused solely on security. We meet with them on a regular basis. They get a quarterly report on what's going on with Amazon, and go through all of our businesses. The board members tell us that they'd like to focus on a couple businesses at a time, so they choose.
It's sort of the, you know, the spin the dial, and say which business is going to come up the next time around, and then again, we have the section on the current events part at the bottom, because it is, again, the common interests in where are we now, where are we going, what's changing around us, and how do we need to evolve? And I think that very short cycle time between something changing in the world, the board getting informed about how we're managing that change is really important to our continued ability to ensure that we've got the right protection in place for customers. - Chris, anything to add? - Yeah, three additional thoughts. First, one of the things I appreciate both about the conversations with Andy and the CEOs, but also even within AWS, is we don't have those conversations in isolation. It's not just a very small group with the CEO. It is with the CEO and his leadership team, because nothing happens in isolation.
So making sure that the business comes along with the conversation, that we're deeply engaged with the business leading up to and as part of those conversations is incredibly important. Second thing is in AWS, we have a board as well as the Amazon board. And so, that allows us as a mechanism to dive on a quarterly basis deeply into security and related topics on risk, so that we're able to continue to have those conversations, and make sure that we're putting the right governance in place. And the third thought, having seen multiple different boards, every board that I've interacted with is incredibly different. A lot of that is, I think, driven by the people aspect, the personalities, and some of it's driven by the nature of the business.
And so, I think one of the things as a CISO, or as a technology leader and the engagement with the board, it's important, I've found, to understand how does the board operate in other domains? How does the business think about itself and talk about itself? What's the language you should use? What's the context? Because talking about security in isolation doesn't help. It's security in context with the business that's so important. And then third of all, making sure that you understand the audience.
Different people on the boards have very different skills. You've got to be able to speak to all of them. And so, whether we're technology leaders involved in a security conversation, or heads, you know, CISOs ourselves, making sure that we understand that audience, the nature of the board, with how the business thinks about itself, and how security and technology fits into that really makes a successful conversation. - I want to amplify something that Chris just said there.
The biggest mistake that we see from new leaders when they're talking to the most senior management, or senior leadership in the company, like a board of directors, is an overfocus on technical matters, especially in the security space. It is a dead killer for your ability to get your point across to your customer, who is that board member. It's we need to speak, as Chris said, in the context of the business.
It doesn't matter that this is a critical vulnerability with a CVSS score of 9.86. Board doesn't care. This is an opportunity for an adversary to get access to this kind of information which belongs to our customers, which has this result, and it has a reasonable likelihood of occurring within the next 60 days. That a board member can get their hands around as opposed to, you know, "This is a scary thing." So I think it's the contextualization, incredibly important. - [Sara] Mm-hmm.
So you both speak with customers on a very regular basis. What are the current security challenges, or issues that you're hearing from customers, and what is AWS doing to help our customers in that space? - Number one's got to be AI. Lots of people, of course, are really interested in how do I use this safely? How can I use AI responsibly? How can I take information and make sure that I'm getting the right access to that data when I need it, preventing access when I don't? When we talk to customers, the first thing I ask is, "How many applications do you have across your company "that are using generative AI? "Do you know right now? "Can you measure that on a regular basis?" Most people say, "Oh, yeah, we counted last month," or last quarter, or whatever. Guess what? Your developer's moving much more quickly than that.
We've had to build processes internally, which allow us to see every time a developer calls a generative AI engine off of their corporate laptop, or off of one of the production assets that we own around the company, and that allows us to have visibility then that we can feed to our application security teams to help them understand what's going on with that particular service. When we first did that count and started doing that a little while ago, we came and reported it up to Andy, and said, "Oh, yeah, there are more than 1,000 generative AI apps that are currently in operation, or development across the company." And we got the shocked look, like, "What? Are you kidding me?" Like, "Nope." And by the way, it's going up
at an enormously quick rate, which is great, because it means our developers are really leaning in and going forward, but it also means that our teams have to hustle, and keep on track on top of these folks to make sure that they're doing things in a way that's reasonable, appropriate, et cetera. But it all started off with that visibility, and building that visibility engine down at the bottom there. - I think the other conversation that I end up having an awful lot about is what capabilities already exist within AWS as folks are thinking about how they're both secure, but also cost-effective? People don't want to be putting the time and energy into spaces where the solutions already exist, or where things already happen. One of the places where we end up talking about that a lot is the architectures and the controls, making sure that people are well-architected, taking a look at how to implement simple and easy controls at scale.
And so, I think that for us has turned into one of the frequent conversations we have internally about how do we make sure that we're producing simple security at scale for these customers. Another place that this ends up, and we've actually been talking about an awful lot recently, is threat intelligence. Different companies, different cloud providers treat threat intelligence differently. Our approach is all about making that threat intelligence a seamless part of how the systems operate.
And so, we've actually spent a bunch of time talking about this, because we haven't had to talk about it in the past, but it's important for customers to know what to expect, that we have series of threat intelligence providers, honeypots, and sensors that are collecting data every day, more than 100 million interactions a day in just our honeypots. And that these technologies, this data gets combined with our other data, sorry, our other sensor data from systems like Sonaris, and enables us to act. This action happens without customers even having to be aware.
We're able to protect against different attacks once we identify a malicious address, and that traffic never even hits your systems. And so, for example, in the last year, we've denied over 24 billion attempts to enumerate S3 buckets, more than 2.6 trillion attempts to discover vulnerable services in EC2. And where we can't provide that automatically for you, where we don't have that degree of fidelity, we're able to plumb that directly into tools like GuardDuty, et cetera. And so, the conversations I'm having with security folks are how do they take advantage of the technology that's already built-in, both the seamless parts and the parts where we're providing extra information for the security teams to operate.
- There's some really interesting data, I think, to amplify a point that he made there about threat intelligence, and threat intelligence is an incredibly fragile thing. What most people don't realize is that from what we see on the internet, about 23% of the IP space of the internet turns over in about three minutes, meaning if your threat intelligence feed is a week old, or a month old, or whatever, you are way, way, way out of date. And a couple other things that talk about the immediacy of action as soon as you get threat intelligence information. When we expose a honeypot to the internet, it takes less than 90 seconds, nine, zero seconds, for an adversary to discover it.
And less than three minutes for that adversary to attempt to exploit it. So this is situations where if your developer says, "Oh, I'm just going to open this bucket up to the internet, it'll be fine, nobody knows that it's there." Three minutes, that's what you got before you have a real problem.
So know what's going on through a robust intelligence feed, be able to act on it quickly, and more importantly, don't require a human in the loop to act on it. Make sure automation does it. - [Chris] Well said. - So I am going to switch to a topic that's very close to my heart, which is in the world of ever-evolving regulations, standards, certifications, et cetera, it proves a challenge to be able to sort of stay on top of that compliance, evolution of compliance. So Chris, can you talk a little bit about how AWS thinks about compliance at scale? - [Chris] We get to talk about this an awful lot. - Yes, we do. - I guess to start off with,
one of the things that I think is incredibly powerful in terms of how you do compliance at scale is you get to start off with a secure foundation. Taking advantage, thinking about security in terms of secure by design, making sure that security's baked into the development process gives you kind of a great starting place before you even have to think about regulation, or compliance. When we do things best, compliance is an intentional side effect of that security work. And to be honest, most of the regulatory bodies want that as well. Their reason for compliance is to ensure you're secure.
And so, it's really important to design a security program that's focused on security with an eye to intentionally demonstrating, proving compliance. And then the third piece is it's not enough to always have that compliance by design as part of your security processes. You need to be able to demonstrate it and show it. And so, being able to pull that data together, make it visible, make it easy for other people to understand is incredibly important. And there's engineering involved in that as well.
It's a worthwhile investment. I'd say that, but you spend more time in this world than I do. So I'm curious on your perspective as well. - Well, I hear a lot from customers right now primarily on the topic of responsible AI programs and how to very rapidly operationalize it. So it really is a conversation about, because of just this very rapid evolution, of being able to move from the concept of compliance, which is sort of very much point in time, very binary, very much focused on are we adhering to the rules and regulations such as the EU AI Act, for example, and being able to evolve that program rapidly into more of the assurance mindset, and assurance being able to provide a level of confidence on the quality, the reliability, and the effectiveness of the compliance that we are able to illustrate.
So how can we do that? And quite frequently, that is usually leveraged through technical standards, so things such as ISO 42001, which enables organizations to be able to illustrate to end customers that they are operating, they're both deploying and developing using responsible AI practices, and then wrapping all of that from a governance perspective. So how do you ensure that the organization is doing what you actually expect, and how do you report out to senior leaders and the board on what you're doing around responsible AI. And most importantly doing all of that in a way that you're meeting the builders where they are, and you are not slowing down innovation. So you're able to meet that high bar, and at the same time, be able to rapidly do it. So switching topics a little bit, Steve, I'm going to go to you. There's quite often, and quite frequently when we talk security, we very much get into the new technology and the evolving worlds that we have in front of us.
But at the end of the day, a threat actor is a threat actor and is a human, and I would love to hear a little bit more around how you think about the human dimension associated with cybersecurity. - Certainly, so breaking news, computer security, information security, cybersecurity, whatever you want to call it, is not a technical problem. It is a people problem. One of the things I learned a long time ago when I was in the FBI focused on counterintelligence work was that while yes, chasing the spies is the job, and it's interesting, they're there for a reason. They're motivated by something.
Traditionally, in the espionage world, it was money, ideology, coercion, or ego. The same thing is true in the cybersecurity world. People are interested in money.
That's your ransomware actor. Ideology, it's your traditional nation state actor who's gathering intelligence, or preparing a battlefield. Influence, which is a new one in this space, is getting a population to think in a particular way, shifting their opinions, causing things to happen in the world, or ego. That's the script kitty who really wants to be the biggest, baddest hacker out there and causes a DDoS attack as part of that.
And why do we care about knowing why these people are doing this, or their motivation? Because it helps us understand the kinds of tools, the kinds of capabilities that they're going to have, where they're likely to go after us, and their tolerance for risk, or exposure as in, you know, is this a big deal if they get caught and the FBI comes knocking on the door, or is this something that doesn't really matter because they're currently sitting in a basement in Belarus, or something like that, which is the kinds of spectrum that we have to work with to understand what we have to do as defenders and how we build systems that help prevent those people from gaining access. The interesting thing is that same mindset needs to be applied for our own employees. Our own employees are universally well-intentioned.
They want to do the right thing. They want to help, et cetera. But let's face it, they're also human. So sometimes, they get in money trouble. Sometimes, they don't like the direction something is going.
Sometimes, they just have a bad day. And as a result, we as defenders need to be able to be prepared to understand what they're doing, why they're doing it, and how we're going to make sure that they're not doing something that they shouldn't. But a lot of what the really important component of cybersecurity and people within a company is is the culture of the company. The security culture of a company is the thing that'll make or break. We have all seen what happens in the public news when you have a deficient security culture. You end up with nation state actors breaking into an organization repeatedly and exploiting them for their own benefit. Why?
Because the people in the company were not measured, or motivated by the right thing. They weren't motivated on protecting your data, or your information. They were goaled on something else. And so, building your culture, which says the most important thing for you as a person, a developer in my company, is to, number one, be safe physically yourself, and number two, protect your customers' data. Because that allows them to make good decisions every time during the day when they're thinking about something. "Should I go left, should I go right? Should I do one thing, should I do another? Should I ask for help because I really don't know? Let me go find an expert in this space."
And I think that incentive there of making sure that you've got the right culture is that it leads you to lower cost down the road, because you don't have to clean up the messes that somebody made because they were moving quickly to hit a profit goal, a margin goal, or a delivery goal as opposed to getting security right for your end customers in the businesses. - And it makes my life easier as well in the security assurance world as well. It's a nice outcome. So Chris, taking that point around culture, we talk a lot at AWS about security being a top priority. Talk to me a little bit about how we actually do that.
How do you build that culture? - One of the reasons why I think culture is so important is not only does it lead to the long investment, but I think every company that I know works to train, provide tools, provide capabilities around cybersecurity, and one of the major differentiators is culture, because security's constantly changing. To your conversation earlier, I can't tell you how many times we end up talking about AI recently, right? AI is constantly changing. And that ability to adapt, that ability to raise your hand and say, "You know what, I'm seeing a conflict here," or, "I'm seeing a better way to do security." Let's think about this. Can we do this better? Not just blindly follow the process and the tools, but actually go ask the question.
Or, "I think these processes and tools are missing something. I see this risk, I see this issue. How do I bring that up?" Those things are incredibly important.
And so, as you said, the culture pays off over time in an amazing way. Building that culture takes deliberate time and energy. It starts at the top. It starts with aligning the culture to the way the organization functions. Part of that is telling yourself who we are. It's internally just as much as externally hearing Matt say, "Everything starts with security."
And furthermore, it's how people spend their time. Steve and I both talked about the weekly meetings that happen led by our CEO. Again, making sure that that's part of how the organization functions is incredibly important. Once you have the security built into the culture of the organization, it's important to emphasize that security is everybody's job.
Each person gets a specific role. That's the opportunity to raise your hand and say, "We have to do something different. We think we're missing something. I'm confused, I'm not sure." Security, everybody needs to understand that security is their job, and it's our job as security leaders to make that job as easy as possible.
Because if people are spending their time focused on security every step of the way, that's going to add friction to the organization. What goes hand in hand with making security everybody's job is security working to make it easy and natural for people to do security. That means that security needs to be distributed across the company.
We need to make sure that training, knowledge, capabilities are well designed to make sure that happens across the whole of the organization. And then lastly, we need to be willing to invest. We need to be willing to invest in innovation that improves security. We need to be willing to invest in innovation that makes it easier to be secure, because if you don't, you end up getting caught in the past, and you're never able to move forward as an organization. One of the ways to do some of this is through things like a Security Guardians program, where we rely on our people, we train them on deep security matters within the service teams, within the engineering teams, so they can make sure that people are thinking about security very early during the development processes and continuously, and they've got that right knowledge.
And it helps make things very, very, very scalable. And so, there's one thing that you all can do with your teams, it's look very deeply at can we create a Security Guardians program, and how do we create a culture of security within our company? - Okay, so what are three questions that business leaders in the room can bring back to their security and compliance programs? - I'll give you one that I always love to ask. For all of us technology leaders, I don't know how many of you have what we call a builder tools, or a developer tools organization. As a security leader, those organizations are my favorite organizations in the whole organization. If you don't have one, these are the teams that build tools that make your developers' lives easy. There's massive leverage there.
If there's a place that I love to see companies put their top talent, it's in the builder tools organization, because in one organization, you can make all of your development processes much, much better. From a security standpoint, that's where the leverage is, because you can take your security knowledge and your security capabilities, and build it into those tools, and get massive scalability, and make security a natural motion. And so, the question that I would take back if I were you all is ask your security leaders and your builder tool leaders what their relationship is, how well they're working together, and how well all of the security outcomes that you're looking for are built into the builder tools capability. - Steve? - So this is to sort of reiterate something I said before is ask your teams, "Where are we building Gen AI applications right now?" And then ask your teams, "What is the mechanism that we have in place, so that we know tomorrow where we're building Gen AI applications, and what is the latency between someone building a new one and us knowing about it?" And you'll find that in many cases, the answer is scramble, scramble, scramble, quick, find some data, here's the answer.
Awesome, it's now the next day, okay? So you need a method, a mechanism, a tool which allows you to do that on a regular basis to keep up-to-date with it, to make sure that you are responsible operators and stewards of that infrastructure, and that you can be responsible owners of the data that you collect on behalf of your customers. The second piece there is what guardrails do you have in place, and is there a mechanism to update those guardrails as the world changes around generative AI? In the time we've been sitting on stage here, generative AI world has advanced incredibly. There's something new that's going on. There's some new way to cause a problem with the foundation model that some smart person has thought up, and we have to be able to defend against it. So what is the rapid iteration method to be able to influence the guardrails you've got around your Gen AI applications? - I think you cheated. I think that was two.
I, too, am going to cheat a little bit. And I would say it's very much asking teams about how they're actually ensuring compliance, and what I mean by that is it's not just a case of in the moment how are we able to tell whether or not we are compliant with the various either standards, laws, et cetera, but it's also actually understanding how you're able to get continuous assurance over time, so that you can really determine what the cost of the builders is. So I would say there's two core questions, which is “How are you compliant with either your internal practices, or laws, et cetera,” and “What is the cost to the builders,” which is really important, because you want to be able to innovate very fast, and you want to ensure that you're monitoring how much it's costing your builders, and still ensuring that you remain compliant. So in closing, the final question that I have is in speaking with customers on a regular basis, what is the best advice that you have for customers to immediately improve their security posture? - For your internal company and for your customers, find ways to implement passkeys. Getting away from passwords is just game-changing for your people and for your customers. Take advantage of that technology.
It's a major leap forward. Implement it today. - And then not only is it much more secure, it's a better user experience. It is so smooth. So get your tech people focused on this, and find out why they're not doing it right now.
Number two is much less exciting than passkeys, and it's security vegetables. Vulnerability management. Patch your stuff. It is the single best defense that you've got against people out there, - Or make us patch it for you. - Exactly, there you go- - Use Lambdas, and other things. - Yup.
- Well, thank you very much for joining us today, and thank you again for the time.
2025-01-27 22:48