This article can also be found in the Premium Editorial Download "Storage magazine: Comparing the top data backup packages."
Download it now to read this article plus other related content.
Device:device interaction occurring between initiators and targets and WWN spoofing is the most likely mechanism to be used by a vandal to gain access to your targets. Zoning and LUN masking will serve as your allies in preventing attacks to individual targets. However, software zoning or LUN masking alone can't provide complete protection. If physical security has been breached, the perpetrator only needs to know the WWN of the interested host to bypass the software zone restrictions you have in place and begin accessing the name server (FFFFFC) and the host's assigned LUNs. Again, we see the importance of physically securing remote switches.
Hardware zoning--the practice of using domain IDs and port numbers to identify zone members--is more secure than software zoning because it requires the intruder to have physical access to the switch port that the interested host is plugged into. In this case, even if the intruder had access to a SAN switch in a remote software development area, they still couldn't access the targets of an accounting server that is physically connected to a more secured switch.
|Fighting break-ins on four fronts|
Apart from physical security, you must guard your SAN from intrusion through four kinds of paths, as shown here.
User:device interaction is limited to those interconnect devices that can be compromised by gaining physical access to a serial port or user interface directly on the device. Unless terminal servers are used, physical access is required for a breach.
Some vendors have chosen to outfit some of their SAN equipment with push-button user interfaces. Although convenient, the consequences of a physical security breach may outweigh the benefits when you consider the number of operations that are available via this interface.
Not only is there a concern that an outside intruder could alter the device's configuration, but we should also consider the inquisitive intern or trainee that has an interest in developing their SAN expertise. These interfaces should always be password protected or otherwise disabled to prevent this.
Accounting and event association with other monitoring and reporting products are essential in establishing SAN security policies. For example, the OS supporting your switching gear should have the ability to report errors and port status changes to a syslogd process on an accessible host. If so, point all of your switch's syslog clients to a host running a syslogd server process, scan the associated log file and then report the event to your network management server.
If your business requirements mandate a more robust security approach, ask your security vendor to provide you with a list monitoring applications that their product provides hooks into. This will give your operations staff eyes into the data center to determine when physical connections have been broken, as well as give you access to the Simple Network Management Protocol's (SNMP) Management Information Base.
Implementing a security plan that protects these four borders and provides additional administrative features provides your applications with heightened security, ease SAN administration and provides a reliable reference for tracking down anomalies that occur in your SAN. You'll have to decide how to implement this plan--whether to exploit the tools available to you through your hardware offering, purchase layered security products or some combination of the two. I recommend the latter as the best approach.
This was first published in March 2003