A Walk in the Clouds: A Cloud Security Strategy for AWS

Part 1: Securing Containers in Amazon ECS

"There are no rules of architecture for a castle

in the clouds." -Gilbert Chesterton


Over the past year alone, the number of breaches affecting Amazon Web Services (AWS) tenants has risen to an all-time high. However, because cloud service providers (CSPs) are a shared responsibility model, the onus of those breaches does not fall on Amazon, rather, the system and data owners of those cloud workloads.

This is part 1 of a multipart series on a strategic plan for securing workloads in the AWS cloud. Part 1 defines an actionable plan for securing containers deployed onto Elastic Cloud 2 (EC2) instances or via Amazon FarGate.

First, terminology is defined to introduce readers who are not familiar with what microservices, APIs, containers, container orchestration, and other related AWS ECS technologies are. Then, the actual plan for securing containers deployed in ECS is detailed, decoupling security controls that are provided natively by AWS to tenants from third-party solutions that should be considered as part of the strategy.

Today, for better or worse, we have an innumerable number of empirical reference data to AWS breaches. Everything from the recent Capital One breach of its S3 data, the breach of Accenture’s data in its S3 buckets in July, to Samsung’s Smart Things source code that had been compromised as a result of a mistaken hard-coded S3 bucket key in the source code of Samsung’s Gitlab repository. The list goes on and on and is surely to get worse before it gets better before year-end. 

However, with the bruises these breaches have given their data owners comes lessons learned as well as a call to action for others not wanting to make those same headlines. The impetus for this series is exactly that, to keep you out of the data breach headlines. This article aims to help you understand what security controls are available to you for hardening and securing your cloud workloads in AWS and to provide your leadership team with the foundation for a broader plan for securing your workloads in the cloud.

In a Monolithic World

Before we can talk about how to secure microservices containers, you need to first fully understand how we got here. The journey to microservices starts with monolithic applications (otherwise known as monoliths).

A monolith is simply a massive, all-encompassing application where all functionality is built into a single app. I like to analogize monoliths as a bunch of chefs in a kitchen all working on a single pot of stew. The chefs are analogous to the developers, all working on a single application where there is a potential for the developers to break other parts of the code that other developers are working on or take down the entire application just to perform maintenance on a particular part of a web site -- for example, the furniture section of the web site.

Microservices moves away from this concept of a bunch of chefs working on a single pot of stew. Instead, each chef would be working on their respective part of the recipe – one focused on marinating the vegetables, another focusing on making the broth, and so on. In microservices, the single monolith would be broken up into parts, with each part of the app or web site for example, being maintained by different teams of developers. An example would be the web site. Instead of a single web site run from a single server, it would be broken up into parts where each part of the site is maintained by a different team and each part running in a different container that all communicate via application programmable interfaces (APIs).

This would allow different parts of the web site to be maintained separately by different teams, preventing the accidental overwrite of the code of other developers, having to take the entire site down just to update or maintain different areas of the site, and so on. 

The Numbers in Containers

The proof is in the pudding for why the world is quickly shifting away from the monolithic mindset to microservices. In a study conducted by IBM in 2017, 59% of organizations surveyed improved application quality and reduced defects while 57% also reduced application downtime and associated costs by migrating monoliths to microservices.

According to IBM’s study, container usage for production enterprise workloads is expected to increase from 25% to 44% within the next three years. Deployment will shift heavily to Hybrid Cloud and support for on-premises -- server-less containerized environments with deployments only on public clouds decreasing.

With this increased movement towards a containerized enterprise, hackers will continue to focus on container bust-outs, a tactic used by adversaries to break out of containers and pivot across container hosts as the attack surface continues to increase, creating a need for you to better understand how to secure them.

Data is the new currency and according to recent reports, is now worth more than oil. A new commodity spawns a lucrative, fast-growing industry, prompting antitrust regulators to step in to restrain those who control its flow. A century ago, the resource in question was oil. Now similar concerns are being raised by the giants that deal in data -- the oil of the digital era. These titans—Alphabet (Google’s parent company), Amazon, Apple, Facebook and Microsoft—look unstoppable. They are the five most valuable listed corporations in the world. Their profits are surging: they collectively racked up over $25 Bn in net profit in the first quarter of 2017. Amazon captures half of all dollars spent online in the United States. Google and Facebook accounted for almost all the revenue growth in digital advertising in the U.S. last year.

Adversaries are consistently on the search for expanding revenues in their illicit business models or creating new ones for targeting, pilfering, and monetizing this new data commodity. With the value of data predicated on the sensitivity of that data, PHI and CUI will surely be on their radars and what better than to take it from where its being stored in public clouds.

This first article in this series covers how to secure Docker containers running in Amazon ECS. Part 2 covers securing AWS S3 buckets, Part 3 covers securing Amazon EC2 instances, and will end with part 4 on securing APIs in the AWS cloud.

Threats to Containers

The number of threats to containers is ever-increasing. Today, these threats include application level DDoS and cross-site scripting attacks on public facing containers; compromised containers attempting to download additional malware, or scan internal systems for weaknesses or sensitive data; container breakout, allowing unauthorized access across containers, hosts, or data centers; a container being forced to use up system resources in an attempt to slow or crash other containers; live patching of applications which introduces malicious processes; and use of insecure applications to flood the network and affect other containers.

Defenses must be placed into the build process, shipment process, and runtime process of containers, which we'll cover in this first part of our series.

Shared Responsibility

Cloud Service Providers (CSPs) operate off a shared responsibility model, meaning, there is a bright line between what the CSP is responsible for and what the tenant is responsible for.

Many organizations make the mistake of thinking that the CSP is responsible for regularly patching and monitoring their servers running in the cloud. However, this couldn’t be further from the truth. The figure below illustrates the division of responsibilities between the tenant of a CSP and the CSP itself (AWS).

Let me first demystify Amazon ECS before I explain how to secure containers running within it.

Amazon ECS

Amazon ECS (Elastic Container Service) is a container orchestration service, much like