Columns
Scary Shadows in Storage
Traditional approaches to network security seem downright medieval. Don't we need something better and stronger?
Halloween is upon us once again and plenty of parents are girding themselves for that familiar unease at seeing their children dressed up to panhandle candy from relative strangers. Allowing your kids to roam outside in the dark, of course, is increasingly worrisome. As a parent, my pulse beats a bit faster until all of my kids are home safe in their beds.
A similar sensation might arise when IT managers consider the increased exposure of data due to the transition to networked storage architectures. Experience with the Internet over the last few years has shown that the increased accessibility of data via open networks casts some pretty scary shadows—such as an increased risk of hacking and malicious software attacks.
This dictum holds true for storage networking as well. As the use of IP storage protocols grows, and your TCP/IP network becomes the universal plumbing for both messaging networks (LANs) and storage networks (SANs), I predict more and more calls for improved protection of the storage infrastructure.
Medieval Methodology
Protecting data in modern networks is done in much the same way as it was back when Halloween was All Hallow's Eve. In medieval times, secret communications between princes were kept out of enemy hands through the use of codes. A message was encrypted by one prince, given to a courier, and decrypted by its intended recipient who alone shared the encryption/decryption key with the sender.
That's much the same method used today to safeguard data traversing a network. Key encryption is integral to IPsec.
Moreover, in medieval times, moats and high walls were used to protect the data repository (the castle) from unauthorized intruders. The same basic strategy is behind contemporary network firewalls, which create an electronic moat between externally facing networks and those inside the company.
In past times, non-repudiability (keeping a message's contents from being stolen) was assured through the use of special signet rings pressed into melted wax that sealed an envelope or scroll containing a message. The uniqueness of the ring, and of contemporary digital signatures, made certain that the message was from the person to whom it was attributed, and the unbroken seal assured that its contents had not been changed or substituted.
Basically, these same concepts are used today to offer what protection is possible to network-based computing. They aren't foolproof, of course. Years ago I interviewed a former National Security Agency official who said that the only way to truly protect the data in a network is not to put it there in the first place. Truer words were never spoken.
Today, however, given the dependency of applications on networks, some risk-taking is required for doing business. Data protection is needed, but providing it means balancing threat potential and protective strategy with financial expense, user inconvenience, application performance and administrative hassle.
Storage Security Appliances
Traditional approaches to network security are largely software-based, involving encryption key distribution and management functions, access control functions and active monitoring functions. For years, it's been assumed that these functions, properly used, would be sufficient to protect not only networks and servers, but also peripheral devices such as storage platforms connected to the servers.
Recently, some vendors have been arguing that we need additional security requirements unique to SANs. Unlike server-captive storage configurations, SANs themselves (the IP variety, at least) are networks prone to eavesdropping, hacking and other attacks.
Typically, the issue for SAN security is framed in terms of a single question: Where best to provide an additional encryption function? Answering this question comes down to determining how you can obtain the greatest value at the least cost (in terms of both dollars and performance). An options matrix, supplied by storage security vendor NeoScale Systems Inc. (Milpitas, Calif.) does a good job of summarizing the options (see "Data Encryption Considerations").
According to this analysis, SAN encryption can be provided as a function of: an application or file system; a storage-management software product installed on all connected hosts; a SAN switch; or a storage-security appliance, like the one offered by NeoScale. Of course, the appliance approach is the preferred choice in NeoScale's matrix, and its reasoning is pretty sound.
The appliance approach spares organizations the cost and hassle of distributed key administration because it's centralized on the appliance. The NeoScale approach also has the merit of side-stepping the drain imposed on applications, servers or networks by the other approaches. The NeoScale appliance is merely a bump-in-the-wire, a concept validated by Novell in other applications.
When extended to IP-based SAN plumbing, the NeoScale approach is preferable to the more clumsy IPsec protocol-based methodology. Arguably, NeoScale could provide not only a workable, extensible, and largely invisible solution for data encryption in the networked storage repository, but also an effective barrier to unauthorized data access and misuse.
How Much is Enough?
All of the above, however, begs the question of whether additional security is really necessary in the storage infrastructure. Shouldn't robust LAN and server safeguards be sufficient to protect against outside intruders?
The answer is yes … and no.
Yes, a strong defense mounted ahead of the storage infrastructure is a must for data protection. All the storage encryption in the world on the back-end storage repository won't mean a thing if the application believes its user to be authorized for data access. Moreover, encryption alone will not protect against the damage that can be done by a malicious program.
What advocates of special storage security provisions seem to be suggesting is that a wiretap doesn't have to be placed in the network leading to the server. It could be placed in the network between the server and the SAN switch, or between the SAN switch and the storage repository. To cope with that scenario, you need strong encryption.
How realistic this scenario is can be debated, of course. But, while the debates go on, SAN-based data may be in jeopardy. Better to err on the side of caution, advocates say.
Do SANs require other types of security beyond encryption? For those whose components are managed via the Simple Network Management Protocol (SNMP), additional safeguards may be required at the device level. SNMP has already been found to provide a convenient inroad for savvy hackers. If a hacker were able to use SNMP to obtain access to the configuration tools on storage arrays that are used to carve disk drives into volumes and LUNs, or to the naming scheme controls on SAN switches, the results could be pure pandemonium.
The bleak scenarios painted by advocates of SAN security may seem paranoid, especially in the absence of documented incidents. However, IT managers, like good parents, know that part of the price to ensure the health and safety of their charges is to fret the small stuff, and maybe even to be a bit paranoid. That way, data storage can make it through another day of hacker tricks and treats.
About the Author
Jon William Toigo is chairman of The Data Management Institute, the CEO of data management consulting and research firm Toigo Partners International, as well as a contributing editor to Enterprise Systems and its Storage Strategies columnist. Mr. Toigo is the author of 14 books, including Disaster Recovery Planning, 3rd Edition, and The Holy Grail of Network Storage Management, both from Prentice Hall.