This is a companion post to our Cloud Security Masterclass on the subject. Our objective is to examine some real world, published cloud exploits and examine both the motivations and techniques of the hackers responsible for them so that you can understand who you are up against, how and why they act, and how to better protect your cloud infrastructure.
Much has been said about Amazon S3 security on Amazon Web Services (AWS) in the press and technical publications, and much of it is oversimplified and of limited practical use. Amazon S3 is an incredibly simple cloud service to use, but adequately securing your S3 resources is anything but simple, as too many organizations have discovered.
Lately, we at Fugue have been demonstrating live hacks against cloud infrastructure based on real events in the news. We often walk through a theft of data from Amazon S3 by exploiting little-known misconfigurations of Security Groups, EC2, IAM, and S3 in combination. See A Technical Analysis of the Capital One Cloud Misconfiguration Breach.
Software is eating the world. In the age of cloud computing, developers now own the security posture of your enterprise because the cloud is fully software-defined and programmable. If that scares you, it's because you haven't given your developers the tools to create secure systems. The good news is that you can, but you need to change how you think about security.
UPDATE: August 26, 2019Since posting this, AWS has made some public statements regarding the breach that shed some light on what likely happened. From their response to Senator Ron Wyden, AWS stated:"As Capital One outlined in their public announcement, the attack occurred due to a misconfiguration error at the application layer of a firewall installed by Capital One, exacerbated by permissions set by Capital One that were likely broader than intended. After gaining access through the misconfigured firewall and having broader permission to access resources, we believe a SSRF attack was used (which is one of several ways an attacker could have potentially gotten access to data once they got in through the misconfigured firewall." "As discussed above, SSRF was not the primary factor in the...
In the last part of this series, we're going to look at the final stages of the software development life cycle (SDLC)—deployment and operations. As a reminder, in parts one and two, we discussed the overall concept of shifting left for security and compliance, and laid out some best practices for how to do so during the development and testing phases of the SDLC. In this post, we'll cover how using policy as code and baselines allows you to leverage all the work done in the earlier phases to prevent deployment of misconfigurations and ensure that your deployed infrastructure remains functional and compliant over time.
In an earlier blog post, we discussed at a high level how security can shift left regarding cloud infrastructure. In this post, we'll drill in with more detail on how this can be done through the discrete phases of the Software Development Life Cycle (SDLC), beginning with the development phase, and extending through testing, and ultimately all the way to deployment and ongoing operations.
We're hearing a lot about “shifting left” these days in the industry, and like most popular terms the meaning can be hard to pin down, and some of the implications buried. This post will focus on how to shift security and compliance left in cloud computing. These two functions are closely related, but the operational aspect of each is quite different. However, before we get into specifics, it might be helpful to define what we mean by shifting left in general.
There is a lot of talk about DevSecOps these days, and we've been working in the area for years now and have learned some things that work and some that don't. First, we'll give you our view on what DevSecOps is, and then we'll make a few recommendations on how to start doing it and get real results in an hour or two!
A lot of folks have realized that manually fixing cloud infrastructure to correct security and compliance issues is just too slow and error prone to handle the threat landscape on the cloud. An increasingly common approach to speeding up remediation these days is to use cloud functions, such as AWS Lambda or Azure Functions, connected to a threat detection tool, to remediate specific cloud misconfigurations.