With a little planning, your iSCSI storage network can be even more secure than a legacy Fibre Channel storage network.
If you're thinking about implementing an iSCSI storage network, as sure as the sun sets each night, someone will ask about security. Here's the short answer: iSCSI can be as secure as you want it to be.
"Now that storage is being put back on Ethernet and IP networks, customers are becoming concerned about access control and encryption," says Kyle Fitze, marketing director for Hewlett-Packard Co. SANs, StorageWorks Division. The commodity protocols and hardware used in iSCSI networks can, in theory, connect to just about any computer, from a rack-mounted server to a laptop or handheld PC. iSCSI was built from the ground up with strong authentication and encryption capabilities ... as long as they're used.
So if iSCSI has so many security features, why do so many people ask about security? The reason is that iSCSI is much more accessible than previous storage protocols. Ethernet hardware and IP support have become ubiquitous, both inside and outside the data center. The technology uses common protocols and is supported by the majority of OSes available today. This means there are millions of people who could theoretically try their hand at breaking into an iSCSI SAN.
This accessibility is also a blessing for iSCSI. On the positive side, there's a lot more understanding and acceptance of its basic concepts vs. Fibre Channel (FC). There's also a legion of trained network engineers who have the skills to build a secure network for iSCSI to run on. Technologies like Challenge-Handshake Authentication Protocol (CHAP), Remote Authentication Dial-In User Service (RADIUS), VPN and IPsec have proven to be powerful and reliable over a decade of widespread use. This stands in contrast to the arcane security features, most of which are rarely used, offered by FC storage device vendors. "Our iSCSI SAN is definitely more secure because of our previous experience with IP and Ethernet," says Ron Braden, IT director for the Town of Vail, CO. "Building a secure IP network is second nature to us."
A secure system addresses data confidentiality, integrity and availability. Most people begin with confidentiality. But availability is equally important and probably accounts for more security breaches. A denial of service attack is much simpler to engineer than an encryption hack. Data can also be deleted, requiring time-consuming restores. Integrity is a more subtle topic. Substituting bad data for good data can go unnoticed and could lead to more serious side effects than simply losing access to a system. Problems with integrity can also lead to legal and compliance issues that are more costly than any technical problem.
|What to do first|
iSCSI experts agree that there are certain things everyone using this technology should do:
Isolate the iSCSI network
The most important step in building a stable and secure iSCSI SAN is to keep it separate from other networks (see "What to do first," this page). "We were not as worried about security as about denial of service," says Braden. "It was too risky from a performance standpoint to allow storage traffic to share the network with other applications." Braden's iSCSI SAN contains what's called an "air gap," which contains dedicated Ethernet switches and isolated fiber-optic cables for storage. This approach reduces the risk that a problem on the main data network would overflow into the SAN. Each of Vail's SAN-attached servers has two Ethernet interfaces: one for the SAN and one for the LAN.
A larger iSCSI implementation at an international bank was configured similarly. Routers and switch configuration throughout the network prevented iSCSI data from leaking from one network segment to another. And the bank used iSCSI host bus adapters (HBAs) instead of standard Ethernet cards. The HBAs it chose couldn't be configured to carry general network traffic, which reduced the risk of an intruder using the iSCSI SAN as a "bridge" to other secure networks.
Who are you?
There are many ways to authenticate a person before granting them access to the iSCSI SAN. You can authenticate based on who someone claims they are by requiring positive identification before talking to them or by continually checking their identity as long as they're connected.
Borrowing a concept from FC, most iSCSI arrays allow you to control access based on a unique identifier for each attached client. While FC uses a world-wide name for LUN masking, iSCSI can use an IP address, a MAC address or a unique name assigned to the iSCSI initiator software running on the client to hide targets. While none of these methods is very secure, they do protect against accidents on the part of storage administrators. Plus, some iSCSI initiators have been known to "grab" all the storage they can see, making masking a requirement. All of these values can be easily changed in software, so spoofing them is trivial.
If masking iSCSI targets isn't enough, CHAP adds another layer of security. The common authentication protocol in IP circles, CHAP uses public key encryption concepts to verify the identity of connected devices. It validates that both devices know a "shared secret" like a password, making it harder to gain access to the storage array. "The iSCSI standard requires that all iSCSI initiators and targets include CHAP support, but not all customers choose to turn it on," reports Eric Schott, director of product management at EqualLogic Inc.
CHAP can also be used to authenticate the array to the clients. John Spiers, founder and CTO of LeftHand Networks Inc., suggests all iSCSI users implement two-way CHAP, also known as Diffie-Hellman CHAP or DH-CHAP. "A single-way CHAP session could be spoofed to break in or set up a man-in-the-middle [attack]," says Spiers. "DH-CHAP is much more secure."
But CHAP isn't totally secure. "CHAP is subject to offline dictionary attacks--the secret can be guessed with a powerful computer," admits Alan Warwick, lead software design engineer for iSCSI at Microsoft Corp. This would be time-consuming and difficult, however, because a CHAP login would have to be captured by a network sniffer situated on the storage network. Warwick suggests those concerned about the possibility of a CHAP attack use 16-byte secrets and change them frequently.
The most secure option for authentication is IPsec Authentication Header (AH), which has a digital signature on every packet. Unlike a full implementation of IPsec that encrypts the entire packet, IPsec AH merely authenticates the sender, recipient and checksum for the message content. This effectively authenticates the entire message, but does nothing to protect its content from snooping. Although there's still some performance impact, it's much easier to encrypt a 60-byte header than a 64KB packet.
Snooping iSCSI packets
Snooping the contents of iSCSI packets, one of the first threats people mention when asked about iSCSI security issues, is less likely to occur than other types of attacks. An IP SAN with no security controls will probably run on a switched Ethernet network. Switches create point-to-point paths for data, so each port sees only the traffic intended for it. To snoop on iSCSI traffic requires some sort of advanced sniffer function to send all traffic to your port, which would require administrative access to the Ethernet switch.
There are many options to protect data in motion over the network. IPsec Encapsulating Security Payload, for example, provides advanced authentication of each packet, effectively eliminating the possibility that someone could read data while it travels across the network. And if stronger encryption is required, it's possible to replace the standard encryption protocols used by IPsec with a more powerful alternative.
Another option is to use an encrypting file system on the server to encrypt data before it gets to the IP SAN. This effectively encrypts data in motion as well as data at rest because no data leaves the server unencrypted. It also prevents all sorts of man-in-the-middle attacks on the network because any tampering with the content interferes with the server's ability to read the data. The downside of using an encrypting file system is the impact it can have on server performance. Even a powerful server can see a noticeable performance hit when using this type of encryption technology.
A VPN creates a point-to-point encrypted tunnel between secure networks. The use of VPN technology should be a requirement whenever sensitive data travels across an uncontrolled network. The Town of Vail relies on an encrypted VPN tunnel for replication to a disaster recovery site, leveraging an existing WAN connection for its daily synchronization.
|A more secure iSCSI on the way|
Hardware–accelerated IPsec. Changes are coming that will make iSCSI even more secure. Vendors say hardware–accelerated IPsec will be a common feature in iSCSI initiators and storage arrays within two years. "Today's CPUs can keep up encryption processing at gigabit speeds, but 10Gb Ethernet will change all of that," says John Matze, president and CEO of Siafu Software LLC, and one of the original authors of the iSCSI protocol. He expects encryption processing will move to routers or storage arrays to provide wire speed throughput at 10Gb/sec.
Microsoft Corp.'s iSCSI Software Target. As Microsoft's market share of the entry-level iSCSI market grows, it will become easier to implement security technologies through its iSCSI target software, which can be configured using the same group policy editor that controls the configuration of Windows servers and desktops. Many iSCSI arrays also integrate smoothly with Windows domains for management authentication.
Trusted Platform Module. Changes in server architectures also have implications for iSCSI. A Trusted Platform Module (TPM) is a specialized chip that can be installed on the motherboard of a PC or server to authenticate the computer rather than the user. To do so, TPM stores information specific to the host system, such as encryption keys, digital certificates and passwords. TPM minimizes the risk that data on the computer will be compromised by physical theft or an external attack. TPM chips are expected to spread to disk drives and storage systems. While the TPM wouldn't remove the need for any of the current encryption or authentication techniques, it would make data stored on storage arrays even more secure.
Probably the most vulnerable point in an iSCSI network has nothing to do with iSCSI at all. Nearly every network device can be managed remotely over a network. This management traffic can travel in-band (sharing the same network as the data) or out-of-band (using a dedicated network). Almost all storage devices, including FC, SAN and iSCSI arrays, have management ports that operate using Ethernet and IP. In nearly all cases, these management ports are the easiest way to hack into the storage array (see "A more secure iSCSI on the way," at right).
Many management interfaces support outdated or insecure protocols like SNMP, Telnet and HTTP, as well as more secure protocols like Java and HTTPS or SSL. These older protocols can often be exploited for destructive purposes, allowing an attacker to access confidential configuration information or even bring down the array. This is especially true if default user names and passwords aren't changed when systems are configured. Some systems also have default accounts for vendor service, which can be the same across an entire region or even a company's whole product line. These accounts can be especially destructive because they often yield access to diagnostics areas and configuration information.
For this reason, management interfaces must be treated just like data interfaces and placed on isolated nonrouting subnets with firewalls and VPNs to prevent unauthorized access. Unfortunately, this isn't standard practice. In most sites, management interfaces are connected to the main corporate network and left open. The Town of Vail's Braden runs the management app on a server with one network interface card on the SAN and one on the LAN, and uses a remote desktop to access it securely.
|Regulations drive security concerns|
Much of the concern over data security within IP circles is driven by government regulations. On the business side, an equal concern is the threat of litigation. One of the most frequently cited regulations is the Sarbanes-Oxley (SOX) Act of 2002, which requires that certain financial data have an audit trail back to its source. But SOX is only the tip of the iceberg.
California's Information Practices Act, also known as SB-1386, has broad implications. It requires companies that have experienced theft of personal information data to notify any customers potentially affected. SB-1386 has driven many companies to implement encryption so they can protect their customers' private data.
The Graham-Leach-Bliley Act of 1999 and HIPAA also require companies to protect personal data. In addition, the Payment Card Industry (PCI) Data Security Standard has strict requirements for credit card processors. Companies affected by any of these regulations should strongly consider encryption technology and assess whether their storage networks are vulnerable to data theft.
It's important to remember that the stereotypical teenage hacker attacking your systems from across the Internet reflects only a small portion of actual security breaches. You're far more likely to suffer a breach in the confidentiality, availability or integrity of your data at the hands of an insider, whether malicious or not.
There have been numerous press reports of insiders who have absconded with critical data and it's likely there are exponentially more cases that go unreported. Preventing unauthorized employee access to data has become more critical in light of regulations like the Sarbanes-Oxley Act of 2002, HIPAA and the Payment Card Industry Data Security Standard (see "Regulations drive security concerns," at right). Sadly, no current IT technology allows storage managers to understand the importance of the data contained in the bits and bytes they manage. Enabling this kind of security will require a whole new level of interaction between IT and business units.
Not all security breaches are malicious. Many common breaches are accidental or caused by an interaction of unrelated system components. For instance, a system admin could take down a RADIUS server not realizing that it was authenticating storage traffic. Or a backup administrator could restore all files in a directory instead of just the requested one.
A final element to consider is that storage is one of the lower-level slices of the IT systems layer cake. No matter how secure your storage array and network are, data will always be vulnerable if a server or app is compromised. "The focus today is more on securing your servers--if you have access to the server, then you have access to the storage," says LeftHand Networks' Spiers. No amount of encryption or authentication will prevent access by a program or user who's supposed to get in. In the end, all storage admins can do is keep their system reliable and hope others do the same.