This article can also be found in the Premium Editorial Download "Information Security magazine: Balancing act: Security resource planning helps manage IT risk."
Download it now to read this article plus other related content.
Terabytes of sensitive data distributed among efficient but vulnerable storage area networks (SANs) have swept away the notion of storage as a closed, secure system.
"As people do disaster recovery, as they connect multiple sites to move data from primary to secondary sites, that's when a lot of security issues have to be thought about," says Jamie Gruener, an analyst for The Yankee Group.
At risk is your organization's most mission-critical data: intellectual property, CRM information, credit card numbers, patient records and so on.
SANs are high-performance, dedicated storage networks, centralizing management of vast and distributed storage arrays--but they are not secure. That means you've got to be concerned, especially if your previously unconnected SAN islands are linked across the WAN to maximize storage capacity or extend DR/BC capability.
Our examination of SAN architecture reveals security weakness throughout, from the app server to the storage array. That's the bad news. The good news is that the new storage security paradigm addresses these weaknesses in three ways:
- Emerging standards are addressing SAN security deficiencies.
- SAN vendors are finally adding muscle to the technology's inadequate security, introducing features such as strong authentication and encrypted management information.
- A handful of security startups have rolled out dedicated high-speed storage encryption solutions. However, it remains to be seen if these technologies are ready for prime time.
Open to Attack
SANs are typically configured in a fabric topology in which devices--app servers, RAIDs--plug into a switch. SAN's security problems come down, basically, to weak authentication between devices and inattention to management security.
Poorly protected SANs are open to attacks, primarily through compromised management systems or app servers. An attacker can stage a man-in-the-middle attack by compromising a server and attacking the SAN through its interface or the host bus adapter (HBA); or by hijacking management communications using a sniffing tool, such as dsniff.
In addition, storage over IP opens storage networks to the same risks that threaten the rest of your IP-based enterprise (see "IP Changes the Rules").
SAN switch vendors, such as Brocade, McData and QLogic, implement zoning and Logical Unit Number (LUN) masking to control data access. These features are designed as much for administration as protection. But they're still an important part of your overall security architecture, allowing you to logically segregate your SAN. You can apply more robust security tools to protect each segment and enforce that segregation. Vendors tend to promote these when they trumpet their overall security capabilities, but it's really basic stuff:
Zoning. The Fibre Channel (FC) standard governing SAN products is wide open by default. Application servers are potentially aware of all SAN devices, with unrestricted access to any disk. Zoning is a switch function that addresses this problem by creating a logical, closed path from host server to storage array.
There are two types of zoning: Hard zoning and software zoning. Hard zoning works in one of two ways: by linking physical ports in the fabric (port zoning), or by using the 64-bit World Wide Name (WWN) that identifies each SAN device. Of the two hard zoning techniques, port zoning is easier but less flexible. On the other hand, WWN can be spoofed, allowing a rogue device onto the network.
Software zoning uses the switch's name server database, which stores WWNs and port numbers. It's a flexible zoning method, but there's a risk that certain operating systems will allow the host to connect directly to the storage device without consulting the database.
Devices can be restricted to single zones or shared zones. For example, a server may be in one zone with a RAID and share a second zone with a tape library.
LUN masking. LUN masking is a RAID-based feature that binds the WWN of the HBA on the host server to a specific SCSI identifier, or LUN.
Since zoning can't mask individual LUNs behind a port, it can't limit an app server to a specific partition on a RAID. LUN masking overcomes this restriction. Let's say a single 18 GB RAID is divided into three 6 GB partitions to store data for the HR, engineering and marketing departments. LUN masking, for example, could "hide" the HR and marketing partitions, so that an app server can only see the engineering department partition.
The problem with all this is that there's no requirement for authentication. A zone isn't considered secure unless each device is strongly authenticated. Otherwise, rogue servers can easily spoof a WWN.
Although storage vendors are planning to support a wide range of authentication methods, the Diffie-Hellman Key Encryption Protocol-Challenge Handshake Authentication Protocol (DH-CHAP) is the method of choice for the proposed Fibre Channel Security Protocol (FC-SP), which addresses FC's weak security.
CHAP is widely accepted because it works with RADIUS authentication servers. Further, CHAP is mandated for gateways implementing the new iSCSI protocol for IP storage, which means that storage network users can deploy one authentication technique from end to end.
While DH-CHAP is mandated to provide interoperability, FC-SP includes two optional authentication protocols: FCAP (Fibre Channel Authentication Protocol) and FCPAP (Fibre Channel Password Authentication and Key Exchange Protocol). FCAP uses digital certificates, and FCPAP uses SRP (Secure Remote Password) as underlying technologies.
Shoring Up the Weak Points
A look at the relationships between SAN subsystems helps put security issues and solutions into focus:
Host-to-fabric. The threat here is that an intruder can spoof the WWN of an HBA and attach to the fabric via any open switch port. SAN solutions enable admins to bind an HBA to one or more switch ports by using access control lists (ACLs). ACLs define and control which HBAs can access which switches. Different vendors may use their own terminology, but it's the same fundamental capability.
Management-to-fabric. SAN management is generally considered the most vulnerable and dangerous point of compromise. As mentioned earlier, an attacker can hijack a management session and run amok through your storage network, modifying configurations and accessing restricted data.
SAN vendors have been notoriously lax in this area. Management sessions lack basic SSL/SSH protection, making them sitting ducks for intruders. Lacking strong authentication, management access ports are wide open to entities outside the storage network, and admin passwords are often transmitted in plaintext. In addition, SAN vendors and SAN management software vendors have long supported early versions of SNMP, which lack basic security features, such as authentication and integrity, instead of the stronger security available in SNMPv3.
Vendors are promising support for SSL, SSH and SNMPv3 in upcoming releases, but they're not there yet.
Encryption mechanisms such as hashing can be implemented for secure authentication. McData, for example, has added MD5 hashing for management console password security to its SANtegrity Suite.
Brocade provides password encryption with its Secure Fabric OS, an add-on software security solution. Management passwords and other critical data elements are encrypted with a switch's public key, then decrypted with its private key. Brocade also employs management access controls to restrict access by vulnerable management services, such as SNMP and Telnet.
Data security vendor Kasten Chase's Assurancy Secure Networked Storage takes a different approach. Its Assurancy Appliance includes a certificate authority and key management service to authenticate SAN devices, through agent software.
However, PKI may be more than most organizations are willing to accept. The cost and complexity of implementation has limited it largely to government agencies and other highly security-sensitive organizations. There's also the question of interoperability in multivendor environments--ensuring that each implementation will accept the other's digital certificates.
Fabric-to-fabric. Unauthenticated or misconfigured switches can exacerbate a breach of the fabric. ACLs provide basic security, controlling whether a new switch can join the fabric by determining if routed packets are forwarded or blocked. PKI, as implemented by Brocade, can be used to authenticate the identity of a new switch in combination with ACLs. Switches exchange digital certificates for mutual authentication, assuring that only authorized switches can join the fabric or a specific zone.
Configuration dissemination and integrity is another area to consider. SAN management software should include a security database that assures that new switches automatically inherit security policies, reducing the chance of configuration error. Integrity-checking assures that configuration changes come from only an authorized and authenticated manager, are propagated correctly and remain unchanged. Integrity-checking software, such as Tripwire, and distributed lock managers can help here.
Even the most robust SAN security doesn't directly address the data itself. A successful hacker or a curious or malicious admin may gain access to your most sensitive data, sitting in plaintext. As a result, your organization may be considering encrypting all or some of its stored data, because of regulatory requirements or enhanced security policy.
Your options range from encrypting everything to simply encrypting selected backup tapes before they're shipped for off-site storage.
While SAN vendors bolster their security, several companies are betting there's a market for storage encryption. Startups Decru, NeoScale Systems and Vormetric have recently introduced heavy-duty security appliances to encrypt data between the app server and the RAID.
A word of caution. These products are new and have little or no track record in the real world. Evaluate and test them carefully before you buy.
Alternatively, you can deploy embedded crypto accelerator cards, such as those used in Kasten Chase's Assurancy Secure Networked Storage. Kasten Chase uses PKI to provide TripleDES or AES encryption.
Your choice of card or appliance may depend on your environment and your preference. (see Figure 2). A card is a lot cheaper than an appliance. On the other hand, you just might prefer not to add anything to a critical app server if you don't have to.
Storage encryption hardware solutions all support TripleDES and/or AES, and feature beefed-up processing power to meet the demands of storage network traffic:
- NeoScale's Crypto-Stor, with both SAN and tape backup appliances, includes a storage firewall to block unauthorized storage access and supports SSL and SSH for management security. It features true random number key generation, FIPS 140-2 Level 3 hardware security for key management, smart card authenticated access and auto key escrow.
- These last points are important. Key management for perhaps millions of files stored for years in multiple locations is tricky business. Vormetric and Decru have similar key management capabilities.
- Decru's DataFort appliances authenticate all SAN devices through exchange of digital certificates with deployed software agents. Decru offers separate appliances for Network Attached Storage (NAS) and SAN.
- One of Decru's first customers is SwapDrive, a Washington, D.C.-based provider of Web-based online backup and storage. Storage service providers will likely adopt these types of encryption technologies to raise customers' comfort levels, especially when their competitors may be sharing space on the same RAID.
- Vormetric--formerly Sotera Networks--released its CoreGuard Core Security System appliance in April. It features a firewall to enforce access policy through host agents and uses TripleDES to encrypt data to any media.
- Ingrian Networks' Network Attached Encryption , incorporated in its i225 appliance, secures data generated by any JCE-compliant Java enterprise application server--such as BEA Weblogic, Oracle Application Server, IBM WebSphere, Apache Tomcat or Sun ONE Application Server--through software agents. The appliance generates an SSL connection to the backend servers and encrypts data with TripleDES.
- Digital Security International's Paranoia2 is a high-speed appliance providing DES and TripleDES encryption for SCSI tape backups.
The Big Picture
Storage network security doesn't exist in isolation, because storage isn't insulated from the rest of your enterprise. Consider how policies and technologies for storage authentication, access control and encryption fit in with your existing security policy and solutions.
The first line of defense for your storage network is your overall enterprise security posture. Although vendors and security experts are correct when they say perimeter defenses are insufficient protection for storage networks, they're key to defense-in-depth.
Consider creating a secure zone around your storage network. Internal firewalls or routers with filters and intelligent use of ACLs can buttress the SAN against intrusion. Harden all servers that interface with your SANs.
Finally, weigh the business risks against the costs. For example, encrypting all your data isn't cost effective if your business or regulatory requirements dictate that only a portion needs protection. Or, you may decide to keep your data in plaintext and put all your security efforts in the front end of the storage network. If you're considering storage over IP, weigh the costs of integration with your existing IP security technologies. Infosecurity budgets are tight, and you've got to sell management on the need for security where none previously existed. Choose the targets and the technologies that make sense.
Vijay Ahuja is founder and president of Cipher Solutions, a provider of storage and network security.
This was first published in July 2003