SANs more menaced from within than without: security is a people thing.

The current turmoil about data security pervades public entities, private enterprises, and the SMB world alike. On the enterprise level, one of the questions that jumps up regularly is whether the storage area network (SAN) is as secure as legal regulation or corporate policy could demand. The answer is "probably." But security issues are multi-layered, and need to be looked at as a composite. Many new storage security products have emerged from startup and veteran vendor alike. What is wanting is a cool, dispassionate look at the entire LAN/WAN topology, because focusing attention on the SAN might put the accent on the wrong acronym. The SAN itself looks less vulnerable than the server and host side of a gateway.

Are FC SANs Secure?

The bulk of the SANs in the enterprise marketplace are based on Fibre Channel (FC) technology. It arrived to market before IP alternatives were considered, so the vulnerability of FC SANs should be examined.

Although FC is becoming more and more familiar to enterprise storage and network administrators, it is still relatively unknown as compared to IP. Kamy Kavianian at Brocade notes: "Fibre Channel is more of a closed network, hiding behind firewalls, VPNs, and so forth."

Not only is FC a more arcane protocol, then, but also it is sensitive to disruption. If a hacker tried a session hijack on an FC channel, the certain result would be to crash the link. As the link is rehabilitated from the crash, authentication routines would ramp.

A number of authentication strategies are moving through the standards boards to address security issues under Fibre Channel. Kavianian enumerates three authentication protocols that have been accepted for inclusion in FC-SP:

DH-CHAP: Diffie-Hellman Challenge Handshake Authentication Protocol

FCAP: Fibre Channel Authentication Protocol

FCPAP: Fibre Channel Password Authentication Protocol 

DH-CHAP

CHAP was chosen by IETF as the mandatory authentication protocol for iSCSI. It is based on shared secrets. DH-CHAP is a variation of CHAP that adds a Diffie-Hellman exchange to both strengthen CHAP and provide an agreed-upon secret key. DH-CHAP was presented as a simple protocol that would be easy to implement.

DH-CHAP is the simplest of the authentication protocols. The protocol requires that both of the entities involved need to know, or at least have access to, the shared secrets required for mutual authentication. This presents both a potential security concern and an administration concern. There is a security concern when the secrets needed reside in the entities themselves. Unlike verifying passwords against a hashed password database, shared secrets need to be available in the clear in order to verify the response to a challenge. The management of the shared secrets necessary for the protocol requires that there be infrastructure support for managing those secrets. A RADIUS server will most likely be desirable for managing shared secrets for all but the smallest fabrics. The RADIUS server can also participate in the protocol by verifying a response to a challenge. All shared secrets could reside in the RADIUS server. Each entity need only remember its own secret. If a RADIUS server is not included, then all entities need to maintain the secrets of all other entities with which they need to mutually authenticate. The time that it takes to go to a RADIUS server for authentication offload processing can be long and unpredictable. For Nx_Port-to-switch connections this time delay can be tolerated; switch-to-switch connections will be more problematic. (A similar switch-to-switch concern applies to certificate revocation checking in an FCAP environment.)

DH-CHAP with a null Diffie-Hellman exchange is the mandatory protocol on which to base interoperability.

FCAP

The Switch Link Authentication Protocol (SLAP) was proposed by Brocade in April 2001. This protocol is based on Public Key technology using certificates. It was the first authentication protocol proposed for FC. Over time, the protocol was generalized and renamed FCAP, the Fibre Channel Authentication Protocol.

FCAP provides enterprise-class security based on Public Key Infrastructure (PKI). Since PKI provides a high level of security, it is prevalent in the more security-conscious customer environments. PKI as the foundation and a certificate-based protocol provide numerous advantages, particularly in providing for strong authentication and management data integrity. The major argument against FCAP has been focused around the perceived complexities associated with PKI. The major challenge with promoting FCAP has been showing that the environment does not have to be overwhelming, but can be made straightforward. The certification process (certificate signing requests [CSRs] and certificate loading), the certificate revocation process (certificate revocation lists [CRLs] and online certificate status protocol [OCSP]), and certificate validation (issuing CA certificate(s), certificate chains, cross certification) all need to be appropriately included in the security services being defined.

FCAP is an optional authentication protocol but it is considered much stronger than the password-based mechanism used in CHAP.

FCPAP

FCPAP, based on passwords, was proposed as an alternative to FCAP. It is based on another protocol called SRP, Secure Remote Password.

FCPAP was proposed primarily to provide a protocol that does not require a PKI. Though FCPAP does not require PKI, there are complexities associated with managing the passwords and related credential material required to support the protocol. Work needs to be done to reduce these administration complexities to make this environment a viable alternative. Password administration for FCPAP is not as easily integrated into an enterprise environment. For example, a RADIUS server does not directly support management of the credentials required by FCPAP nor directly support offload of the SRP-based authentication.

All three of the authentication protocols are required to be able to perform mutual authentication with optional key agreement. The optional key agreement is done using Diffie-Hellman key agreement exchanges. Key agreements can be used to support message authentication of data transfers, CT Authentication, and SA setup.

Kavianian and others at Brocade also caution that where encryption is advisable, the use of hardware appliances from such companies as Neoscale, Decru or Vormetric is recommended. This is opposed to software-specific solutions.

Why Appliances?

Duc Pham, CTO at Vormetric, points out the specific advantages of an appliance approach. One of the primary reasons cited is that the security infrastructure is not host-based. In most cases, attacks against a SAN are likely to be staged from a host location, perhaps as a Trojan horse or other piggyback strategy. Vormetric's Phil Grasso notes that, depending on the threat model, an appliance is relatively faster than host-based software.

The essence of the Vormetric plan is to place the access at the file system layer, the highest point in the stack before breaking into the applications layers. The system is indifferent to the storage architecture, and the latency penalty is very small. Pham observes that encryption in the SAN only has value in protection from physical theft of media and gives no protection to on-line information.

Before leaving the FC SAN discussion, the issue of password etiquette should be examined. If FC SANs are resistant to attack from the outside, then the danger of unauthorized or malicious intrusion comes from within the data center. And there are entry points.

Changing passwords needs to become a discipline. When a SAN is installed, there is an even chance that the administrator's starting password is "password." Now if someone on the inside gets past the firewall and discovers a switch: they might try the word "password" first, then the name of the OEM second (probabilities give a better than average opportunity to the unauthorized user). The OEMs are often considered at fault in such a situation, where the burden of adequate precaution actually resides in the storage or network administrator.

Is it a preventable security breach? Yes. What is the risk? Contaminating the zones results in a loss of availability, but administrators do that all of the time by accident. Will data be lost? Potentially for data in transit; but if a database is involved, the engine promises to be able to back-out or complete an uncommitted transaction. While the likelihood of data loss is not great, the risk of lost access impacts data availability significantly.

Familiarity Breeds Vulnerability

A growing number of next generation SAN architectures may well be based in an iSCSI fabric. ISCSI transmits native SCSI over a layer of the IP stack. It permits a corporate network to transfer and store SCSI commands and data at any location with access to the WAN or, if transmitted over the Internet, to locations with access to the Internet. It will also allow smaller, localized SANs to be built using the common Ethernet infrastructure. Hence, iSCSI enables SANs to be implemented by a broad mainstream market.

There is a fear in the marketplace that IP is especially vulnerable. As mentioned earlier, Fibre Channel is a comparatively lesser-known technology. Sad to say, well-known things tend to be hacked. The target list often becomes Microsoft, Linux and then vendor-specific Unix flavors. News reports on the so-called MyDoom virus suggested that SCO computer systems might have been the intended target.

IP is part of the target list as well, since Ethernet is a commonly known and commonly understood architecture. Therefore, their security is of concern.

In a session hijacking situation. Paul Siefert at SANRAD notes that Internet security is based on a virtual private network implementation using the IPSec security tool. It is difficult but not impossible to breach this security; the bulk of security breaches are internal in origin. The VPN is basic: a couple of gateways, one interface. Good success has been seen historically using IPSec.

www.brocade.com

www.sanrad.com

www.vormetric.com