Operating a highly available, secure SaaS solution in the AWS cloud is hard. The problems faced by both large and small organizations are roughly the same. Therefore it may be logical to assume that the solutions are as well. The only real difference is scale.
Enter Netflix. I have always been impressed by the depth and openness of Netflix relative to internally developed open source tools they make available through their Open Source Software Center. Startups and emerging companies typically lack resources to utilize best of breed paid solutions for security, availability, cloud management etc.
Netflix has made a conscious decision to pay it forward and I for one appreciate their commitment.
Enter “Security Monkey“. A Netflix security and audit tool for aggregating and reporting on configuration, specifically as it relates to state. The last is important. As explained by Netflix:
“CloudTrail provides verbose data on API calls, but has no sense of state in terms of how a particular configuration item (e.g. security group) has changed over time. Security Monkey provides exactly this capability.”
Security Monkey adds another tool to the AWS security practitioners tool-belt to help mitigate operational risk and prove up our security posture at audit time. Win-Win.
But never give a monkey a gun… BAD security practice.
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.)
AWS Shared Responsibility Model Screen
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.
As widely reported today Amazon officially announced Zocalo. According to the website: “Amazon Zocalo is a fully managed, secure enterprise storage and sharing service with strong administrative controls and feedback capabilities that improve user productivity.”
The Register’s take on the new disruptive AWS product highlights the potential negative effect on Box’s IPO prospects and overall business.
I agree. Box still lacks peer to peer file sharing a critical basic functionality that has always precluded any interest that I have in either their product or company. Does Box understand that not everyone lives in the land of unlimited Internet, even in 2014?