All Your Virtualized Storage Are Belong To Us…
A point I’ve raised in my Four Horsemen presentation that I’m spending a lot of time researching is on the topic of how virtualization is accelerating the adoption of SAN storage and to a larger extent I/O virtualization and what that means to security.
I wanted to introduce this topic as a teaser to a larger series of posts. This is not a treatise on the subject and is deliberately thin on detail and thick on corner case illustration. You have been warned.
What I’m both extremely intrigued by and really worried about as we move further along the virtualization continuum is the strange duality offered up by the intersection of consolidated compute, resources and information overlaid with tremendous distributed mobility and the security (or lack thereof) of this pooled storage holding all our crown jewels.
Centralized storage offers great benefits: easier to backup/restore, simpler management, better cost effectiveness, facilitated resiliency and potentially better security. However, that all depends upon how and who is actually responsible for the operational aspects of security and defining the policies and compliance requirements in the first place.
We see the grappling matches of responsibility being waged between who is responsible for securing our basic virtualized environments from the "server" and "network" perspective today and we’re struggling for answers.
What about securing storage?
This isn’t an argument about filesystem partitioning, ACL’s and GPO. This is a whole other networking fabric or set of appliances that are being deployed, conntected to our hosts and administered/secured by…who?
Think about it; we’re moving away from local storage to pooled "networked" storage. Not only is our critical information stored in these pools, but the Virtual Machine (VM) images are also. Databases too. One stop shopping!
Sure, this has trend has been going on for years, but virtualization and consolidation are shining the ugly light on the fact that we’ve been covering our eyes as to what this means to our overall security posture for many years. That’s not going to last much longer.
Depending upon who is responsible for the architecture of your virtualized storage, your perfectly reasonable asset, network segmentation and layered defense may go out the window when "machines" from multiple tiers all interconnect to a single storage fabric.
It shouldn’t happen, but it does; think about your (coming soon) virtualized DMZ’s and what that might mean to this diagram:
You might notice that for "simplicity" although the management/service console network is represented, the storage "network" is not. I’ll bet dollars to doughnuts that all three tiers would be serviced by a single SAN in the real world…
I’ve heard that over your dead body would you combine multiple network zones on the same physical/virtualized host like in the picture above. Strangely though I bet many of you connect physical assets (virtualized or not) of varying criticality to the same SAN fabric though like in the Brocade diagram on the top left.
What exactly is the difference?
Will the real SAN storage security experts please stand up? OK, how
about if you’re faking it really well? Um, how about you storage
admins posing as security experts? Server admins who eat LUNs for
lunch? Network engineers who admin Cisco, Brocade, Xsigo I/O virtualization switches?
I am *not* a security storage expert but I’m reasonably skilled in many
other elements of security, and that’s really the point of all of
this. I recognize there are many things that can be done to segment/zone/mask/secure
storage, but I don’t have those skills and I don’t know how to assess others’ either. I’d bet that if you haven’t
been involved in securing storage for quite some time, even if you’re
being drug into virtualized environments, you’re in the same boat?
Food for (scary) thought.