Cloud Security Blog

For many years we've implemented security a bit like a watermelon. We've focused on making the outer perimeter hard and resilient, but ignored the soft gushy internals. We would leverage stateful inspection firewalls, proxies, network intrusion detection/prevention, etc to fortify the perimeter. Internally however, security may consist of simple antivirus blacklisting software and possibly some permission tweaking. The end result was that once an attacker could breech the perimeter, internal systems became easy pickings.
A great example is the classic DMZ. Internet accessible servers are all isolated off of a leg on the firewall. If one of those servers becomes compromised, nothing is controlling traffic between servers on the DMZ leg. Thus compromising the remaining servers becomes a simpler task. Once the perimeter is breeched, the attacker gets insider access to the remaining servers.
With cloud computing, specifically public IaaS, the perimeter becomes a dead concept.

...

This topic comes up from time to time, and I had someone ask me about it the other day, so I figured it was worthy of a blog post.

I've seen a lot of discussions revolving around whether you can hide the fact that an operating system is running within a VM as opposed to running directly on hardware. Most of the discussions revolve around interaction with interrupts and memory addresses. In other words, most of the tricks I've seen assume the person doing the probing has shell access to the system.

To be honest, its even easier than that. If you know your way around TCP/IP communications, there are subtle clues you can leverage that can reveal the OS is running in a virtualized environment with nothing more than a TCP three packet handshake. This means that if you know what you are doing, even Web servers can be properly identified.

For example, in this trace we have an Ubuntu server running directly on hardware:

[root@fubar ~]# tshark -n -T ...

Greets all,

Rather than submit a text based entry for today, I would like to point you to a free Webcast I'll be doing for SANS on hypervisor security. The full title is "Why hypervisor security does not scale into public space". It will run live at 1:00PM ET tomorrow, Wednesday the 22nd. Here's the link to the full description and sign up info. If you cannot make the live event, it will get added to the archive for later viewing.

Hope to see you there,

Chris

While teaching 524 this week, the subject of VM cloning came up. Specifically, we were discussing the impact of cloning on how we apply security to our servers. The folks in class enjoyed the topic enough that I thought I would cover it here as well.

Gen2 Building and Auditing Servers

Back when we were building standalone servers, their deployment was not all that unlike how we copied books 1,000 years ago. An admin would configure the server, patch it, lock it down, and then auditors would ensure the server was built to company policy. While automated scripts may be used, there was always some amount of customization taking place, thus the need to audit the final product. Again, this process was pretty similar to how books were created back when scribes were performing the task, which required an in depth audit of every book if you wanted to maintain quality.

...

Just wanted to send out a huge thank you to the most awesome students I had in 524 Cloud Security Fundamentals this week. We had some great questions, and even better discussions, and I plan on cycling in the content the next time I teach the class.

For those who missed the class, I'll be teaching it again in Chicago in November. I will also be speaking at the Cloud Security Summit in January.