Nodody in These Clouds But Us Chickens

28. Oct, 2009 0 Comments

One of my favorite security books is Cliff Stoll’s the Cuckcoo’s Egg, where he tracks a spy impersonating a well-known computer scientist at the Lawrence Berkeley Lab. Once inside, the culprit hacks into a shared server to stage a series of attacks into other remote systems, located on remote networks such as MILNET. Although he was logged onto the Berkeley system as a local superuser, Stoll works with authorities tracking him across federal and international networks to a hotel room in Hanover, Germany.

It took six months to find this guy—not including all the legal time to prosecute him in Germany. Most people don’t have the time, persistence, nor ability.

Does your cloud provider?

Stoll’s story raises an age-old concern: with a computing environment accessible to the public, across a public network, security threats become location-independent. Worse, it’s often what’s happening on the inside of the building that alerts operators of an attack.

There’s an old saying from Bob Blakely (now with the Burton Group) that there’s nobody here on this network but us chickens. He meant that it’s naïve to assume your environment is secure simply because the perimeter network is “secure”; it’s often the fox hiding in the henhouse, behind the firewall, that wreaks the most damage.

Sure, properly configured networks and authentication systems improves security. But in cloud computing, where many users access and run applications side-by-side with other users—on the same infrastructure—the possibility of lateral breaches inside the data center theoretically increases. Some of these users (or their malware) could be hunting for back doors into other users’ virtual henhouses.

Stoll recommends gaining deeper visibility into the IT infrastructure through ad hoc security systems, constant auditing, monitoring, log sifting, and reporting. Stoll setup offline alarms (a phone paged him when the hacker logged on) and offline monitors.

In a cloud model, you’re relying on the security knowledge, methods, infrastructure, and tools setup by the provider. But users also need to be aware of common threats (malware, data theft, session or tunnel hijacking, impersonation, man-in-the-middle attacks) and should receive guidance from providers on combating them.

According to Gartner, the best way to assess the security capabilities of your provider is to have a third-party audit them. Determining an “appropriate level” of security, according to Gartner, depends largely on your enterprise’s compliance and confidentiality requirements, and how the provider meets (or doesn’t meet) those requirements.

Another option for re-locating applications requiring higher security: private clouds. Understanding how the provider designs and manages private clouds—through virtualization software and other partitioning and delegation schemes—will give you insight into the security level of their environment. How much of the “private” infrastructure is shared with other customers? How much is dedicated just to your company? How is security managed and delegated to users?

In summary, the security of your provider’s environment will depend largely on:

The cloud implementation (no two providers are alike) and architecture (shared vs. dedicated; public vs. private; internal vs. external).
In-house security expertise—and the methodologies in place. Are the Cliff Stoll’s of the world working for your provider with modern tools and understanding?
Security tools or services available for encryption, antivirus, monitoring, intrusion detection systems, or other security capabilities.
Auditing: tools and processes for demonstrating security capabilities to 3 rd-parties through APIs, logs, reports, visual aids, and other means.

–Jason Goodman