Other than various one- or two-day seminars, I attend two main conferences each year, the RSA Conference and Interop. I like RSA because its focus is on security. And I like Interop because its focus isn't on security. That is, because information security requires fairly comprehensive knowledge of all facets of IT, Interop is valuable in allowing me to round out my knowledge.
At the RSA conference, I feel like the proverbial kid in a candy store. So many topics, so many interesting tracks, coupled with discussions from industry experts. All the sessions are so tantalizing, it's nearly impossible to decide which to attend. What works best for me is to choose a couple of areas of concentration and then head for the sessions that sound most relevant and interesting.
I was back at RSA last month, and this time my areas of concentration were cloud computing and virtualization. I've mentioned before that my company's IT department has been meeting with several cloud computing vendors to determine whether moving some of our server infrastructure to the cloud would save the company both capital and operational expenses. We're in a fairly serious slump, so the project is timely. Of course, when an initiative gains momentum quickly -- like this one has -- security is often left in the dust. Before things get out of hand, I want to be sure I've provided appropriate and meaningful security requirements. At RSA, I was hoping to gain additional knowledge to help me ask the right questions the next time the cloud vendors show up.
Another valuable resource in helping me evaluate the security risks of cloud computing is a document prepared by the Cloud Security Alliance. (You can download the PDF at the alliance's Web site.) Focusing on 15 key domains of concern, this document provides in-depth insight and perspective. Since it's more than 80 pages long, I can't just hand it to a cloud vendor and ask for comments. Instead, I will extrapolate key points, combine them with my own, and create a cloud computing security controls matrix, similar to what I've done for application security.
Good Questions
Each of the 15 domains covered in the document raises some very interesting points. For example, what happens when a cloud vendor is served with a subpoena? Will it tell the affected customer? Or what if we don't want our source code to live on servers in Russia? Can we opt out of certain geographical points of presence? And in the case of a vendor that provides data encryption for its customers, who manages the keys? I don't have space to do justice to what the CSA document covers, but I can tell you that it is a good starting point and will stimulate you to think of other concerns.
But back to RSA and my other area of concentration, virtualization. Those sessions simply validated the concerns that I have already brought to the attention of the project team that's deploying VMware virtualization tools. For example, the VMotion feature allows you to move virtual machines from one physical server to another with no noticeable downtime. From a security perspective, such movements had better happen on a dedicated virtual LAN. Then there's vCenter Server, which allows us to provision, monitor and manage a virtual data center through a single interface. If you don't lock this application down properly, a malicious user could cause some serious damage, without having to walk into the data center.
So, once again, the RSA Conference was well worth my time. Now I'll work on creating my cloud computing security controls matrix.
This week's journal is written by a real security manager, "Mathias Thurman," whose name and employer have been disguised for obvious reasons. Contact him at mathias_thurman@yahoo.com.
Join in. To join in the discussions about security, go to computerworld.com/blogs/security