The Capital One breach is grabbing a lot of attention lately. This breach is notable not only for its size of 100M stolen customer records but also because the data was taken from a site hosted at AWS. I will refrain from rehashing the details here; you can read them on CNN, Krebs on Security, and a story on Ars Technica that discusses the alleged perpetrator of the attack.
Based on publicly available information, the Capital One breach looks like many previous mega-breaches: a well-known vulnerability was exploited allowing an attacker access to confidential data.
The alleged vulnerability exploited in this breach was Server Side Request Forgery (SSRF), a vulnerability that is present in many cloud and virtualization platforms, including AWS. It is a favorite vulnerability among hackers since it is relatively easy to exploit and, when successful, can provide extensive data access. Evan Johnson from Cloudflare published a great blog that explains SSRF in detail.
Here is the important part about SSRF, is not new, unknown, or weird. It is easily mitigated with properly configured access controls and/or a properly configured Web Application Firewall— both of which are accepted best practices for any application in the cloud. OWASP publishes a great “Cheat Sheet” on how to protect against SSRF.
SSRF has quickly become the latest vulnerability outrage. Even Capitol Hill has decided to weigh in demanding AWS fix their “rented servers.” You know things are going haywire when the US Senate is offering up cloud security architecture advice.
SSRF is a genuinely serious vulnerability, but its rise in prevalence is closely aligned to the increase in cloud usage. SSRF also highlights the dangers of “lifting and shifting” applications to the cloud from on-premise deployments.
Traditional on-premise environments are secured like a castle. There is a robust perimeter to control access. However, once inside the perimeter, access is largely unrestricted. On-premise environments have a clearly defined “inside” and “outside,” making access controls simple with no sharing. Consequently, applications developed in such environments have simple access control requirements.
In contrast, cloud environments, like AWS, have a more complex, shared security model. Every service (or server) is a “castle” There is no perimeter in the classic sense. Applications are distributed across any number of micro-services, containers, and virtualized hosts. Access rights must be managed at every layer, not merely the perimeter. Moreover, those access rights must be dynamic and able to handle the ephemeral nature of cloud systems (which partially explains why AWS’ Metadata Service lacks SSRF protections).
Lack of granular access rights is how a “lift and shift” migration can introduce security vulnerabilities into an environment. Applications developed in an on-premise environment may have weaker, simple access rights. When those applications are migrated to the cloud, those same weak access rights are migrated along with them. Since the cloud has a more complex, shared model, those weak rights now expose a vulnerability that was not as relevant in an on-premise deployment.
In other words, migrating from on-premise to the cloud has dangers.
So, what are some lessons we can take away from the problems of Lift and Shift?
1. On-Premise Security Does Not Seamlessly Transfer to the Cloud
Cloud environments demand security that is cloud-specific. When migrating applications to the cloud, security must be rearchitected to suit the specifics of the cloud. Access rights are an example of how something that is simpler on-premise, becomes more complex in the cloud.
2. Shared Security Model
Cloud environments have a shared security model. This means application owners are responsible for the security of their applications. The cloud service provider only supplies a minimal set of security protections. This shared model is another reason why security must be specifically architected for the cloud.
3. Prioritize Access Rights
Do not relegate access rights to later in the development process. Access rights must be defined and enforced in the earliest stages of development. Otherwise, relaxed rules will make their way to production, where it becomes significantly more difficult to change them.
4. Automate Access Rights
The importance of access rights also necessitates automating them to allow for consistent and persistent enforcement. That also allows you to develop them in an iterative manner, much like the application itself. Manually controlling rights is a recipe for mistakes and exploits like SSRF.
5. Automate Security
While you are automating access rights, automate security as well. When security is deployed in a consistent manner, in the earliest stages of development, it too can be iteratively perfected to defend against exploits such as SSRF.
As organizations move more applications to the cloud, it is inevitable that hackers will exploit vulnerabilities specific to the cloud with greater frequency. We can look to the Capital One breach as a warning. While the cloud offers tremendous security benefits, it also demands we approach security differently.
