The AWS Security Landscape Evolution

These are questions which were easier to answer five or so years ago, when organisations typically owned one cloud (AWS) account. The AWS account only had one kind of server (EC2 Classics) and these were only available on the internet.  So AWS customers might have restricted their use to testing a proof of concept and definitely avoided the storage of any sensitive data (after all, all it takes is credit card to get into the cloud isn’t it).  Nowadays its a lot more difficult to answer these questions.  An enterprise with a presence in cloud can easily have more than 100 AWS accounts (my work 1Password account has about 20 AWS account credentials that I have access to).

An architecture for a minimalist AWS presence for an organisation might look like below:

Each environment has all the resources required for that one environment and is kept logically separate from the other environments by creating separate AWS Accounts. The segregation can also be done based on the functionality of the application, or the business unit that will use the account. Such segregation will still require a dev, test and prod environment to work within the ITIL methodology of managing IT assets. On top of all these accounts there will be a Master AWS account for consolidating the billing between all the different kinds of AWS accounts and auditing purposes. You can see how this will get quite a task to manage when we may be looking at 20+ accounts every day.

Similar evolution has happened to the security conversation that I have with clients hosting resources/assets in AWS. Initial conversations were around how to help clients keep assets secure in AWS and at the same time enable these assets to automatically scale based on demand in a secure way. This was easy to manage when everyone had just one AWS account. With bigger organisations and more AWS accounts, we have an increased governance requirement that needs to be managed by the operations and security team. You can see how complicated it can be to answer the questions that I have asked in the beginning of this post. At the time of writing this article (May,2017) AWS has no product that answers the above questions across all the AWS accounts within an enterprise. AWS does have a product called Organizations to apply restrictions on AWS products that can be used in any AWS account managed by the master account. This still however doesn’t answer the questions asked above. If you added the following compliance and standards requirements such as ISO27001, PCI/DSS Compliance, CIS Compliance in the mix, you can see the security posture becoming hard to visualise.

The above challenges have made me look at products that answer some of these questions. One of the products that I like and use regularly at client site is called Stax to answer some of these questions. The Stax dashboard can tell me in one go if any of my AWS accounts have any public facing IT assets (AWS S3 buckets) or any machines (EC2 instances, ELBs) facing the internet or even any AWS resources that have been created outside of defined regions (this is important from a privacy perspective for government agencies, health & financial institutes). It can alert me when any AWS resources in any of my AWS accounts are not complying to any of the organisation compliance rules. I do have to mention Stax doesn’t answer all of the security concerns (it was originally designed to function as a cost optimisation as well as a security tool), but it does give customers a good start to answering security compliance questions. Stax and other similar products in the space are evolving with AWS, adding more features and checks, so soon they will start to answer these questions.

I would have loved to say that every client that I talk to is already at a mature state and able to extract the value from such products as required. However, this isn’t the case and not all organisations are the same way in the way they use AWS. I am looking forward to the next phase of AWS security evolution where compliance questions across all accounts will get answered by products like Stax and similar products and my security conversations will evolve to something more like: “I know some of these assets in AWS are not compliant, how strong an action should I take – should I kill a server created in a non-Australian region or simply notify the team?” and let them manage their own compliance level.