Storage Encryption: Not the cure for the common admin?
Much has been gurgled about the security, or more precisely the lack thereof, of Fibre Channel and Storage Area networks. While it's true that FC appears to have been designed without proper consideration for operational security it's not the case that the issue isn't being addressed.
That being said with so many rapidly expanding and incorrectly configured networks shooting up all over the place encryption technology appears to be the silver bullet people are turning to secure data from the various types of attacks and system misconfiguration (WWN Spoofing, E-Port Replication, Incorrect LUN Masking, Zone hops, the list goes on and on and on), the idea being that just because someone might be able to see the data it doesn't mean they'll be able to read the data.
Like people who don't worry about tapes falling off the back of a truck this is dangerous thinking and does nothing to address the fundamental issue of what procedural or technological failure is exposing the data in the first place. Encryption of data at rest is a component of a larger information security strategy, it's not the security strategy and people should have any illusions that it is.
Since I plan to do other things today we'll ignore the operational security issues (Much to the chagrin of any security professionals reading this I'd imagine but the sun has shown up for the first time in a week and I plan on avoiding it like all the other vampires.), and just focus on the technical aspects.
If you want to secure information at rest you have a number of options and as per usual they all have their drawbacks. Lets start at the host and move on from there.
Host based data encryption technologies are nothing new what with most of the Enterprise UNIX operating systems offering or soon to offer file system encryption as an option. Things get interesting when you begin generating point in time copies and mounting them up on other hosts as you need to develop your own key exchange policy to ensure you can read the copy. Into this then come things such as RSA File Security Manager/RSA Database Security Manager, and the up coming PowerPath Data at Rest Encryption. All of these are/will be interoperable with RSA Key Manager (RKM) which means files/databases/volume encrypt/decrypt requests will be handled by RKM as per whatever policies are put in place.
The issue with Application/Filesystem/Volume level encryption of course is that for the most part you're limited to supported versions of Applications/Host Operating Systems and you burn CPU cycles in the clear-text/cypher-text operations being carried out in software. Lets be honest though, the CPU wars have resulted in cheap CPU cycles for everyone so much so that it's driven server virtualization via Virtual Machine so one wonders how real he CPU crunch problem is for most people? I don't doubt it exists in some cases, I do doubt it exists in all cases.
Jumping off the host and into appliance land. There are more than a few vendors in this space (Decru, Neoscale , Vormetric) though the tend to sit at different places in your environment. The Decru & Neoscale's of the world sit in the fabric usually oblivious to the nature of the data flowing through them, while Vormetric inserts itself into the access operations occurring on the server(s) it's protecting. Something like Tumbleweed MailGate puts itself in front of your Email servers and there are other devices for other use cases. Customers tend to like the appliance approach as they are self contained units which are easy to manage and not too difficult to deploy.
However, appliances tend to fall down on the job when customers start looking at scaling port count or performance/throughput. Depending on your needs you could soon find yourself managing tens or hundreds of appliances to get you to where you want to be, and the management tools might not scale that well with the worst case having to manage each appliance individually.
While some appliances may sit in front of the switch the Cisco/RSA Storage Media Encryption announcement allows for customers to choose to do the encryption in the switch itself. By adding an SME card you can choose the paths you want encrypted, the standard switch management tool comes with basic key management functionality with the option to step up to RKM for more advanced key management functionality. The drawback here of course is that currently it's a single vendor solution (Though I'm sure Brocade aren't that far behind), limited to a specific set of switches and does require you to buy extra options for a switch you may or may not already have.
Finally we come to encryption at the target, be that target disk or tape. The management overhead here tends to be the smallest but the acquisition cost tends to be greatest. It's not like a software upgrade will add media encryption so you'll probably have to buy new tape drives or storage arrays to acquire the functionality. IBM/Sun offer tape drive encryption on their own tape drives, LTO-4 has it natively and Fujitsu offer 128 bit AES with their Eternus range of storage arrays but right now that's as good as things get. On the array side of things things get awkward when it comes to heterogeneous replication between different vendors arrays so people need to be aware of what they're buying into if they go for array level encryption.
All in all there's a solution for every data at rest encryption problem but people would probably be better served examining what they have in place already and ensuring that's secure before they should start looking at encryption. Implemented incorrectly the best/worse cases could be data exposure or data erasure. Which one is worse for your business depends on your circumstances and whatever regulations you need to operate under.
