Out of Control? – AWS and Shared Responsibility

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

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.

A Security Leaders Quest for Commitment in a Sea of Conflict and Compliance.

As security leaders we spend our working lives managing risk, being bombarded with very real threats and vulnerabilities and the vendors who can “solve” them, all while struggling to influence and instill positive change in our own dysfunctional organizations. From time to time we must  step back to own and celebrate the fact that the even the small positive steps for good we take today lay the foundation for a more secure future that none of us alive today can even imagine.



Austin, Devops and Great Folks

There are a couple of people that I want to take the time to highlight; Ernest Mueller @ernestmueller and Tim Virtue @timvirtue.
Ernest’s thought leadership, publication and iteration of “What is Devops” has been exceedingly helpful in my quest to both define devops in my own head as well as communicate the vision and future of operations/development/cloud to others.

Tim is the first security leader that I know of that has presented devops in the context of security. I had the opportunity to listen and speak to Tim this year at SecureWorld Houston.  A slidshare of his presentation is here.

The fact that both of these guys are in Austin?  Bonus!

My take on agile/devops? relative to security?  The fundamentals of information security will remain the same.  Devops will demand that we as security leaders, change our tactics, and speed the heck up, to retain any relevancy in the face of the insane pace that devops and agile processes facilitate.


Amazon, Zocalo and the death of Box.com

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?

Supporting Link:



Using the “3 C’s of influence” to gauge the effectiveness of your security program

While doing my best to absorb a small portion of the wealth of useful information found in Dr. Kenneth Brown’s Great Courses: Influence Mastering Life’s Most Powerful Skill, I had an ah-ha moment that I wanted to pass along.
Dr. Brown states that exerting influence will always result in one of the three following outcomes; CONFLICT, COMPLIANCE, or COMMITMENT.

CISO’s and other security pros who have spent years in the security trenches are more than familiar with the first two; conflict and compliance.  The bulk of our time it seems is spent squarely in between.

If we have finally exerted enough influence successfully managing past conflict, and adeptly wielding the compliance ax to “be compliant”, we tend to call it a win and move on.

The ah-ha moment for me was the realization that the persistent, nagging feeling of uneasiness I have carried since my early days of security leadership is the “commitment gap”, the gap that exists between compliance and commitment.

Failing to achieve commitment from stakeholders, results in, at best compliance. While certainly better than conflict,  compliance by itself is inadequate and a hollow victory to be sure.

Commitment is a high bar, and unfortunately not always something that can be obtained, but it should always be the goal.

Do you agree?  I’d love to hear about your successes, challenges and thoughts on this or any other information security related topic.