If you can, use separate switches isolated from the network used by your workstation traffic. If an attacker can't physically get to the storage network, he can't do anything with it and must turn to a different attack vector.
If policies or finances don't permit physical separation of hardware, logical separation is your second best option. Any network switches that you can trust for server and storage traffic will be equipped with the capability to establish virtual LANs (VLANs). An attacker would need to know the user ID and password of the network switches in order to gain access to the traffic. So, make sure that the user name and password on the networking equipment are not root/root.
Once you have established physical separation -- or as close to that as possible -- the next thing is to make sure that systems connecting to storage controllers over the iSCSI network are protected. There are two aspects of protection here; physical and logical. Securing physical access to the server room is an obvious but all too often overlooked aspect. Beyond that, you need to protect the data that's on the wire.
Ensure that you implement controls on the storage platform so that any logical unit numbers (LUNs) you present to servers and snapshot backup information can't simply be hijacked by an attacker. Each storage vendor has its own name for it, but essentially it's the same as LUN zoning on FC storage networks. Only allowing a LUN to be accessed by the server that owns it is a simple and effective control on key data.
There is a problem though. While physical or logical separation is fine for block-based (SAN) data traveling between a server and a storage system, a unified storage platform can present LUNs to servers over iSCSI and network shares to client PCs so that organizations may dispense with traditional Windows file servers. Physical separation of users and iSCSI storage is therefore not possible. While all iSCSI storage systems have multiple network interfaces to separate different types of data, the fact is that it all comes together in the iSCSI storage platform.
If your storage system allows it, consider IPsec. This is the implementation of a common, certificate-based security system where all packets traveling across the wire are encrypted and authenticated. For more about IPsec on iSCSI storage systems take a look at: technet.microsft.com.
You may already be familiar with IPsec implementations on Windows networks, as it's often used to protect traffic flowing across networks that may be susceptible to unauthorized monitoring and interception. Extending IPsec to your storage networks could represent the easiest path for you by leveraging skills that your Windows support professionals already possess.
The primary alternative to IPsec is the Challenge Handshake Authentication Protocol (CHAP). There are two options here as well. The first option is inbound to the storage platform where the storage authenticates the "initiator," an iSCSI term for the device that is accessing the storage over the network. The second option is where both target (the storage) and the initiator authenticate each other. The storage first authenticates the initiator (server, PC, etc.) and then before data is transmitted the initiator authenticates the storage.
Remember though, if you don't provide physical security and prevent unauthorized people from gaining access to your servers, storage and PCs, you may as well not bother. The biggest failing in any network security design is the end user or the IT administrator who wedges the server room door open. The same concept applies to your backups. There's no point in taking complex precautions to secure data when it's on the wire if you simply back the data up to tape and hand it over to the offsite tape storage facility. Consider tape encryption.
If you want to learn more about iSCSI security and authentication, please check out this paper, which provides an interesting pictorial of the authentication flow.
About the author: Mark Arnold, MCSE+M, Microsoft MVP, is the principal consultant with LMA Consulting LLC, a Philadelphia, PA-based private messaging and storage consultancy. Mark assists customers in designs of SAN-based Exchange implementations. You can contact him at firstname.lastname@example.org.
This was first published in October 2008