One of the biggest vulnerabilities in SAN security isn't in the SAN at all. It's in the enterprise LAN. For example in a presentation titled "Networked Storage: Security Framework Considerations", Hitachi Data Systems (www.hds.com) rates the security threat associated with the connection between the manager and the SAN fabric as high to medium, where other types of traffic, such as from device to device rate medium to low.
Of course this is exactly where the LAN fits into the SAN picture. It doesn't carry the storage data, but it is used by most SANs to link the SAN to the management console. An intruder on the LAN can send commands to the SAN like a storage administrator and what that means is that a successful compromise of the LAN can allow someone to do just about anything they want to your SAN and its data.
Protecting your SAN from the LAN requires multiple layers of security, starting with the LAN itself and moving through the configuration of the administration software. LAN, SAN and storage administration software all have security options available. The important thing is to use those options to create a self-reinforcing safety net around your SAN.
The beginning is to make the LAN as secure as possible. This typically involves using things like firewalls if the LAN is connected to the Internet as well as good general security.
The more SAN-specific parts of LAN-SAN security start with access and authentication. It is important that your SAN accept management commands only from known, trusted systems. This means restricting which computers can act as administration consoles and authenticating those computers before the commands are executed.
If possible, SAN-management information, especially passwords and user names, should be encrypted. Many applications offer this feature, but often it isn't the default.
Of course you should use your system's logging features to create a record of management activity or any attempts at management activity. This not only helps detect attempted security breaches, it is invaluable if the SAN configuration has been changed, either accidentally or maliciously.
The alarm features built into SAN and storage administration software can alert administrators to attempts to compromise the SAN. You should define normal activity parameters for management activity on the SAN and set thresholds for sounding alarms when those parameters are significantly exceeded.
Don't neglect to control who can change security policies and parameters, including zoning. Ideally security policies and configuration should be centralized and all policies should be distributed from a trusted source.
Finally, if you don't need a feature in your SAN software, turn it off. A great many seemingly innocuous features in SAN and storage-management software carry security risks. If you don't need the feature, why run the risks.
SAN security is attracting considerable attention these days and there are a number of white papers and presentations available discussing the issues.
"Networked Storage: Security Framework Considerations" is available at: http://ieee-tcia.org/sisw2001/HDS_IEEE_sisw_12_4_2001.pdf.
"Securing Networked Data Storage" is available from McData at: http://www.mcdata.com/downloads/whitepapers/ securing_netdata_storage.pdf.
Another presentation on SAN security, this one from Brocade, titled "Fabric Security: (Securing the SAN Infrastructure) is available at http://itanium.ee.ualberta.ca/hpw2002/paper/9425.pdf.
Rick Cook has been writing about mass storage since the days when the term meant an 80K floppy disk. The computers he learned on used ferrite cores and magnetic drums. For the last twenty years he has been a freelance writer specializing in storage and other computer issues.
