Security at AWS

When meeting with security, risk, and compliance executives who have yet to start their cloud transformation or who already have multiple cloud workloads in AWS, I am often asked a version of the following question:

“While we agree that the cloud is the new normal, it is different than running security on premise in the enterprise. We don’t want to reinvent the wheel when it comes to cloud security operations. How does AWS do it?”

Fortunately our CISO, Stephen Schmidt, gave a great talk at re:Invent 2017 that speaks exactly to this common question. While I encourage you to watch the video, I will summarize the key points, as well as some that aren’t covered in the video, below.

Culture: Everyone at AWS is Responsible for Security

While we have dedicated security professionals whose primary responsibility is in fact security, every AWS employee, regardless of role, is responsible for ensuring that security is an integral component of every facet of the business, and security is referred to early and often. Every employee knows how to report a security issue, and they are empowered to escalate security issues to the highest levels if needed.

It Starts at the Top…

Andy Jassy (CEO of AWS) convenes a weekly security review with the AWS CISO and all senior VPs in the company. This meeting enforces the culture that security is “job zero” at AWS, by which we mean it’s even more important than any number one priority. People are made accountable for resolving any open issues, and strict timelines are adhered to for resolution. The AWS CISO holds weekly application security review meetings with all of the service team owners. New services will not launch if there are any known security issues open. However, blocking (delaying) a launch is very rarely required. Our security teams are deeply engaged with new services and new feature development from the beginning. A highly collaborative (as opposed to oppositional) culture when it comes to security reinforces the trust between service teams and security teams.

…And Continues Through Every Level.

Every VP, director, manager, engineer, developer, etc., has security, risk, or compliance metrics as part of their individual and department goals. Security expectations are set for all service teams to ensure minimum security baselines are set across all of AWS. They are non-negotiable. Some examples: all EC2 (Elastic Compute Cloud) instances must have Amazon Inspector installed; all service teams take specific goals to remove human access to systems and data; encryption must be used for data in transit and at rest where applicable; security practices and reviews must minimize the blast radius of credential misuse by using fine grained access controls.

With the Security Expectations program defined and a culture of security first in place, developers focus on building new features and services, not debating whether a security feature or control should or shouldn’t be incorporated.

Security Operations at Scale

AWS has millions of customers, thousands of employees, and more than a hundred services…and those numbers continue to grow. There is no way to physically staff a security team to protect all of those assets using traditional techniques. Therefore, AWS builds security into its services from the start and deals with remaining issues by relying on automation built by security engineers. Automation is the key to ensuring that security is enforced consistently, in a repeatable fashion across all of AWS. Automation can detect malformed packets as part of an attack and blackhole them accordingly. Automation can enforce rules, set by humans, to ensure that certain S3 buckets remain private while others public. In most cases, security trouble tickets can be investigated and closed via automated processes, never engaging a human security engineer. In short, automation can and must be used in all places where a process can be standardized and made repeatable and mechanical. This allows our security engineers to focus on the more nebulous area of risk where human beings are best utilized.

It’s Not About the SOC

Let me tell you about AWS’s state-of-the-art Security Operations Center, buried deep in an undisclosed location, with multiple large screens and blinking lights alerting on every possible security anomaly. I’d love to tell you about this center, but we don’t have one of those. No, really.Really. We do, however, have a mature SOC function. We maintain a follow-the-sun model for security operations, with one person on duty at all times, taking a six-hour shift. Handoffs are formal, tool driven, and go from Seattle to Herndon to Sydney to Dublin. There is a primary on-call, a secondary on-call, and an escalation path. The escalation path is entirely automated and driven by the infrastructure itself. For example, if the primary on-call doesn’t respond to a page within the defined SLA, the secondary on-call is paged. This goes on up the chain of the security organization to the AWS CISO, if need be.

Tooling

We’ve talked about the high degree of automation in regards to security operations that is in place at AWS. But, how does an enterprise even begin to build such tooling and mechanisms? By using the same tools that AWS uses…the same tools that are available to you today. You can build these event-driven security solutions with AWS Config, AWS CloudFormation, AWS CloudTrail, AWS CloudWatch, AWS CloudWatch Events, AWS Lambda, Amazon GuardDuty, Amazon Macie, and Amazon Inspector to name a few.

Takeaways

1. Build a strong security culture, make it important, and include everyone in your organization.
2. Invest in security engineering, tooling, and automation mechanisms that scale.
3. Develop and disseminate a set of security expectations for your organization. Get humans away from data and systems. Automate everything that can be automated, letting your security professionals focus on what humans do best: assess risk and add value to the business’ objectives.

– Clarke

LinkedIn
Twitter