News Stay informed about the latest enterprise technology news and product updates.

Yes, security is a real issue for SANs

SAN expert Chris Poelker answers questions on SAN security. Is it a real threat?

There's a lot of SAN going around out there in IT land and with that, an interest in SAN security. asked SAN expert Chris Poelker to give us his take on a few of the concerns CIOs and administrators are telling us they have with securing their networks. These concerns include data vulnerability, what a SAN security breach looks like and a checklist for CIOs. How real is the threat that someone could "break into" a SAN?

Chris Poelker: SAN security means data security. Today's hackers use IP networks or dial-up connections to steal data, or do other malicious damage to corporate networks. Since a SAN is simply a networked storage container for data, it is usually not accessible via an outside network connection. Say you have a small data center with a simple SAN installed, a few switches and perhaps sixteen to 30 hosts attached to the SAN for data access. If all the management ports on the switches and storage arrays use a physically different network than your public corporate LAN and no one can simply walk up and add a server to a switch, you should be fairly safe.

So for those folks with smaller SANs and good physical control of resources, security should be considered but you're probably going to be just fine.

So when should you start to worry? Just because your SAN is secure does not mean your data is secure. Any server connected to the SAN with an outside LAN connection is still vulnerable to the data it has access to. LUN security may prevent access to data that belongs to other servers but hackers can still break in and delete data through the corporate LAN connection. This is why SAN security starts with LAN security. Make sure your corporate LAN is safe first, then worry about the SAN. One without the other is useless.

To figure out what you need to secure, all you need to do is look at the access points into the SAN. I'll preface my comments with the fact that as of today, I have never heard of anyone breaking into a SAN. It is possible though, so let's look at the vulnerabilities:

1. No Physical security to connections within a data center
2. Using data replication over an unsecure IP network
3. No SNMP security
4. Management ports connected to public LAN
5. Unsecure servers
6. Dial-in access to SAN components

1. All SAN switches have both a console port and an IP port for management of the SAN. If someone is able to beak into your data center, all they need to do is hook up a laptop to any switch RS232 console port and they can zap all kinds of things. Make sure your data centers are physically secure and you trust your people.

2. Data replication over unsecure IP networks is asking for trouble. Anyone with access to a sniffer or anyone who can tie into the data stream and capture data may be able to do damage,or steal data. Use encryption where possible, or use optical networks with dedicated links between sites.

3. SNMP is used to capture error conditions or set certain parameters in the SAN. If your SNMP setup is not secure, you could be looking for trouble. Use the latest version of SNMP that has better security hooks, and make sure you don't do something silly like leaving the community string as "public."

4. Leaving device management ports exposed to the corporate network with no security in place is the most likely candidate for someone to break into your SAN. Every switch, storage array, tape library, etc. has an IP connection for management. Most devices do not have any way to protect themselves from viruses on your corporate LAN. Use a physically separate secure internal LAN consisting of only your SAN components and a secure management server for all SAN IP management connections.

5. Unsecure servers that can be hacked into are the best way to break into your SAN. Keep your servers secure. Period.

6. Any device that lets an external caller connect to the device for remote access is a security hole. SAN devices should call out, not let anyone call in. If your device needs to be fixed, let it call out and ask for help and send a technician in to fix it. Fixing it remotely, by someone who may not know exactly what's currently going on in your data center, may be risky. What would a SAN break-in look like?

Christopher Poelker: Interesting question. If someone broke into your SAN to steal data, they would have to connect up via a server. If you monitor your connections, you would see that a server was added and removed. If they accessed the data through a currently configured and connected server, you may never know it happened. To steal data that belongs to a particular server involves simple SCSI reads. If you have LUN security in your storage arrays, the only data able to be accessed would be the data that that server has access to inside the array. Why do a lot of storage pros have blinders on about the security risks exposed in their pooled storage?

Christopher Poelker: The security risks are mostly for IP connections today. All security in a SAN starts with IP. If the servers connected to the SAN are not secure, then the SAN itself is exposed. SAN professionals may sometimes take it for granted that network security should be done by the folks that handle the network and not the storage guys. This is why most storage groups within a company consist of a database person, a network person, a server admin and the storage admin. What type of checklist or questions should CIOs ask their storage folks to ensure that the right protections are in place?

Christopher Poelker:
1. Is the IP network secure?
2. Is the data center secure?
3. Do we trust our employees?
4. Do we use encryption when needed?
5. Are we using iSCSI?
6. Have we looked into iSCSI security methods?
7. Do we replicate data, or do we have access to data via remote links?
8. Can anyone dial-in to our SAN?

Dig Deeper on Data storage strategy

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.