Many companies are deploying Storage Area Networks (SANs) to offload data traffic from a company's local area network and servers onto a dedicated storage network, thus improving the performance and availability of data across the enterprise. Unfortunately, the security aspects of a SAN are often an afterthought, and, as storage area networks continue to grow, and become more complex, securing the SAN becomes paramount. After all, the system architecture is only as strong as its weakest link.

Leveraging the network for storage has adverse security implications. System administrators must balance the advantages of consolidated storage against the security concerns raised by introducing a network between a computer and its disks, and creating a single, central target for hackers. Regrettably, SAN security is often overlooked, because it is relatively new and security features are limited. The primary objective of most system administrators is to make the system operational, and often, the first time security is even considered is after it has been breached.

The crux of the problem is that companies need to stop thinking of SANs as disks and start thinking of them as networks, and securing them as one would a network. Once you begin connecting SANs to your servers, there is the potential for hackers to leverage one computer’s connection to break into other computers. Thus, a SAN presents the same security issues as a data communications network, and it would behoove companies to follow the same security practices that are used for LANs and WANs.

There are some basic architectural considerations for secure network design:

1. Physical separation and/or logical separation
2. Limiting protocol choices across the SAN
3. Controls for hardware and software maintenance (privileged access)

SAN Segmentation

By segmenting a company's SANs according to functionality and creating multiple independent SAN architectures, you are effectively isolating network traffic, which increases security, enhances performance, improves scalability and minimizes contention.

Any production infrastructure will have several different classes of machines:

• Machines directly connected to the network outside of the production infrastructure, such as firewalls, load balancers, and in some networks, web servers.
• Machines indirectly connected to the outside network -- not terminating network connections directly, but interpreting data from untrusted sources, such as URLs, filenames, and data from web forms or other client software. These machines include web servers, FTP servers, etc.
• Machines that are leveraged by machines in the first two classes for services, but that never directly interpret data from the outside, such as application servers.
• Machines that provide persistent storage for data, such as database servers (although other servers often store key data as well).

The key to secure network design is ensuring, as much as is possible, that machines in different security classes do not trust each other or share common resources. It is also desirable to have different functions performed by different machines, and to isolate those machines from each other to whatever degree is feasible. Since security is increased as separation is increased, a balance must be struck between separation and consolidation if a SAN is to be used at all.

A SAN shouldn’t connect two different classes of servers, such as a web server and a database server, because a web server accepts untrusted information from the outside world and attempts to interpret it. One needs only to look at a handful of the most recent security exploits to see that the majority of security issues arise from the interpretation of untrusted information. Most security breaches are performed by providing carefully crafted information to a server, causing the server to crash and execute arbitrary code or provide access to programs and information that are supposed to be unavailable. Since it is impossible to write perfect software to do this interpretation, there is always a chance that a web server will be breached. If a web server is connected to a database server via a SAN, then the door is open for a hacker to attempt to leverage the web server's SAN access to directly attack the database server and potentially obtain unlimited access to corporate data.

VLAN (Virtual Local Area Network) technology can provide some separation for SANs, and current SAN switches contain technology to implement what is in essence VLANs on a SAN. While VLANs are useful, it must be remembered that this is logical separation, which is not as secure as physical separation. Many companies use VLANs extensively in place of physical separation between their networks and are therefore susceptible to attacks that "jump" from one VLAN to another. For high security, physical separation is still preferable. As with all security decisions, however, you must evaluate the risks and costs of alternative approaches, based on corporate objectives. What might be appropriate for one installation is not appropriate for another.

IP vs. SCSI

Another important security issue, with regular networks or SANs, is what protocols you allow. SANS were originally envisioned as extensions of regular disks, thus they support SCSI. SANs can also support IP (Internet Protocol), however, SANs are not built with security in mind. Thus, if you decide to run IP over a SAN, you further increase risk, because you are bringing IP-based exploits to the SAN without the current protections that are available on standard IP-based networks.

Sure, IP brings familiarity and tool availability, which makes maintenance tasks, such as backup, easier. Yet, we have assessed the value and determined that it is not worth the increased security risk for the type of applications that our customers host in Quadrix Solutions’ eData Centers.

Maintenance and Future Developments

Maintenance issues create further opportunities for crackers, especially since the tools currently available for SAN maintenance are very immature. Proper authentication and access control is really not readily available for SANs. Often, administrative access is available to anyone on the network who can reach a central NT server that controls the SAN. Careful design and implementation, however, can provide for secure maintenance access. In the future, look for improvements in maintenance tools, the development of SAN-capable firewalls and better authentication techniques for ensuring that a disk partition is only being accessed by the intended machine.

Fortunately, at this point, crackers are not typically viewing the SAN as a point of leverage, so even a certain amount of obscurity can help reduce the likelihood of a security breach. Security through obscurity can’t protect against the seasoned cracker, but it can provide a small additional component that will reduce the number of amateur attacks.

Five Fundamental Principles of Security

The point of a SAN is to make a network attached disk look like it’s locally attached. Don’t lose sight of the fact that while you are convincing the machine that the disk is local – it is unequivocally part of a network. Thus, even if you are not sharing the disk between multiple machines, a breach of security on one machine may result in a breach on another machine on the same SAN. To minimize security breaches, companies should pay heed to “Five Fundamental Principles of Security”:

1. 100% security does not exist.
2. Security risks are directly proportional to software complexity.
3. Implement security in layers.
4. Don't allow a breach to be leveraged elsewhere.
5. You're never done! You must keep up-to-date on software packages, drivers, and security alerts. Log files must also be regularly reviewed for anomalies.

At the end of the day, companies must find a balance in terms of what is practical, secure, and cost-effective. Sure, it is human nature to avoid dealing with the difficulties of securing a SAN. By applying the basic concepts of network security, companies can think of SANs in a new light and prevent security loopholes before the weakest link breaks down.