By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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. SearchStorage.com: 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. SearchStorage.com: 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. SearchStorage.com: 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?