The AWS Security Journey (2021)

A lot has happened in the area of security at AWS over the years. By now, AWS has released an exhaustive range of security services and the role of the security officer has changed significantly. This article looks back and forecasts where the journey will go next.

TL;DR

• Cloud providers have shaped the philosophy of security and done their homework.
• New services to secure and new security services and their features pose a know-how challenge.
• Security Engineers as specialists will outnumber Security Architect generalists.
• Cloud customers organizations will be increasingly challenged to keep risk at an acceptable level.

The beginning – Security Philosophers

What is your story? How did you come to AWS? For me, as a security professional, the cloud was an obvious field of work. However, initially, it was not clear that AWS would be the market leader and for such a long time.

Cloud computing was proposed, but its adoption was not an immediate success. There were security concerns about confidentiality, legal issues about data location, and data ownership worries.¹

AWS had an easy solution for the last one: Customers own their data, can always transfer their data, and must do so before they terminate the contract. AWS will not keep the data afterward.

The legal discussion – at least in Europe – dragged on for several years: USA PATRIOT Act, EU Privacy Directive, Safe Harbor, CLOUD ACT, GDPR, … In the meantime, the practitioners were implementing, with major or minor concessions to the perceived legal situation, and they were rarely called to order.

AWS did their homework on security and passed audits, and achieved certifications. With the Security White Paper, AWS published the Shared Responsibility Model and informed their customers that they had work to do, too.

Security work was like this:

1. Customer voices a security concern, what could go wrong.
2. Reword it as a question or demand to the cloud provider.
3. Locate information about the provider’s security in an official white paper, an answered questionnaire, or from a 3rd party audit.
4. Evaluate whether the answer covers the initial concern or whether parts of the issue remain in the customers’ responsibility.

The build-up – Security Architects

AWS released CloudTrail and KMS and was directing a large part of their information campaign to security: AWS Summits, Blogs, Meetups always mentioned: “security is our #1 priority”. With the availability of KMS, encryption-at-rest was more in the hands of customers, and later, Werner Vogels recommended, “just encrypt everything”.

AWS was leading the security initiative. The regional rollouts in many countries acknowledged their customer’s legal worries about data location and allowed them to save their data in their own country. Now all concerns could be handled, and implementation of “Cloud First” initiatives could start. For me, with eu-central-1, I realized that AWS would become the most important player, not only in Germany but worldwide.

By then, the services were complete with security features, and one could safely assume that there would be some solution for every security problem. The security design would proceed as follows:

1. Identify the AWS service, which addressed the problem.
   A nod to Michael, who helped to structure the topics with his AWS Security Primer mindmap.
2. Use the service name to look up security information in the AWS reference.
3. Design a solution and draw a diagram.
4. Code and find out about the limitations of the service.

AWS provided some structure, how this work should be done, and ultimately it was codified in the professional education program for the “AWS Certified Solutions Architect”, which also includes many security topics. Note that there was no prep book or online course initially, and taking the exam was a step into the unknown.

In 2018 AWS created the Security Specialty, which was going deeper into implementation details, but in scope initially stayed close to the Solution Architects scope. The exam is updated over time, and as I recertified in 2021, it occurred to me how much the field has changed: More services to secure and more security services, more bits to know.

The overload – Security Engineers

AWS announced that “Over 150 AWS services now have a security chapter”, which is quite an impressive number. Depending on how you count (the CloudPegBoard lists 323 AWS services), most common services seem to be covered, and everyone should use this ready-made security resource. If a security chapter does not cover a service, a security analysis will have to be performed, as was previously the norm.

AWS-native security services

AWS rolls out ever more security services, and new features are continuously added to the existing services, as summarized in the table below. First and foremost the table shows that the required know-how rises in two dimensions: Year after year, the table gets longer, and the numbers of the existing lines get higher.

Is it realistic that any AWS security expert will have sufficiently deep knowledge about every service’s internal operations and configuration details? In security, the margin of error is relatively small.

Specialist vs. generalist

The larger amount of knowledge causes a split between the Security Architect as a generalist and the Security Engineer as a specialist. The number of engineers will continue to grow with the number of applications that must be maintained in AWS and the increasing need-to-know-how in AWS services. Whereas Security Architects will continue to work at the generalist level, similar to Solution Architects, usually in implementation projects, their number will not grow as much.

Both can work together to generate results faster by using the increasing amount of material available from AWS and other sources, as follows:

1. Architect finds an implementation blueprint or CloudFormation template and lists all AWS services in the diagram and hands it to the Engineer.
2. Engineer collects all recommendations from the security chapters of each service and checks the implementation manually or in the CloudFormation template.
3. Both lookup checks or metrics in Security Hub or Guard Duty or design their own to configure alerts from the checks and metrics.

This approach is traceable, measurable, efficient, and improves security. It also acknowledges that nothing is perfect and includes a response to incidents. However, the remaining risk is not transparent, primarily if some measures have not been implemented.

The future

As more cloud applications go into operation, they encounter well-known management problems of security in organizations: Immediate costs get more attention than future damages, and prevention is not valued if nothing has happened in the past. In effect, a business will do less than was recommended and accept more risk than would be optimal.

It is foreseeable that security incidents will happen more often, and damages will be more significant. Unfortunately, currently, there is no mechanism for the community to learn from substantial breaches like Capital One.⁵ We would need 3rd party investigations of essential incidents, which make analysis and improvements public so that everyone can learn and improve.