In-Depth
Storage Security, Part 7: Confusing Encryption with Security
Confusing encryption with data storage security can be dangerous to your storage protection strategy.
Concluding this series of columns on storage security is a delicate thing. Architectural options are many, and it is easy to become mired down in the details and nuances of the vendor pitches—or worse, to lose sight of objectives that prompted this investigation in the first place.
The original question we asked was simple enough: does the storage infrastructure require its own special security capability? More to the point, are there special requirements that are more closely associated with the data storage and data management processes than with the secure operation of LANs or servers? Do these requirements represent special vulnerabilities that organizations must address? If there are such requirements and vulnerabilities, do they require special security provisions at the storage layer of the IT infrastructure?
Almost universally, the answer from vendors has been a resounding, "Yes!" Storage-layer security is missing in most organizations, they say, and it needs to be addressed immediately, usually through a program of universal data encryption.
After interviewing a number of vendors, it seemed clear that storage security is largely synonymous with encryption. Encryption, however, is properly viewed as the last line of data defense—intended to maintain the secrecy or privacy of data when all other security measures have failed.
If you think about it, encryption does not protect against data loss—a tape can still fall off the back of a truck en route to off-site storage and a laptop can still be stolen from the table at a seminar. Encryption merely makes the stolen data more difficult to access by someone who doesn’t have the password or USB key token or biometric identifier to unscramble it. In the storage realm, "defense-in-depth" translates to protecting decryption keys—as well as data itself—using a combination of what you know, what you have, and who you are to define who can unlock the data.
Furthermore, encryption does not protect against storage vandalism, which aims less at knowing the contents of a file than assuring that the data, regardless of whether or not it is encrypted, will fall off the edge of the earth, much like Columbus’s little known fourth ship.
Storage vandalism takes many forms. In one instance, the bad guys crack network security, access the SAN switch via its IP network management connection, and scramble all of the zones and pathways through the FC fabric so that data gets parked on physical disk drives with no rhyme or reason. In another approach, the intruder breaks application and network security to become a legitimate user, then encrypts a critical database with a new unbreakable key, denying the owner access to the encrypted data—or holding the data for ransom. This has actually happened at on-line casinos.
Expanding your scope, there is the threat that was cited at the outset of this series: distributed denial-of-service attacks. As the government institutions, banks, media outlets, and airports of Estonia know all too well, flooding all inroads to systems and networks with nonsense traffic generated by anonymous zombie systems has much the same result as corrupting, holding for ransom, or deleting data altogether: access is denied to legitimate users. As in the case of Estonia, you may be hard pressed to identify the culprits or their motives for the attack.
Encryption is Not Security
Given this perspective, it is clear that storage encryption is not the same as storage security. While encryption may be an important component, encrypting something is not the same as securing it. This point always seems to get lost in discussions of storage encryption and devolves into a debate over two points: where do you spend the processing cycles to encrypt data so that it doesn’t add latency to sensitive read/write processes, and how do you manage the encryption/decryption keys once you have encrypted the data? These are important questions, to be sure, but they relate only to encryption—and encryption alone is not storage security.
This past week, EMC announced a "secure" version of its CLARiiON storage array that expanded just a little on the "storage security equals encryption" story. The company that its latest wares included provisions for "secure access to the system." EMC summarized this as "a feature" that would give managers the ability to "define a security administrator role," enabling certain admins to authorize specific users to access arrays or to add arrays to a domain, but denying the same "administrator" the capability to monitor or configure the CLARiiON array itself.
EMC also touted new features that would provide a "secure infrastructure"—basically leveraging IP address filtering to control and confine access to the CLARiiON array to specific management workstations and to encrypt and authenticate any access made to the array via the storage array’s command line interface.
Finally, the company touted, again under the rubric of "security," "compliance and audit features" that would document system login attempts and leverage the Internet Time Protocol (NTP) to provide consistent and accurate timestamps on access logs.
While these three "security features" are hardly innovative and probably should be part of the on-board operating system of any piece of equipment installed in a corporate LAN, EMC’s announcement lays bare a problem in the thinking behind storage architecture up to now. Despite all the talk about networked storage that has permeated the trade press since the mid-1990s, storage has still been designed to be a peripheral device, not a peer node in a network (however you define "network," which most storage vendors have taken to also include channel attached storage). Consequently, even the most mundane security provisions, which are commonly extended to real networking equipment and server nodes, have been largely absent from the technology of storage. These include even such Security 101 features as secure administration and audit logging.
Still in its Infancy
Compared with servers and networks, storage technology is still in its infancy with respect to security. It is difficult to define what its security requirements are and whether they should be fielded on the storage platform itself or in the storage fabric or ahead of the storage infrastructure altogether—in the LAN or server environment. Clearly, whatever security requirements are defined and security standards articulated for locking down the storage infrastructure, they will ultimately need to integrate and interoperate with security provisions within other infrastructure layers.
The vendors with whom I chatted were in universal agreement on another point with respect to storage security: the storage industry’s trade association, SNIA, has done a very poor job in defining storage security requirements or specifying any framework for integrating storage security with the broader security service fielded by companies today. We made a tongue-in-cheek reference to Dr. Seuss earlier in this column as a metaphor for the debate over where encryption is best provided ("in a box, with a fox, on a boat, with a goat"). In fact, we picked the wrong metaphor. Lewis Carroll’s Alice in Wonderland would have been a better reference, at least as it pertains to the industry’s generally poor showing on defining storage security. Exploring this issue is very similar to taking a wild ride down a rabbit hole.
The message to the IT manager about storage security: you are on your own. It will likely require a grassroots, user-based, effort to define for the storage makers what you think you need and how it needs to work with other security capabilities you have already fielded before useful features will begin to appear on products in the storage market. To help think the problem through, the Data Management Institute will shortly launch a community Web site, SecurityManagement.org. Watch this space.
Your comments are welcome. jtoigo@toigopartners.com.