Key Takeaways: The AWS shared responsibility model is a vehicle for explaining security control responsibilities between AWS and customer and is not a security panacea for vendors developing on the platform. Closely examine vendor governance controls, specifically vendor management programs to determine if the additional responsibilities of shared responsibility are accounted for in their security program.
In 2012 Amazon pioneered a cloud security concept they now call the “Shared Responsibility Model”. This concept was borne out of the need to clearly communicate the line of demarcation between AWS security responsibilities and ours (loyal AWS customers).
The concept is as obvious as it is useful, if used for good rather than evil.
I use the term frequently to explain to auditors, engineers, c-level folks and basically anyone who will listen that Amazon is responsible for technical security controls from the “concrete through the hypervisor” and explain that as an AWS customer we are responsible for everything else. Everything else includes; the operating system, network and firewall configuration, our software/platform, and of course our data. Here is a diagram taken from the AWS Security Best Practices whitepaper available here. (Evil follows the diagram.)
Now for the evil. I’ve noted on more than one occasion vendors invoking the AWS shared responsibility model to absolve themselves of any responsibility for the security layers that Amazon is responsible for. This is flat wrong and irresponsible.
The vendor is most certainly still responsible for security throughout the entire AWS stack, but what has changes is the type of control. What was a technical control now becomes a governance control.
Scrutiny of their vendor management program (if they have one) should ferret out whether they have a clue as to the difference.