This post was originally written for
Trend Micro .This is the 4th & final post in a short series on the shared responsibility model for security in the AWS Cloud. Please take a few minutes to read the others: part 1, part 2, and part 3
Shellshock
Shellshock (which entails a number of CVE’s ), is a bug that affects bash, a command line interpreter/shell. This bug was rated a 10/10 by the National Vulnerability Database, meaning that it could have a huge impact and is easily exploitable.
If you’re wondering just how easy it is to exploit this bug, check out this video demonstration I pulled together.
Needless to say, this was one bug where “drop everything & patch now” was the appropriate reaction.
Whose Responsibility?
When looking at whose responsibility it is to patch this bug, we find a very interesting case. This is essentially an operating system bug. Therefore, it’s reasonable to assume that some AWS services were affected under the covers.
Since it’s AWS’ responsibility to manage the security of all supporting software for services like Amazon SNS, Amazon SQS, Amazon Redshift, and others, we will probably never know the extent of how this affected the underlying framework of these systems.
And that’s the point.
Abstract and container services on AWS are designed to be highly available and resilient. We–the users–should never notice something like a patch to an OS. Shellshock is a great example of this. None of us have any idea how much or little effort was required by AWS to resolve the issue.
Your Responsibility
EC2 instances are another story, though. For any EC2 instances, it was entirely your responsibility to manage the patching or deployment of mitigating controls to protect your deployment from Shellshock.
Specific to this vulnerability, it did take a few days for the industry to completely determine its scope, which meant there were several patches issued to address aspects of the bug. This is where a mitigating control like an intrusion prevention system (IPS) can save you some stressful nights.
An IPS scans the network traffic to and from your instances, and when it see an attack like Shellshock, it can drop those packets from the network immediately, shielding you from the attack.
Sharing Security Responsibilities
Over the past couple of weeks, we’ve seen how the shared responsibility model for security in the AWS Cloud is applied in the real world . We’ve seen how bugs in the hypervisor are handled, how issues like POODLE can impact different services, and finally, how bugs like Shellshock work in EC2.
As you’ve seen, the shared responsibility model for security is simple to explain but can be nuanced in its application. The key is to understand where the line for the division of responsibilities is for each service that you are using.
Shared Responsibility In Action from marknca
This series was based on slides from the talk that I gave at an AWS meetup at AWS HQ in October.
I’m at #reInvent today. Swing by SEC313, “Updating Security Operations For The Cloud](http://4mn.ca/1wFCtoP).” this afternoon (2:15pm PST, 12-Nov-2014) to see how you can improve your security practice by leveraging features of the AWS Cloud.
If you’re not onsite, you can always catch me online @marknca.
