Archive

Blogging is very much a broadcast medium. Sure, people comment every now and then, but I like talking to people; I like to understand what *they* think.

I have some folks I’d like to “interview” for my blog on the topic of cloud – specifically practitioners who have relevant cloud computing experience relevant to ops, compliance, risk, and security. I don’t want anecdotes or take ill-defined polls and I also don’t want to regurgitate my interpretation of what somewhat else said. I want to hear you say it and let others know directly what you said.

Not interested in vendor pitches, thanks.

The structure would be somewhat similar to my Take 5 interviews. I’d preferably like folks in the architect or CISO/CSO role who have broad exposure to initiatives in their large enterprise or service provider companies.

Here’s the biggest challenge I see in Cloud deployment as the topic of security inevitably occurs in conversation:

There’s too much of it.

Huh?

More specifically, much like my points regarding networking in highly-virtualized multi-tenant environments — it’s everywhere — we’ve got the same problem with security. Security is shot-gunned across the cloud landscape in a haphazard fashion…and the buck (pun intended) most definitely does not stop here.

The reality is that if you’re using IaaS, the lines of demarcation for the responsibility surrounding security may in one take seemed blurred but are in fact extremely well-delineated, and that’s the problem. I’ve seen quite a few validated design documents outlining how to deploy “secure multi-tentant virtualized environments.” One of them is 800 pages long.

Check out the diagram below.

I quickly mocked up an IaaS stack wherein you have the Cloud provider supplying, operating, managing and securing the underlying cloud hardware and software layers whilst the applications and information (contained within VM boundaries) are maintained by the consumer of these services. The list of controls isn’t complete, but it gives you a rough idea of what gets focused on. Do you see some interesting overlaps? How about gaps?

This is the issue; each one of those layers has security controls in it. There is lots of duplication and there is lots of opportunity for things to be obscured or simply not accounted for at each layer.

Each of these layers and functional solutions is generally managed by different groups of people. Each of them is generally managed by different methods and mechanisms. In the case of IaaS, none of the controls at the hardware and software layers generally intercommunicate and given the abstraction provided as part of the service offering, all those security functions are made invisible to the things running in the VMs.

A practical issue is that the FW, VPN, IPS and LB functions at the hardware layer are completely separate from the FW, VPN, IPS and LB functions at the software layer which are in turn completely separate from the FW, VPN, IPS and LB functions which might be built into the VM’s (or virtual appliances) which sit stop them.

The security in the hardware is isolated from the security in the software which is isolated from the security in the workload. You can, today, quite literally install the same capabilities up and down the stack without ever meeting in the middle.

That’s not only wasteful in terms of resources but incredibly prone to error in both construction, management and implementation (since at the core it’s all software, and software has defects.)

Keep in mind that at the provider level the majority of these security controls are focused on protecting the infrastructure, NOT the stuff atop it. By design, these systems are blind to the workloads running atop them (which are often encrypted both at rest and in transit.) In many cases this is why a provider may not be able to detect an “attack” beyond data such as flows/traffic.

To make things more interesting, in some cases the layer responsible for all that abstraction is now the most significant layer involved in securing the system as a whole and the fundamental security elements associated with the trust model we rely upon.

The hypervisor is an enormous liability; there’s no defense in depth when your primary security controls are provided by the (*ahem*) operating system provider. How does one provide a compensating control when visibility/transparency [detective] are limited by design and there’s no easy way to provide preventative controls aside from the hooks the thing you’re trying to secure grants access to?

“Trust me” ain’t an appropriate answer. We need better visibility and capabilities to robustly address this issue. Unfortunately, there’s no standard for security ecosystem interoperability from a management, provisioning, orchestration or monitoring perspective even within a single stack layer. There certainly isn’t across them.

In the case of Cloud providers who use commodity hardware with big, flat networks with little or no context for anything other than the flows/IP mappings running over them (thus the hardware layer is portrayed as truly commoditized,) how much better/worse do you think the overall security posture is of a consumer’s workload running atop this stack. No, that’s not a rhetorical question. I think the case could be argued either side of the line in the sand given the points I’ve made above.

This is the big suck. Cloud security suffers from the exact same siloed security telemetry problems as legacy operational models…except now it does it at scale. This is why I’ve always made the case that one can’t “secure the Cloud” — at least not holistically — given this lego brick problem. Everyone wants to make the claim that they’re technology is that which will be the first to solve this problem. It ain’t going to happen. Not with the IaaS (or even PaaS) model, it won’t.

However, there is a big opportunity to move forward here. How? I’ll give you a hint. It exists toward the left side of the diagram.

There are many projects in my time that I’ve been passionate about, honored to have curated and personally gratified by others’ responses to, but none more than HacKid.

What is HacKid?

HacKid is a new kind of non-profit conference focused on providing an interactive, hands-on experience for the entire family — kids aged 5-17 & their parents — in order to raise awareness, excitement and understanding of technology, gaming, mathematics, safety, privacy, networking, security and engineering and their impact on society and culture.

The first HacKid conference is in Cambridge, MA on the weekend of October 9th and 10th, 2010.

The activities and sessions at HacKid are many and varied in topic. Some of the things the kids and parents will do are:

Learn About Online & Social Networking Safety

Make a Podcast

Learn How to Deal With Cyber-Bullies

Learn Kodu & Scratch Programming Languages

Build An Interactive Robot 3D printer

Discover Hair Hacking

Learn How the Internet works

Get Creative With Food Hacking

Manipulate Hardware & Software For Fun

Dive Into Electronics

Learn magic

Build a trebuchet

Meet & interact With Law Enforcement

Learn About Low-impact Martial Arts/Self-Defense

There’s a ton of stuff to learn and get excited about.

The gist of the idea for HacKid (sounds like “hacked,” get it?) came about when I took my three daughters aged 6, 9 and 14 along with me to the Source Security conference in Boston. It was fantastic to have them engage with my friends, colleagues and audience members as well as ask all sorts of interesting questions regarding the conference, however while they were interested in some things, it wasn’t engaging for them because it wasn’t relevant, it wasn’t interactive, it wasn’t hands-on…it wasn’t targeted to them.

…and it wasn’t meant to be.

I went home that night, registered the domain name, tweeted about it and was overwhelmed with people who said they wanted to help make this a reality. The next day I reached out to the folks at Microsoft’s New England Research and Development (NERD) center in Cambridge and they kindly volunteered their amazing facilities. From that moment on (a few months) it’s been on like Donkey Kong.