Skip to content ↓ | Skip to navigation ↓

A number of high-profile data breaches have resulted directly from misconfigured permissions or unpatched vulnerabilities. For instance, the 2017 Equifax breach was the result of exploiting an unpatched flaw in Apache Struts allowing remote code execution. More recently, the Capital One breach last year stemmed from a misconfigured web application firewall. Verizon’s 2020 DBIR reported that only hacking was more prevalent than misconfiguration errors as the culprit of data breaches.

With more and more companies moving to cloud or hybrid environments, it’s important to understand how security in the cloud works. Even though cloud providers such as Amazon Web Services, Microsoft Azure,and Google Cloud Platform offer world-class security of their infrastructure, customers of these cloud services are responsible for their share of security obligations.

For instance, AWS provides the following breakdown of shared responsibility in their documentation:

AWS Cloud Shared Responsibility

The most important distinction here is between security ‘of’ the cloud and security ‘in’ the cloud. In general, AWS is responsible for the physical infrastructure, network, database services and so on, i.e. the cloud, while customers are responsible for whatever they are doing in the cloud. However, depending on what you’re doing in the cloud, your responsibilities might not exactly follow this picture. For instance, if you’re using AWS Lambda, a server-less compute platform, then your shared responsibility picture looks like the following:

Cloud - Shared-Responsibilty-Model-LAMBDA

Notice that AWS assumes some of the security obligations from the previous breakdown. For instance, now you, the customer, no longer need to worry about network traffic and firewall configuration. These differing levels of responsibility are directly proportional to the amount of control and flexibility you want in the cloud.

Most cloud customers are not using a single service at a single level of responsibility in their deployments. In large and complex cloud environments, inconsistent configurations and patching are hard to manage manually. So, if you’re building infrastructure in the cloud, then you ought to be automating your build-out. Configuring security groups, networks, firewalls, access, encryption and so on by hand introduces opportunities for mistakes. Automation is also crucially important for checking deployments continually and for remediation.

Join me at SecTor 2020 where I’ll give an overview of shared responsibility and configuration management in the cloud.