How real is the threat that someone could "break into" a SAN?
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.
This was first published in October 2003