Because so many kinds of entities are involved in a SAN, it is useful to approach SAN security from a functional perspective rather than through the entities involved. This means starting with a list of functions that must be achieved and applying that function list to all the entities rather than attempting to secure each entity separately. One such list of SAN security functions is the "Five A's": Authentication, access, audits, alarms and availability.
Authentication is making sure that only authorized personnel can access the SAN. This is usually implemented with a challenge-response protocol, most often based on userids and passwords. However other methods, such as biometrics, could be used. Like all of the Five A's, authentication involves a number of subsidiary issues. For example if user id-passwords are used, the usual password-control procedures apply, including changing passwords regularly and making sure they stay secure. In addition to the 'social engineering' involved in implementing proper password procedures among users, there are a number of technical issues, such as not transmitting unencrypted passwords over the net, especially out of band channels. For all that, personnel authentication issues are probably the best understood of the various SAN security issues because they are common to so much of computer security.
Access is making sure that only the appropriate people gain access to the SAN and its information at the appropriate level. Here the technical issues loom larger than they do with authentication, and storage administrators have more control over the situation. The most basic part of access is determining and enforcing who will have access to what information and what privileges they will have with the data and the SAN itself. Since SANs can differ considerably in their access control capabilities and how they are implemented, the first step is to determine what tools and utilities are available to the administrators to manage access. This will typically include the ability to set read/write/delete permissions for data, limits on who can access SAN management functions such as configuration and features such as zoning and LUN masking. This is typically the function that takes the most time and effort to set up and maintain because of the number of variables and the granularity desired. Ideally each person with access to the SAN would have all the variables set individually to produce a completely unique profile. In practice this isn't possible, both because of the amount of work that would be involved and the limits on the available tools. It is also important to review access privileges regularly and to modify them as duties and responsibilities change. User and administrator access aside, access also includes preventing unauthorized access to information. Encrypting passwords, messages and data moving over the SAN is a powerful tool for defeating unauthorized access. Most SANs include at least some encryption features, however encryption may involve trading off speed for security. If it does and if encrypting everything at the same level of security imposes unacceptable performance penalties, the administrator may want to establish an encryption hierarchy. For example passwords would have the strongest encryption protection, with management and administrative messages next and the data itself with the lowest level of protection.
Auditing access, configuration changes and user activity are important not only to detect security breaches, but to keep track of changes to the network and trends that may affect network performance. An effective auditing plan would include maintaining logs for access to the SAN, configuration changes and user activity. Based on that information, the auditing system should identify both normal and anomalous behavior and include procedures for reacting to violations. Like access control, auditing is usually a matter of inventorying the available tools and applying them effectively. All SANs have audit utilities and additional SAN auditing packages are available from vendors. However it is likely to take some thought and study to develop an effective auditing plan for your SAN.
Alarms are reactions to the results of the audits. They should vary from a simple, non-intrusive notification of minor incidents to full-blown crisis plans in the event of a major threat. It is especially important to set alarms that identify serious problems without crying wolf. Again, this takes study and planning on the part of the storage administrators. The first step in developing an effective alarm strategy involves determining what constitutes a normal pattern of activity on the SAN. In addition to traffic data, this could include use of administrative tools and making changes to the SAN. It is best to think broadly when gathering data on what is normal. Once 'normality' has been established, the next step is to determine how far the SAN activity should deviate from normal before it becomes cause to issue an alarm. Besides the obvious analysis of variance in the SAN activity parameters, this should include consideration of patterns of business activity and possibly external events. For example, if a blizzard shuts down transportation in your area, it is logical to expect more people to log onto the SAN remotely as they try to work from home. On the other hand, you wouldn't expect a lot of attempts to change the SAN configuration in the middle of a blizzard. Like access, effective alarm procedures require constant monitoring and frequent change and updating to keep them in synch with the realities of the enterprise.
Availability isn't usually considered as part of SAN security, but it has an important relation to it. Availability is primarily an architectural issue and refers to the degree of redundancy, fault tolerance and fail-over built into the SAN. However availability also involves disaster recovery and that is usually seen as part of security. In the security context, availability includes developing and maintaining an effective disaster recovery plan to handle incidents that could shut down the data center or destroy data. Disaster recovery requires careful planning and frequent practice to make sure the plan covers everything and will actually work when things go seriously wrong.
About the Author
Rick Cook has been writing about mass storage since the days when the term meant an 80K floppy disk. The computers he learned on used ferrite cores and magnetic drums. For the last twenty years he has been a freelance writer specializing in storage and other computer issues.
This tip originally appeared on SearchStorage.com. This was first published in December 2005
This was first published in December 2005