Guidelines for ensuring storage security

Although a variety of storage security technologies are under development, the best advice is to focus on what you can do today.

By Tom Petrocelli

IT managers have always been concerned about the security of their systems. Originally, the focus was on physical security, limiting access to mainframes through swipe cards and providing audit trails though sign-in sheets. As systems became more open and connected—through networking and then internetworking—a new

series of vulnerabilities emerged, and system administrators were forced to find ways to combat them.

Storage was rarely a major security issue. System administrators had to be concerned with the physical security of removable media, but other than that, storage was trapped behind the servers and security measures were focused on other parts of the infrastructure, particularly the networks.

That changed with the advent of storage networking and storage area networks (SANs) in particular. With a SAN, a number of computers have direct, raw access to storage devices. Unfortunately, when SANs—especially Fibre Channel SANs—were first designed, little was done about security. The assumption, once again, was that by securing the servers you secured the storage, too. This was a comforting—but erroneous—thought. The ability to connect any computer with a Fibre Channel host bus adapter (HBA) into the pool of storage devices created vulnerabilities where none existed before. And the fact that a server could access many storage devices at once magnified the damage that a single attack could do.

Probably the most troubling aspect of storage system vulnerability is that many of the holes can be plugged with technology and techniques already in place. Yes, it would be much better if Fibre Channel SANs had secure protocols from the beginning, or even reasonable authentication mechanisms, all of which will come with time. In the meantime, it is important to use the tools currently available to create a more secure environment.

It is important to remember that the majority of security threats are not going to come from outside an organization but from within. A disgruntled employee can generally do more damage than an external hacker. Hackers also tend to target very large corporate and government networks. Internal threats attack any size organization and can deploy methods that an outsider would not be able to.

IP-networked storage presents a different set of challenges, but many of them are similar to other IP security issues. IPSec, authentication protocols such as Kerberos, and existing firewall products can all be deployed for IP SANs. Even then, the IP storage environment can be made more secure simply by following certain practices that take advantage of existing technology.

This article provides some tips on how to make your storage network more secure. Even if you have one small SAN you can implement these guidelines to create a more secure environment. Most of these tips apply to Fibre Channel SANs, but some will also be valid for IP-based storage networks.

It's important to note that the term "security" can mean a lot of things. It might include concepts such as availability (or the ability to access and use data) and authenticity (the ability to verify that data is correct). This article focuses on the most basic aspect of security: freedom from intrusion and destruction by unauthorized or authorized people and processes. The emphasis is on data and system integrity—the assurance that data and devices are not changed in an inadvertent or unwanted fashion, including deletion, addition, and modification of data—and accountability, or knowing that something has changed and who made the change.

Tip #1: Don't forget physical security

Too many IT managers (and vendors) focus on high-tech solutions. But high-end technology won't matter if backup tapes are left lying on a desk so that someone can walk off with them. You would be surprised how many programmers and system administrators toss tapes, CDs, and floppy disks on the front seat of their car and drive off. Each time that happens you're at risk of losing important data or having someone look at things he shouldn't see. Many hackers get good, highly confidential information from printouts tossed in the trash.

One of the best types of denial-of-service attack is the least sophisticated: the off switch. It only takes a few seconds for someone to turn off a server, pull the plug, or yank out a cable. Most of the time this is not even a conscious act. One careless move can do more damage than a determined hacker.

Fortunately, this is the easiest vulnerability to fix. Policies that outline proper media handling are a simple way to ensure that data isn't lost due to carelessness. Of course, you have to enforce those policies to make them effective.

Good locks that limit access to data centers, together with swipe cards, are inexpensive. Just make sure no one props open the doors.

Tip #2: Disable the ability to change the WWN on an HBA

There is a tendency to think of World Wide Names (WWNs) as immutable since, like Ethernet MAC addresses, they are unique and burned into an HBA by the vendor. Actually, many HBAs allow the WWN to be changed. This is usually accomplished from the configuration utilities that come with the HBA. In some cases these utilities are available during system boot before security software loads.

Being able to spoof a WWN gives a device or computer the same identity, and hence the same access, as another device on a different port. This will cause conflicts within the system and can allow a system to do damage to attached devices. A storage system doesn't have to be the target of a hacker for this to occur; it could be due to a careless system administrator. Either way, it needs to be avoided. WWN spoofing, whether intentional or unintentional, provides an easy path to data destruction or an unstable system. At the very least, having two devices with the same WWN will lead to indeterminate behavior within a SAN.

There is a valid reason that some HBAs support this feature: It allows an HBA to be salvaged if it becomes damaged and its nonvolatile memory is overwritten. Reload the firmware, reset the WWN, and on you go.

The risks clearly outweigh the benefits. If the nonvolatile memory is overwritten you can always send the HBA back to the manufacturer to get it re-initialized with a new WWN. Most HBA manufacturers that allow the WWN to be changed also allow the feature to be disabled. If that is not the default for your HBAs, change it so that it is. If the HBA relies on external utilities to accomplish this task, remove them from your system and keep them on a CD or floppy in a locked cabinet.

Tip #3: Always be in the zone

Many Fibre Channel installations do not deploy zoning. It's tempting to think that since a SAN is small, it doesn't need to be zoned. Zoning can also be difficult to set up and might not seem worth it for small homogeneous SANs.

Unfortunately, an unzoned system is not secure. Anyone with a Fibre Channel HBA and a computer can plug into a SAN and do damage. It gets worse when you have iSCSI gateways that could let almost any computer with the right drivers access the SAN. A lot of damage can happen inadvertently, too. In addition, if you connect a Windows server into an all-Unix, unzoned SAN, there is the potential for the Windows system to overwrite Unix volume information on the disks.

The simple solution is to zone every port, even unused ones. Unused ports should have zones that include only that port until you have a use for it. As long as Fibre Channel zoning doesn't provide for a default zone, this is necessary.

Tip #4: Use hard zoning

Soft zoning, or the ability to zone based on WWN or alias name, is much more flexible than hard zoning based on specific ports. It also is much less secure. Combined with a spoofed WWN, soft zoning leaves a security hole even a novice can exploit.

Soft zoning doesn't physically keep hosts from devices. Like LUN masking, it limits what a host can "see." But data can still be written to "unseen" devices. Hard zoning actively limits access to other ports, making this form of attack impossible. Soft zoning based on WWNs can also leave open a path to a device from a spoofed HBA. Since the WWN seems to belong in the zone, it is possible for a host with a spoofed address or alias to participate in the zone even though it was not intended to be part of it. This should be considered an exploitable vulnerability.

Hard zoning doesn't stop someone from disconnecting a system connected to a port and replacing it with another one. However, a disconnected system is likely to be noticed much more quickly than a new or altered one. With soft zoning, the basic purpose of zoning (device isolation) can be defeated. Consider using hard zoning on all of your Fibre Channel switches.

Tip #5: Encrypt data on backup tapes

If your physical security is breached or a system administrator ignores policies, tapes can easily be stolen. This denies the organization only the use of the tape. Assuming this happens, the objective is to deny the thief the ability to use the information on the tape. One simple way to do this is to encrypt data during backups. This is usually a feature of the backup software. Even if encryption is available only as an add-on option, it is worth the money.

Many system administrators don't enable encryption because it slows down backup and subsequent retrieval. The tradeoff is better security. Having unencrypted tapes means that the data can be accessed by anyone with software that can read the tape format.

Tip #6: Consider inline encryption for critical data

Another alternative for protecting data "at rest" (on tapes or disks) is an encryption appliance. These products encrypt data as it is written to disk or tape. They may make it difficult for a different host to read data on the encrypted disks and impossible to read information from the media if it is removed from the system. The key advantage of these appliances is that they automatically encrypt data, supposedly without degradation in write-and-read speeds.

However, there are several downsides to this technology. First, the products are still relatively new. Second, it means buying yet another box, as well as the ongoing expense of managing the devices. Finally, encrypted data on a disk is useless if the encryption device fails. That's why vendors advise implementing encryption appliances in redundant pairs, which obviously drives up costs.

Still, the upside from these devices can be significant. It is harder to "accidentally" turn off an encryption appliance without someone noticing. The ability to work at or near line speed is also important, reducing the biggest disincentive for using encryption now.

In the future, encryption devices may be integrated into intelligent storage switches, which would presumably lower costs. If an organization is experiencing problems now, however, these appliances are worth considering today.

Tip #7: Use virtual fabric features

If you have the budget, you should consider the emerging "intelligent storage switches," which allow you to carve up a SAN into virtual fabrics, providing isolation that goes beyond zoning. The result is that any attack on the system is held to a small virtual fabric. Damage is limited even for threats capable of attacking the switch's fabric services.

However, there are some serious issues to consider with intelligent storage switches. First, they are new, do not have a proven track record, and are relatively expensive. Another problem is that virtual fabric features are usually available only on large director class switches. Many SANs, however, have a relatively small number of connections and do not require directors. The Cisco MDS product line is an exception, providing Virtual SAN (VSAN) features on the low-end of the line.

Another key advantage these switches have is that they are extensible platforms that can support fabric services, and they may support advanced security features in the future.

Tip #8: Use policy-based access features and multiple logins

It is surprising how many system administrators never change the passwords on their hardware. Nor do they take advantage of features such as multiple logins with different access levels. The result is that anyone who has the system password for a device has complete access to its functions. Even worse, since change logging is often tied to login names, it is impossible to know who did what to a system. This creates a security vulnerability that can be exploited by any disgruntled employee. To be fair, a number of devices don't allow more than one login and quite a few of those that do, do not restrict access to functionality based on login.

Set up as many logins as there are administrators, and limit the actions they can take. And don't forget to enable logging if it's available.

Tip #9: Secure the network and servers

For the most part, if hackers can get to a server, they can get to the storage. Most server software needs unfettered access to the storage. From a security point of view, this is a vulnerability that is easily exploited. What many hackers want to get at is actually the data—either to view it or destroy it. Access to the data must be the first place to look when securing SANs, namely, the servers and networks attached to the SAN.

SAN security is only part of the overall data-center security plan, "defense in-depth" is the only way to have a truly secure system.

Tip #10: Use LUN masking

LUN masking is a relatively weak security mechanism, because it just restricts information returned by a target device via the SCSI Inquiry command. The LUNs exist and are accessible but are not reported back to the host device. A programmer with a basic knowledge of SCSI protocols can easily defeat LUN masking by simply writing to LUNs that, though "unannounced," still exist. There are a number of valid utilities that operate similar to a port scanner and ignore LUN masking.

However, LUN masking does serve a very valid function: It keeps misbehaving systems and mistakes by system administrators from causing widespread havoc.

Most RAID arrays provide LUN masking for this reason. To defeat LUN masking, you usually have to be trying to defeat it or have a very badly behaving software application. Since most host operating systems and storage applications respect LUN masking and won't mount masked disks, it keeps mistakes such as overwriting data owned by a different host from occurring. It also creates yet another barrier for a hacker to overcome.

Used in conjunction with hard zoning (and possibly virtual fabrics), LUN masking provides an additional layer of protection. Even if hackers get into a server, they will only be able to access the data on the LUNs available to that server unless they have special LUN scanner software and can run it on the server.

Tip #11: It's really about people

Ultimately, people represent the real threat. All the system vulnerabilities will cause no harm to the business if a person does not initiate some action either willfully or accidentally. Knowing who in an organization is capable of what, both technically and temperamentally, is key to avoiding bad situations.

Finally, security policies need to be developed and communicated to everyone in the company who might interact with the SAN. Many of the tips listed above will have no effect if there are not enforced security policies.

SANs create security risks that didn't exist before. The very features that make SANs appealing and useful can be used against the SAN and the company. While the industry waits for more-sophisticated technology, there are many things that can be done to minimize security problems.

Tom Petrocelli is president of Technology Alignment Partners Inc., an analyst and consulting firm (www.techalignment.com).

This article was originally published on September 01, 2003