Addressing SAN security issues

Security breaches pose a threat to storage area network data, but there are a number of steps that IT managers can take to ward off potential problems.

By Richard Lary

Most managers assume their current storage area network (SAN) implementations are secure. The truth: They are safe enough for today's limited implementations, but as SANs become more prevalent, broader security measures will be necessary.

Click here to enlarge image

Today, organizations are turning to SANs for the scalability, flexibility, and reduced management costs they promise to deliver. SANs allow organizations to collect large amounts of data on a storage-specific network where it can be efficiently accessed and managed. While most SAN implementations today are simple pilot projects or relatively small and homogeneous networks intended to address a single storage problem, ultimately they will allow organizations to treat storage as an enterprise service, a utility that delivers capacity and performance as needed throughout the organization.

As its name implies, a SAN is a network. As such, it raises many of the same security issues as any network. In this sense, SAN security issues are similar to those of an NFS network. In the case of the SAN, application servers access storage devices across a separate storage network. These servers are also attached to the corporate network.

In some ways, a SAN is more secure than other corporate networks, however. Desktops, for example, don't have direct access to the SAN, nor does the SAN connect to an external "Storage Internet"-at least not yet. However, hackers can still penetrate a SAN by compromising a server that has SAN access, or a rogue server administrator or technician can subvert security measures.

While there is nothing inherently flawed about SANs from a security standpoint, they do rely on the security of the attached application servers. If the security of one server is breached, the SAN cannot contain the problem. For today's small homogeneous SANs, this isn't a major concern, but as SANs grow larger and encompass valuable enterprise data resources among many servers, it will be a problem.

A SAN requires IT managers to change their views on security. Before SANs, storage was attached to each server and was as secure as that server. A server that handled valuable financial or strategic data, or sensitive medical or personal data, received more intense security treatment than servers handling less-valuable or sensitive data. Security was a concern, but the security decisions were applied and managed at the server. If the server was compromised, its associated data was compromised, but the security breach generally was contained to the specific server.

SANs, on the other hand, can support a variety of servers running different operating systems and an assortment of storage devices (e.g., RAID subsystems and tape libraries). A Fibre Channel SAN consists of the following:

  • A Fibre Channel communications infrastructure.
  • Storage server nodes (disk and tape subsystems) connected to the communications infrastructure.
  • Client system nodes, which connect to the communications infrastructure through host bus adapters.
  • Value-added services, such as storage pooling or offloaded backup, implemented in client software or in dedicated nodes ("SAN appliances") connected to the communications infrastructure.
  • A management infrastructure, with agents on some or all of the above components, which uses those agents to monitor and modify the operation of the SAN.

A Fibre Channel communications infrastructure consists of one or more parallel networks of Fibre Channel switches, known as fabrics. Each connection point on one of these switches is used to connect to other switches or to a single node, such as a client host adapter or storage server, or a ring of as many as 126 nodes interconnected via Fibre Channel Arbitrated Loop (FC-AL). To communicate, a node must log into the fabric. Here, it is assigned a name that is used to route its messages inside the SAN.

Through the fabric log-in procedure, the node is able to get the names of other nodes on the SAN, perform a port log-in to those nodes, and begin communicating. FCP, the protocol used by clients to access storage across a SAN, is a variant of the SCSI protocol that runs across a Fibre Channel network.

In a SAN environment, clients access what have traditionally been locally attached storage volumes across the Fibre Channel fabric. Sometimes these volumes are implemented as particular logical units on a particular storage server. If a value-added service for storage pooling is present, these volumes are actually virtual volumes that are dynamically allocated from a storage pool that spans multiple logical units on many different storage servers.

The ability of a SAN to connect many clients to a common pool of storage enables new data-processing operations, which exploit that connectivity. For instance, multiple clients organized as a cluster may share a set of storage volumes, or a client may create a snapshot of a storage volume and pass access authorization to that volume to a SAN appliance that performs backup. Or, a client may pass read access rights to a specific volume to another client as a way of transmitting a large amount of data to that client. In such cases, the SAN must implement and enforce the assignment of specific storage resources to specific clients and manage access rights and authorizations.

SAN security conundrum

If clients were always well behaved, the process of assigning specific storage resources to clients and managing access and authorization would be straightforward. However, client operating systems have various levels of inherent security and are managed by system managers of varying levels of security consciousness and integrity.

Herein lies the problem. If the SAN itself does not provide a security mechanism that cannot be bypassed by a compromised client, then the security of all data on the SAN is at risk. In effect, the security of the SAN would be no better than the security of the weakest and worst managed (in terms of security) client in the SAN.

Currently, SANs typically do not provide any rigorous internal security to compensate for a poorly secured client. To the contrary, they assume the systems attached to the SAN are secure and that the clients are what they purport.

At the hardware level, Fibre Channel is a bus based on trust. As such, it essentially provides no security against spoofing attacks-where a compromised client masquerades as another client to get access to unauthorized data. The Fibre Channel specification does not provide any standard mechanism for a storage server to restrict access of a particular logical unit to a particular client. As far as Fibre Channel and FCP standards are concerned, once a client logs onto the SAN, it can access any logical storage unit presented by any storage server.

Some storage subsystem, host bus adapter, switch, and software vendors have implemented SAN security measures outside the Fibre Channel standard. Examples include LUN masking (or mapping) and switch zoning. However, despite these measures, Fibre Channel and FCP allow several methods by which a determined and knowledgeable attacker can steal or destroy SAN data, given the ability to alter device driver code in a SAN client:

  • The attacker could, by providing false information during the login procedure, pose as another server on the SAN, thereby gaining access to that server's data.
  • The attacker could, by providing false information during the login procedure, pose as one of the storage servers on the SAN, thereby providing a means to penetrate other SAN clients.
  • The attacker could forge the source address in a Fibre Channel message to make that message appear to come from another server on the SAN.
  • The attacker could, under certain Fibre Channel fabric conditions, eavesdrop on messages being sent between other nodes on the SAN.

Because these attacks require sophisticated driver-level code, they are beyond the abilities of the average disgruntled employee or high-school hacker. That's good news, but it is not cause for complacency.

Consider the example of Back Orifice, a program that allows the Windows or Windows NT system on which it is installed to be monitored or controlled remotely without setting off any security alarms. The hackers who wrote Back Orifice did so to show off their skills; they did not (to anyone's knowledge) use it to compromise systems. They did, however, make the program available on the Internet to any unskilled but malicious person who might feel the need to use it.

SANs are not yet widespread enough to attract the creators of cracker-enabling tools like Back Orifice, but if SAN security vulnerabilities persist, expect to see some form of SAN Blaster tool in the near future.

SAN defense measures

The storage industry recognizes the SAN security problem and is working on the issue through organizations such as Storage Network Industry Association (SNIA). By the time most organizations are ready to deploy enterprise-wide SANs, improved security capabilities will be available. In the meantime, organizations can take a number of steps to secure their SANs and data.

  1. Recognize that SANs raise new security issues. While a SAN is not exposed like other systems, do not assume that it is a secure environment.
  2. Insist on a consistent level of security across all systems accessing the SAN. As noted above, today's SANs are only as secure as their weakest element.
  3. Make use of LUN masking features, which restrict access and visibility of logical volumes to a subset of the client systems on the SAN. While LUN masking is vulnerable to a determined attack at the device-driver level, it is effective against lesser attacks.
  4. Use partitioning to segregate more-sensitive data from less-sensitive data. For example, don't put confidential financial data on the same SAN with engineering data that is meant to be widely accessible. There are many ways to partition data (e.g., by department or region), but the confidentiality of the data should be one of the primary considerations..
    Alternatively, SAN managers can partition data into "hard" or "soft" zones. A security breach in one zone will not impact any non-overlapping zone. "Zoning" is not based on logins, but the management of the switches themselves. The zones are created on the basis of physical ports on the switch. Each zone becomes a virtual private network, which means nodes that are not in the same zone cannot communicate.
    "Soft zoning" is being proposed as a Fibre Channel standard, but an attacker who knows how to modify device-driver code can defeat it. "Hard zoning," on the other hand, is very secure, but it has drawbacks nonetheless. For example, it is not dynamic, which means you can't easily configure and reconfigure zones as business needs or operating procedures change. Today, organizations are turning to SANs in large part for the flexibility of dynamic access to a wide range of stored information and raw storage capacity. Zoning constrains that access.
  5. Secure the management paths and access paths. Attackers who compromises a server hosting a SAN management agent can bypass the LUN masking and/or zoning protections, giving them access to SAN data without making any device driver modifications.
  6. Enforce sound security discipline in hiring, promoting, and assigning responsibility.

Such security concerns shouldn't in-hibit IT managers from moving ahead with SAN implementations. The threats, although real and potentially devastating, do not pose a serious immediate risk given the limited number of SAN implementations today and the knowledge required to mount a successful attack. Looking ahead, however, solutions that address SAN security in conjunction with evolving SAN security standards will be required-the first of which will probably come out of SNIA.

Richard Lary is technical director, Storage Products Division, at Compaq Computer Corp. (www.compaq.com).

SAN security check list

  • Recognize that SANs raise new security concerns.
  • Insist on a consistent level of security across all systems accessing the SAN.
  • Make use of LUN masking, which restricts access and visibility of logical volumes to a subset of the client systems on the SAN.
  • Use partitioning to segregate more sensitive data from less sensitive data.
  • Secure the management paths as well as the access paths.

This article was originally published on March 01, 2000