Review: Storage Security Products

Although we're not picking a winner in this review, Cisco's 9216i switch (pictured) impressed us with its broad range of functionality. Granted, it does absolutely nothing to protect hosts, but the 9216i let us handle authorization, access control and encryption from a single platform and was easily the most comprehensive offering we tested. Virtual LANs nicely restricted which devices, and even LUNs (logical unit numbers), could be seen from any given host, meaning that a breach mustn't serve up all your data, just that which the compromised server must see. If compliance is a concern, Cisco's integration with RADIUS provides the ability to maintain access logging.

Although the Cisco 9216i--or any other switches we tested--won't be a fit for installations with other vendors' Fibre Channel infrastructures already in place or that use NAS or iSCSI, we found viable ways to satisfy storage-security needs in nearly any configuration.

Access Control

Access control should be straightforward. And if you simply need to determine who can manage your storage network, then it is. But once you start considering who can see what data, things aren't so clear-cut. The problem lies in the overlap of the storage infrastructure with the users and groups defined in most IT operations. For example, in a database you create users and give them access to the data, so the database-encryption products we looked at did not worry about access control. For file- and block-level encryption products, only an add-on at the client level could allow access control by user. Decru has a good solution to this problem--we could even define which applications had access to a given file or folder.

But switch infrastructure products are just that--infrastructure gear. Do you define all ADS users as having access to your Ethernet switches? Do you define which network resources they can see and whether they can modify them? No, and you can't with a Fibre Channel switch, either. Access control in that sense does not exist on FC switches. Rather, you can say what LUNs a given server can see, but below that point you have to use the OS on the server to lock down access. This makes perfect sense from a storage viewpoint because the storage network is serving up blocks, and as such doesn't know about the file, let alone who can read and write it. That's an OS function. Most iSCSI products work on the same principle, that you're controlling access elsewhere.

In practice, we'd like to see some overarching scheme that gives storage or security managers the ability to say, "These ADS users can see this data." It sure would help us lock things down. Maybe smart Fibre Channel switches will do that for us, maybe not.

If you worry about your storage devices, disks and/or tapes being physically stolen, storage-level encryption will help you sleep easier. Several vendors let us encrypt data on a tape and store the key encrypted on that same tape. The master key is stored only on the device in question or on smart cards that you control. But you must store one of those smart cards at a remote site or you risk not being able to restore backups should you suffer a catastrophic disaster in your data center. Remote backup devices--CPD appliances and real-time data synchronization products combined with encryption--are another solution to this problem if you have two sites with high-bandwidth connections. Both create another step and another cost factor in restoring lost data or retrieving data to respond to litigation.

If you're concerned only about an attacker--internal or external--getting certain pieces of data stored in the database, a database-encryption tool should fill the bill. This type of product lets you encrypt tables and/or columns in the database, then grant decryption rights only to certain users. You can feel comfortable knowing that compromising one machine on the network doesn't grant access to your core data. The downside: Only data that fits into databases can be protected, and then you must be careful about which columns are encrypted. Primary keys and columns frequently used in joins should not be encrypted if you can avoid it.

These systems have matured to the point that they don't require changes to your applications. Products available create a view of the table that includes calls to decryption-stored procedures as part of accessing the view. The view is given the name of the original table, and the new table with encrypted info is given a different name. Transparency to applications was a necessary step that we're glad to see these vendors have implemented.

Overall, we found database encryption slower than file-level encryption; this surprised us, so we looked into the details. All the database-encryption products we tested call stored procedures to decrypt with a key and an Initialization Vector. The problem is that stored procedures must be called over and over, slowing access by an average of two times. File- or block-level encryption doesn't need to make all of these extraneous calls; these systems get the key and IV once, then use them to decrypt the entire file or block in a single call. There are some limitations on input and output size, but we're still talking several calls to read a multigig file, as opposed to one call per row to read an encrypted database.

File- and block-level encryption tools posted overall better performance, returning an average 92 percent of encrypted data as compared with unencrypted in the same period in Fibre Channel, with similar numbers for iSCSI. That is the best-case average. Our NWC Monster Test, a customized IOMeter access specification that simulates actual usage with randomized reads and writes of varying sizes while background sequential reads are going on, shows less than 50 percent of the maximum throughput under Fibre Channel.

Remember that all the various encryption tools must decrypt data, too. You'll have to choose among products that do decryption on the host, using valuable CPU time; on the appliance, meaning it's decrypted on the network; or on the database server, using CPU time and impacting database performance to some extent. In all three cases, at some point, the data is in clear text. Nothing can be done about that unless you develop your applications to deal with only encrypted data, which is not feasible for any application that requires user interface elements. At least one product, from Kasten Chase, let us run secure IM, e-mail and file sharing using an appliance that distributes keys to validated users. This kept our data encrypted throughout the network to the client in question; decryption occurred on the client.

The storage-security market has come a long way, but we hope vendors will continue to innovate. For example, all the LUN-level encryption products we looked at require familiarity with storage-specific terminology, like WWN (World Wide Name) and FCID (Fibre Channel ID). This may not seem like a huge deal, but security staffers can't be knowledgeable in every area they're assigned to protect. Most switches let storage admins give simple names to each port, and we'd like to see these products take advantage of this.

Another problem is in the way switches interoperate with storage-network appliances. Most switch vendors require you to turn off some amount of functionality to support interoperability. Storage-encryption devices--specifically LUN encryption devices--generally appear on the storage network as switches. This is so they can route requests through themselves to handle decryption. The problem: When you configure your SAN switch to handle this new third-party "switch," you will lose core functionality that the SAN switch vendor has built in, even if the rest of your SAN is single-vendor.

This is not a weakness of storage-security vendors, but of SAN-switch vendors: It's way past time for SAN switches to offer full functionality in heterogeneous environments. Imagine losing functionality on your Ethernet switch when another vendor's switch is introduced into the network--you'd be shopping for a new vendor quickly.

On the plus side, we're pleased with the level of access control that SAN switches now provide. For example, some vendors support RADIUS servers for authentication and access control; this lets admins tightly regulate who can make changes to the storage infrastructure, while RADIUS server logging provides an audit trail of what changes were made and by whom.

Categorically Speaking

We divided storage-security products into three categories: file and disk encryption, database encryption and storage switches. Write-ups are alphabetical by category; though Cisco's MDS 9216i storage switch also performs file and disk encryption, we listed it under the storage-switch heading.

Decru DataFort FC525 storage-security appliance 2.0; Decru Client Security Module; Lifetime Key Management system

Decru's DataFort appliance encrypted data stored on our disks and limited access to them. It attaches to a Fibre Channel switch, through an inline or a sidearm configuration. It encrypts data traveling to the Fibre Channel network and decrypts data traveling from the Fibre Channel network to the server.

DataFort is the only appliance that queried our FC switch to gather configuration information. Although we commend the company for making the effort, info was still presented as WWNs, something security administrators should not have to deal with.

This product is an attractive choice for admins who can't, or don't wish to, touch each server that sits on the network. We achieved encryption of our at-rest data without any mandatory changes to our servers.

For hands-on types, Decru also sent us an add-on software tool, the Decru Client Security Module, that requires installation on each server (or client, for that matter) you wish to control. This application limits which programs can read which directories. We could even disallow applications from running at all and use Decru's security features and group administration to limit the applications available on any given host. Considering that applications like SQL*Net and Microsoft Management Console are threats to your databases, this is a darn good idea. Client Security Module supports only Windows at this time, with Linux in development.

Decru supports clustering DataForts for those environments where one box cannot handle the load. With our small test environment, we didn't overload our appliance, but we're looking forward to running a competitive review where we can try to do just that!

Two problems to be aware of: DataFort created several Fibre Channel zones that were used to funnel all traffic through the appliance. This could conflict with existing zone configurations and is confusing when reconfiguring a switch. The other concern is that all data is passed through the device twice--once to receive it and encrypt it, once to send it on to its destination. Although the product uses two ports for this function, it could create a bottleneck. Decru suggested that we configure our system to hold a single box inline on each port, but the cost of this solution, particularly in a large SAN, could be prohibitive.

Decru DataFort FC525 storage security appliance 2.0; Decru Client Security Module, $43,700. Decru, (888) 22DECRU, (650) 413-6700. www.decru.com

Kasten Chase Assurency SecureData

Kasten Chase's SecureData appliance plugs into an Ethernet network and uses a set of cryptographic accelerator cards to decrypt data and retrieve keys from the appliance. These cards must be installed on each host that requires access to secured data, a negative compared with rival systems that do not require contact with each individual server. However, unlike all the other hardware we tested, this configuration gave us full data security from the Fibre Channel or IP connection leaving our servers to the storage device being addressed.

Once data has reached the requesting server (when applications receive the data from the FC or IP driver, to be exact), it is no longer encrypted. That does mean that applications are still a risk, but it also means that sniffing the IP network or spoofing the WWN will gain an attacker only a stream of encrypted matter. The other positive of Kasten Chase's approach is that the encryption/decryption occurs on the host in a dedicated card. That relieves one possible bottleneck, the encryption device, but limits OS support to Solaris, Windows and Linux, with AIX in development.

To perform encryption and delve into the device's functionality, we used Kasten Chase's Server Encryption Driver, which let us encrypt, rekey and "zeroize" disks (wipe all data information from them) through a Windows UI. Kasten Chase's interface let us select the LUNs to be encrypted, then set them encrypting in the background while users continued working normally; the same held true for rekeying the data (re-encrypting the data with a new key)--we were able to work with the data, albeit with some slowdowns, while it was being encrypted.

Kasten Chase also demonstrated for us its Assurency CipherShare, which provides an encrypted groupware environment that includes IM, e-mail and file sharing and uses the SecureData Appliance to manage keys and certificates. Although we didn't delve into its depths, we did see CipherShare running in production on a wireless laptop over the Internet, and performance appeared good.

Assurency SecureData appliance, $27,950; Assurency ACA-800 CryptoAccelerator, $2,450; Assurency Server Encryption Driver, 1,950. Kasten Chase, (800) 263-1448, (905) 238-6900. www.kastenchase.com

NeoScale Systems CryptoStor FC 2002

The NeoScale system offers several architectures from which to choose, including inline between switch and storage, inline between host and storage, and attached to the fabric. We chose to attach to the fabric, mostly because of the costs that would be associated with protecting each array or host with its own box. We did the same with Decru.

CryptoStor FC does block-level encryption from disk to the device, wherever the device is in your SAN. NeoScale also offers a backup-tape encryption device and a SAN VPN device that we did not evaluate.

The CryptoStor is a more complex system than rivals that we tested, and some of that complexity could be eliminated. For example, as with Decru, security types will need to handle FCIDs or WWNs. This is even more painful with CryptoStor because the device does not query the switch to see what's available; we had to know the FCIDs or WWNs we were working with and enter the numbers by hand. Ouch.

Generally, with added complexity you gain power, but this wasn't the case with CryptoStor. As with Decru, denser configuration possibilities are not generally feasible in large SAN environments because of the per-port expense, yet flexible configuration is a key NeoScale selling point. We were impressed with the CryptoStor's allow/deny and time-scheduling capabilities, which may be its saving graces. Although other vendors offer time scheduling, they tend to focus on allow times only. This can do the job, but security folks are used to having whitelist/blacklist capabilities with allow/deny times. In this instance, the CryptoStor uses terminology familiar to the security officer.

Finally, CryptoStor required that we make a host available to do encryption for the appliance. We found this solution, common in database encryption products, unwieldy when encrypting large SAN volumes because it tied up a machine for long periods of time. As with many configuration issues, keep in mind that you will do this only a few times over the life of the product, ideally only once per LUN, so this is not a major negative.

If your storage-management staff is handling your storage security, it'll be very comfortable working with the CryptoStor FC. But if you keep a separate security staff around, it'll need the help of a storage-networking professional to administer this device.

CryptoStor FC 2002, starts at $35,000; CryptoStor SAN VPN, starts at $40,000; CryptoStor Tape, starts at $17,000. NeoScale Systems, (408) 473-1300. www.neoscale.com

Ingrian i221 DataSecure Platform 3.1

The Ingrian i221 is a database-encryption appliance. Intuitively, we expected encryption to be slower on the appliance than on the database server because the appliance requires round-trips to do encryption/decryption, but our testing showed that time lost with database encryption occurs in calling stored procedures over and over to decrypt each row in the output. The i221's performance in our testing was pretty close to that of Protegrity's encryption software.

The i221 is very easy to use, but the newness of the 4.0-series software caused us some problems. Ingrian is still working out bugs in its method for getting the software and licenses distributed, but this is a minor and temporary issue.

We did see some oddities with the i221. For instance, running a query with one tool would return errors, while the same user running the same query with another tool would get back data. In all cases, we were able to find a way to get at the data, but it did take us time. Knowing that these problems exist should set you down the path of searching for alternate command lines--or an alternate product.

The i221's database-support add-ons, tools used to interface with the database, are a little bulky and lack documentation. This is more of a problem with Oracle, where explicit knowledge of Java JCE is useful to get things configured correctly.

Overall, if column-level database encryption is what you're looking for, the i221 will probably suit your needs. We liked its clustering features--the only issue we had with them is that there wasn't 100 percent replication between the boxes in the cluster. Fortunately, this data is only certificates and keys, and DataSecure let us manually copy between the members of the cluster, so this turned out to be just an inconvenience.

Ingrian i221 DataSecure Platform 3.1, starts at $32,500. Ingrian Networks, (866) 464-7426, (650) 261-2400. www.ingrian.com

Protegrity Secure.Data

Secure.Data is the sole software-only product in this review; while data at rest is protected, data leaving the database is, by necessity, unencrypted. Secure.Data performs database encryption utilizing a Windows service Protegrity has developed and is less expensive than appliances, at $15,000 to $25,000.

Secure.Data offers a sound approach to encrypting sensitive data, with plug-ins for Oracle and SQL Server. Encryption/decryption occurs in stored procedures, and key management and key access occur in services on the database server. The one point that gave us pause is that the keys are stored on the same physical machine as the data, which Protegrity says is acceptable if the keys are encrypted also. Alternately, Protegrity offers a configuration with a network-attached HSM (Hierarchical Storage Management), but we did not test this setup.

Overall, we found that Secure.Data performs in line with hardware acceleration, the weakness being that the CPU time used by the system is 100 percent taken from your database server's CPU time. Under heavy load, it could bog down your server, requiring a more rapid deployment of database servers than you had originally planned. This can be expensive--depending on your chosen database, it might be as expensive as choosing a database-encryption appliance.

In addition, we're not big fans of software implemented as Windows services. Troubleshooting can be a nightmare if something goes wrong, and trusting critical data to something that might take many hours to debug isn't our idea of a best practice. On the other hand, Secure.Data's centralized management system did push keys out to all the database servers in our cluster, propagating access and keys to new databases quickly and easily. If you want your security to apply to particular columns, and you want access control and access logging, but you need a product that can scale with the number of databases you implement, then Protegrity Secure.Data might be the right choice for you.

Secure.Data, starts at $15,000. Protegrity Corp., (203) 326-7200. www.protegrity.com

Brocade SilkWorm 3850 and 3900 with Secure Fabric OS

Silkworm switches are FC-only products on which Brocade has implemented Secure Fabric OSs. They offer built-in support for zoning and port blocking, as well as a form of access control. The ability to restrict ports to devices is also included in Brocade Fabric Manager. The most appealing thing about Brocade's SilkWorm is its Policy Control Center, which placed all policy-relevant items for our entire fabric in a single user interface. Although we still had to know storage-specific information to configure security in the switches, administrators will not have to hunt for the location where a user must be added to get access to telnet or the Web interface.

As might be expected, we found much of the functionality supported by McData and Cisco in the SilkWorm switch, with the notable exception of Cisco's encryption functionality. We found zoning less user-friendly than in rivals, but as you'll likely create zones only once, that's not a deal breaker. The SilkWorm's overall security was more intuitive than Cisco's or McData's. We viewed, configured and modified nearly all security functionality from the Policy Control Center, and the ability to see what IP address or WWN has access to which interface or port on the switch is simplified nearly to the level we were looking for in other products.

Brocade lags behind the other switch vendors in role-based access control--we couldn't define users and groups as readily as with competitors. Balancing this against the Policy Control Center, however, Brocade is a worthy competitor for your security dollars. The one catch with this and all switches is that you're unlikely to replace an existing SAN switch infrastructure to implement security, but if you're looking at building a new SAN, Brocade is worth considering.

Brocade sells only through OEMs. Hewlett-Packard quoted $49,893 for the Brocade SilkWorm 3900 32-Port FC Switch, $7,500 for Secure Fabric OS and $17,500 for Brocade Fabric Manager. Brocade Communications Systems, (888) 283-4273, (408) 333-8000. www.brocade.com

Cisco Systems 9216i Storage Switch with SAN OS-2

The 9216i is a Fibre Channel switch with iSCSI and FC-IP capabilities. Through Ethernet ports, Cisco allows access to data stored on the SAN utilizing iSCSI (for server connections) and FC-IP (for remote SAN connections).

Cisco's 9216i includes a ton of storage-security functionality--we were impressed with the breadth it brought to the table. We liked the VSAN (virtual SAN) capability, which offers increased security over basic zoning, and authentication and access control through a RADIUS server. Encryption of iSCSI and FC-IP was built-in and operated as advertised.

Encryption of FC protects data on the back end of the SAN, but not from the switch to the client. Encryption of iSCSI data stored on the SAN is handled from disk to client. We ran into some problems when FC-IP encryption was turned on and all traffic was routed through the FC-IP switch interlink, dropping performance of our 2-Gbps SAN to a mere 82 MB per second (656 Mbps), but we resolved them by wiping the switches and starting over.

The main thing that Cisco needs to work on is reducing complexity. Creation of VSANs and zoning are typically jobs for storage administrators, while RBAC, RBM, encryption and management of encryption keys are the purview of security admins, as is auditing of logs. We'd like to see the market, led by large companies like Cisco, move to a world where the security administrator is working in a separate UI that does not involve LUNS, WWNs or FCIDs. At a minimum, an easy-to-use auditing facility for all security functionality should be in place. This is an achievable goal--most switches already let you assign English names to ports and WWNs. Cisco certainly wasn't the worst of the crowd, but they all have a way to go.

Cisco MDS 9216i with SAN-OS 2, starts at $40,000. Cisco Systems, (800) 326-1941, (408) 526-4000. www.cisco.com

McData Intrepid 6064 and Spherion 4500 with SANtegrity Security Suite I and II

McData sent us a set of FC Switches--one director-class and one workgroup-size--that use SANtegrity Security Suite software to implement security.

With the exception of encryption, which it does not support directly, McData has stayed neck and neck with Cisco. Authorization and access control through RADIUS or on-switch, zoning and administrative logging are all built in to the McData platform.

McData's SANavigator software provided a useful UI that let us configure just about everything. We could even set up fabric binding--locking new switches out of the fabric. McData also has implemented port and switch binding, whereby we could lock a port down to a specific WWN. This is two-way binding (a one-to-one mapping), and we found it particularly helpful in stopping WWN spoofing attacks--the attacker would have to disconnect the original and plug his or her spoofed WWN machine into the exact port to mount a successful spoofing attack.

Like most vendors that implement access controls, McData uses a role-based approach and can look to a RADIUS server for access rights. Overall, if you do not need encryption, or are willing to get your encryption from a third party, the SANavigator and SANtegrity user interfaces should be enough to make you consider McData for your secure FC SAN infrastructure.

SANtegrity Security Suite software; SANavigator Security Center management tool reviewed with Intrepid 6064 with E/OS 7.0, approximately $57,060 as tested. McData Corp., (800) 545-5773, (303) 558-8000. www.mcdata.com

Don MacVittie is a technology editor at Network Computing. He previously worked at WPS Resources as an application engineer. Write to him at [email protected].

Our test bed included all the elements of a SAN plus all the elements of database systems; we built our SAN using the following equipment:

• Five quad-processor Intel PCs with 3 GB of memory, two Gigabit Ethernet connections and a single 2-Gbps Fibre Channel connection running Windows Server 2000 SP3. Our 2-Gbps Fibre Channel connections are LSI Logic LSI7102XP-1 2-Gbps FC cards.

• One 2-GB array configured as four RAID-5 135 GB LUNs

• An EqualLogic PS100E iSCSI storage array configured as two 10-GB RAID 5 LUNs and two 100-GB RAID 5 LUNS. The remainder of the available space was placed into a single large volume and not used for this test.

Different vendors preferred different SAN switches, and we accommodated them as much as possible. Through the course of this test, we used three Fibre Channel switches--a Brocade SilkWorm 3850, an Emulex InSpeed 350 and a McData Spherion 4500--all running at 2 Gbps.

For iSCSI hosts, we used Microsoft's iSCSI initiator in all testing. Although it's possible that better performance would come from an iSCSI HBA (Host Bus Adapter) or a TOE (TCP-IP Offload Engine) card, we needed a solution that was available on as many as 15 clients, and we didn't have 15 of any single-model card available in the lab. However, most iSCSI implementations use the free software initiator.

We used IOMeter for performance testing, but because of the wide breadth of products and architectures in this review, we limited published performance results to generalities about product types and impact of categories.

All Network Computing product reviews are conducted by current or former IT professionals in our Real-World Labs® or partner labs, according to our own test criteria. Vendor involvement is limited to assistance in configuration and troubleshooting. Network Computing schedules reviews based solely on our editorial judgment of reader needs, and we conduct tests and publish results without vendor influence.