Storage Area Networking Security Devices
Robert Rounsavall, Terremark Worldwide, Inc.
Storage area networking (SAN) devices have become a critical IT component of almost every business today. The upside and intended consequences of using a SAN are to consolidate corporate data as well as reduce cost, complexity, and risks. The tradeoff and downside to implementing SAN technology are that the risks of large-scale data loss are higher in terms of both cost and reputation. With the rapid adoption of virtualization, SANs now house more than just data; they house entire virtual servers and huge clusters of servers in “enterprise clouds.” 1 In addition to all the technical, management, deployment, and protection challenges, a SAN comes with a full range of legal regulations such as PCI, HIPAA, SOX, GLBA, SB1386, and many others. Companies keep their informational “crown jewels” on their SANs but in most cases do not understand all the architecture issues and risks involved, which can cost an organization huge losses. This chapter covers all the issues and security concerns related to storage area network security.
1. What is a SAN?
The Storage Network Industry Association (SNIA)2 defines a SAN as a data storage system consisting of various storage elements, storage devices, computer systems, and/or appliances, plus all the control software, all communicating in efficient harmony over a network. Put in simple terms, a SAN is a specialized, high-speed network attaching servers and storage devices and, for this reason, it is sometimes referred to as “the network behind the servers.” A SAN allows “any-to-any” connections across the network, using interconnected elements such as routers, gateways, hubs, switches, and directors. It eliminates the traditional dedicated connection between a server and storage as well as the concept that the server effectively “owns and manages” the storage devices. It also eliminates any restriction to the amount of data that a server can access, currently limited by the number of storage devices attached to the individual server. Instead, a SAN introduces the flexibility of networking to enable one server or many heterogeneous servers to share a common storage utility, which may comprise many storage devices, including disk, tape, and optical storage. Additionally, the storage utility may be located far from the servers that use it.
The SAN can be viewed as an extension to the storage bus concept, which enables storage devices and servers to be interconnected using similar elements to those used in local area networks (LANs) and wide area networks (WANs). SANs can be interconnected with routers, hubs, switches, directors, and gateways. A SAN can also be shared between servers and/or dedicated to one server. It can be local or extended over geographical distances.
2. SAN Deployment Justifications
Perhaps a main reason SANs have emerged as the leading advanced storage option is because they can often alleviate many if not all the data storage “pain points” of IT managers.3 For quite some time IT managers have been in a predicament in which some servers, such as database servers, run out of hard disk space rather quickly, whereas other servers, such as application servers, tend to not need a whole lot of disk space and usually have storage to spare. When a SAN is implemented, the storage can be spread throughout servers on an as-needed basis. The following are further justifications and benefits for implementing a storage area network:
• They allow for more manageable, scalable, and efficient deployment of mission-critical data.
• SAN designs can protect resource investments from unexpected turns in the economic environment and changes in market adoption of new technology.
• SANs help with the difficulty of managing large, disparate islands of storage from multiple physical and virtual locations.
• SANs reduce the complexity of maintaining scheduled backups for multiple systems and difficulty in preparing for unscheduled system outages.
• The inability to share storage resources and achieve efficient levels of subsystem utilization is avoided.
• SANs help address the issue of a shortage of qualified storage professionals to manage storage resources effectively.
• SANs help us understand how to implement the plethora of storage technology alternatives, including appropriate deployment of Fibre Channel as well as Internet small computer systems interface (iSCSI), Fibre Channel over IP (FCIP), and InfiniBand.
• SANs allow us to work with restricted budgets and increasing costs of deploying and maintaining them, despite decreasing prices for physical storage in terms of average street price per terabyte.
In addition to all these benefits, the true advantage of implementing a SAN is that it enables the management of huge quantities of email and other business-critical data such as that created by many enterprise applications, such as customer relationship management (CRM), enterprise resource planning (ERP), and others. The popularity of these enterprise applications, regulatory compliance, and other audit requirements have resulted in an explosion of information and data that have become the lifeblood of these organizations, greatly elevating the importance of a sound storage strategy. Selecting a unified architecture that integrates the appropriate technologies to meet user requirements across a range of applications is central to ensuring storage support for mission-critical applications. Then matching technologies to user demands allows for optimized storage architecture, providing the best use of capital and IT resources.
A large number of enterprises have already implemented production SANs, and many industry analysts have researched the actual benefits of these implementations. A Gartner4 study of large enterprise data center managers shows that 64% of those surveyed were either running or deploying a SAN. Another study by the Aberdeen Group cites that nearly 60% of organizations that have SANs installed have two or more separate SANs. The study also states that 80% of those surveyed felt that they had satisfactorily achieved their main goals for implementing a SAN. Across the board, all vendor case studies and all industry analyst investigations have found the following core benefits of SAN implementation compared to a direct attached storage (DAS) environment:
3. The Critical Reasons for SAN Security
SAN security is important because there is more concentrated, centralized, high-value data at risk than in normal distributed servers with built-in, smaller-scale storage solutions. On a SAN you have data from multiple devices and multiple parts of the network shared on one platform. This typically fast-growing data can be consolidated and centralized from locations all over the world. SANs also store more than just data; with the increasing acceptance of server virtualization, multiple OS images and the data they create are being retrieved from and enabled by SANs.
Why is SAN Security Important?
Some large-scale security losses have occurred by intercepting information incrementally over time, but the vast majority of breaches involve access or loss of data from the corporate SAN. (For deeper insight into the numbers, check out the Data Loss Web site. This website tracks incidents and is a clearinghouse of data loss each month.5)
A wide range of adversaries can attack an organization simply to access its SAN, which is where all the company data rests. Common adversaries who will be looking to access the organization’s main data store are:
If one or some of these perpetrators were to be successful in stealing or compromising the data in the SAN, and if news got around that your customer data had been compromised, it could directly impact your organization monetarily and cause significant losses in terms of:
4. SAN Architecture and Components
In its simplest form, a SAN is a number of servers attached to a storage array using a switch. Figure 34.1 is a diagram of all the components involved.
Figure 34.1 Simple SAN elements.
SAN Switches
Specialized switches called SAN switches are at the heart of a typical SAN. Switches provide capabilities to match the number of host SAN connections to the number of connections provided by the storage array. Switches also provide path redundancy in the event of a path failure from host server to switch or from storage array to switch. SAN switches can connect both servers and storage devices and thus provide the connection points for the fabric of the SAN. For smaller SANs, the standard SAN switches are called modular switches and can typically support eight or 16 ports (though some 32-port modular switches are beginning to emerge). Sometimes modular switches are interconnected to create a fault-tolerant fabric. For larger SAN fabrics, director-class switches provide a larger port capacity (64 to 128 ports per switch) and built-in fault tolerance. The type of SAN switch, its design features, and its port capacity all contribute to its overall capacity, performance, and fault tolerance. The number of switches, types of switches, and manner in which the switches are interconnected define the topology of the fabric.
Network Attached Storage (NAS)
Network attached storage (NAS) is file-level data storage providing data access to many different network clients. The Business Continuity Planning (BCP) defined in this category address the security associated with file-level storage systems/ecosystems. They cover the Network File System (NFS), which is often used by Unix and Linux (and their derivatives’) clients as well as SMB/CIFS, which is frequently used by Windows clients.
Fabric
When one or more SAN switches are connected, a fabric is created. The fabric is the actual network portion of the SAN. Special communications protocols such as Fibre Channel (FC), iSCSI, and Fibre Channel over Ethernet (FCoE) are used to communicate over the entire network. Multiple fabrics may be interconnected in a single SAN, and even for a simple SAN it is not unusual for it to be composed of two fabrics for redundancy.
HBA and Controllers
Host servers and storage systems are connected to the SAN fabric through ports in the fabric. A host connects to a fabric port through a Host Bus Adapter (HBA), and the storage devices connect to fabric ports through their controllers. Each server may host numerous applications that require dedicated storage for applications processing. Servers need not be homogeneous within the SAN environment.
Tape Library
A tape library is a storage device that is designed to hold, manage, label, and store data to tape. Its main benefit is related to cost/TB, but its slow random access relegates it to an archival device.
Protocols, Storage Formats and Communications
The following protocols and file systems are other important components of a SAN.
Block-Based IP Storage (IP)
Block-based IP storage is implemented using protocols such as iSCSI, Internet Fibre Channel Protocol (iFCP), and FCIP to transmit SCSI commands over IP networks.
Secure iSCSI
Internet SCSI or iSCSI, which is described in IETF RFC 3720, is a connection-oriented command/response protocol that runs over TCP and is used to access disk, tape, and other devices.
Secure FCIP
Fibre Channel over TCP/IP (FCIP), defined in IETF RFC 3821, is a pure Fibre Channel encapsulation protocol. It allows the interconnection of islands of Fibre Channel storage area networks through IP-based networks to form a unified storage area network.
Fibre Channel Storage (FCS)
Fibre Channel is a gigabit-speed network technology used for block-based storage and the Fibre Channel Protocol (FCP) is the interface protocol used to transmit SCSI on this network technology.
Secure FCP
Fibre Channel entities (host bus adapters or HBAs, switches, and storage) can contribute to the overall secure posture of a storage network by employing mechanisms such as filtering and authentication.
Secure Fibre Channel Storage Networks
A SAN is architected to attach remote computer storage devices (such as disk arrays, tape libraries, and optical jukeboxes) to servers in such a way that, to the operating system, the devices appear as though they’re locally attached. These SANs are often based on a Fibre Channel fabric topology that utilizes the Fibre Channel Protocol (FCP).
SMB/CIFS
SMB/CIFS is a network protocol whose most common use is sharing files, especially in Microsoft operating system environments.
Network File System (NFS)
NFS is a client/server application, communicating with a remote procedure call (RPC)-based protocol. It enables file systems physically residing on one computer system or NAS device to be used by other computers in the network, appearing to users on the remote host as just another local disk.
Online Fixed Content
An online fixed content system usually contains at least some data subject to retention policies and a retention-managed storage system/ecosystem is commonly used for such data.
5. SAN General Threats and Issues
A SAN is a prime target of all attackers due to the goldmine of information that can be attained by accessing it. Here we discuss the general threats and issues related to SANs.
SAN Cost: A Deterrent to Attackers
Unlike many network components such as servers, routers, and switches, SANs are quite expensive, which does raise the bar for attackers a little bit. There are not huge numbers of people with SAN protocol expertise, and not too many people have a SAN in their home lab, unless they are a foreign government that has dedicated resources to researching and exploiting these types of vulnerabilities. Why would anyone go to the trouble when it would be much easier to compromise the machines of the people who manage the SANs or the servers that are themselves connected to the SAN?
The barrier to entry to directly attack the SAN is high; however, the ability to attack the management tools and administrators who access the SAN is not. Most are administered via Web interfaces, software applications, or command-line interfaces. An attacker simply has to gain root or administrator access on those machines to be able to attack the SAN.
Physical Level Threats, Issues, and Risk Mitigation
There can be many physical risks involved in using a SAN. It is important to take them all into consideration when planning and investing in a storage area network.
• Locate the SAN in a secure datacenter
• Ensure that proper access controls are in place
• Cabinets, servers, and tape libraries come with locks; use them
• Periodically audit the access control list
• Verify whether former employees can access the location where the SAN is located
• Perform physical penetration and social engineering tests on a regular basis
Physical Environment
The SAN must be located in an area with proper ventilation and cooling. Ensure that your datacenter has proper cooling and verify any service-level agreements with a third-party provider with regard to power and cooling.
Hardware Failure Considerations
Ensure that the SAN is designed and constructed in such a way that when a piece of hardware fails, it does not cause an outage. Schedule failover testing on a regular basis during maintenance windows so that it will be completed on time.
Secure Sensitive Data on Removable Media to Protect “Externalized Data”
Many of the data breaches that fill the newspapers and create significant embarrassments for organizations are easily preventable and involve loss of externalized data such as backup media. To follow are some ideas to avoid unauthorized disclosure while data is in transit:
• Offsite backup tapes of sensitive or regulated data should be encrypted as a general practice and must be encrypted when leaving the direct control of the organization; encryption keys must be stored separately from data.
• Use only secure and bonded shippers if not encrypted. (Remember that duty-of-care contractual provisions often contain a limitation of liability limited to the bond value. The risk transfer value is often less than the data value.)
• Secure sensitive data transferred between datacenters.
• Sensitive/regulated data transferred to and from remote datacenters must be encrypted in flight.
• Secure sensitive data in third-party datacenters.
• Sensitive/regulated data stored in third-party datacenters must be encrypted prior to arrival (both in-flight and at-rest).
Know Thy Network (or Storage Network)
It is not only a best practice but critical that the SAN is well documented. All assets must be known. All physical and logical interfaces must be known. Create detailed physical and logical diagrams of the SAN. Identify all interfaces on the SAN gear. Many times people overlook the network interfaces for the out-of-band management. Some vendors put a sticker with login and password physically on the server for the out-of-band management ports. Ensure that these are changed. Know what networks can access the SAN and from where. Verify all entry points and exit points for data, especially sensitive data such as financial information or PII. If an auditor asks, it should be simple to point to exactly where that data rests and where it goes on the network.
Use Best Practices for Disaster Recovery and Backup
Guidelines such as the NIST Special Publication 800-346 outline best practices for disaster recovery and backup. The seven steps for contingency planning are outlined below:
1. Develop the contingency planning policy statement. A formal department or agency policy provides the authority and guidance necessary to develop an effective contingency plan.
2. Conduct the business impact analysis (BIA). The BIA helps identify and prioritize critical IT systems and components. A template for developing the BIA is also provided to assist the user.
3. Identify preventive controls. Measures taken to reduce the effects of system disruptions can increase system availability and reduce contingency life-cycle costs.
4. Develop recovery strategies. Thorough recovery strategies ensure that the system may be recovered quickly and effectively following a disruption.
5. Develop an IT contingency plan. The contingency plan should contain detailed guidance and procedures for restoring a damaged system.
6. Plan testing, training, and exercises. Testing the plan identifies planning gaps, whereas training prepares recovery personnel for plan activation; both activities improve plan effectiveness and overall agency preparedness.
7. Plan maintenance. The plan should be a living document that is updated regularly to remain current with system enhancements.
Logical Level Threats, Vulnerabilities, and Risk Mitigation
Aside from the physical risks and issues with SANs, there are also many logical threats. A threat is defined as any potential danger to information or systems. These are the same threats that exist in any network and they are also applicable to a storage network because Windows and Unix servers are used to access and manage the SAN. For this reason, it is important to take a defense-in-depth approach to securing the SAN.
Some of the threats that face a SAN are as follows:
• Internal threats (malicious). A malicious employee could access the sensitive data in a SAN via management interface or poorly secured servers.
• Internal threats (nonmalicious). Not following proper procedure such as using change management could bring down a SAN. A misconfiguration could bring down a SAN. Poor planning for growth could limit your SAN.
• Outside threats. An attacker could access your SAN data or management interface by compromising a management server, a workstation or laptop owned by an engineer, or other server that has access to the SAN.
The following parts of the chapter deal with protecting against these threats.
Begin with a Security Policy
Having a corporate information security policy is essential.7 Companies should already have such policies, and they should be periodically reviewed and updated. If organizations process credit cards for payment and are subject to the Payment Card Industry (PCI)8 standards, they are mandated to have a security policy. Federal agencies subject to certification and accreditation under guidelines such as DIACAP9 must also have security policies.
Is storage covered in the corporate security policy? Some considerations for storage security policies include the following:
Instrument the Network with Security Tools
Many of the network security instrumentation devices such as IDS/IPS have become a commodity, required for compliance and a minimum baseline for any IT network. The problem with many of those tools is that they are signature based and only provide alerts and packet captures on the offending packet alerts. Adding tools such as full packet capture and network anomaly detection systems can allow a corporation to see attacks that are not yet known. They can also find attacks that bypass the IDS/IPSs and help prove to customers and government regulators whether or not the valuable data was actually stolen from the network.
Intrusion Detection and Prevention Systems (IDS/IPS)
Intrusion detection and prevention systems can detect and block attacks on a network. Intrusion prevention systems are usually inline and can block attacks. A few warnings about IPS devices:
Time after time attacks can slip by these systems. They will block the low-hanging fruit, but a sophisticated attacker can trivially bypass IDS/IPS devices. Commercial tools include TippingPoint, Sourcefire, ISS, and Fortinet. Open-source tools include Snort and Bro.
Network Traffic Pattern Behavior Analysis
Intrusion detection systems and vulnerability-scanning systems are only able to detect well-known vulnerabilities. A majority of enterprises have these systems as well as log aggregation systems but are unable to detect 0-day threats and other previously compromised machines. The answer to this problem is NetFlow data. NetFlow data shows all connections into and out of the network. There are commercial and open-source tools. Commercial tools are Arbor Networks and Mazu Networks. Open-source tools include nfdump and Argus.
Full Network Traffic Capture and Replay
Full packet capture tools allow security engineers to record and play back all the traffic on the network. This allows for validation of IDS/IPS alerts and validation of items that NetFlow or log data is showing. Commercial tools include Niksun, NetWitness, and NetScout. Open-source tools include Wireshark and tcpdump.
Secure Network and Management tools
It is important to secure the network and management tools. If physical separation is not possible, then at a very minimum logical separation must occur. For example:
• Separate the management network with a firewall.
• Ensure user space and management interfaces are on different subnets/VLANs.
• Use strong communication protocols such as SSH, SSL, and VPNs to connect to and communicate with the management interfaces.
• Avoid using out-of-band modems if possible. If absolutely necessary, use the callback feature on the modems.
• Have a local technician or datacenter operators connect the line only when remote dial-in access is needed, and then disconnect when done.
Restrict Remote Support
Best practice is to not allow remote support; however, most SANs have a “call home” feature that allows them to call back to the manufacturer for support. Managed network and security services are commonplace. If remote access for vendors is mandatory, take extreme care. Here are some things that can help make access to the SAN safe:
• Disable the remote “call home” feature in the SAN until needed.
• Do not open a port in the firewall and give direct external access to the SAN management station.
• If outsourcing management of a device, ensure that there is a VPN set up and verify that the data is transmitted encrypted.
• On mission-critical systems, do not allow external connections. Have internal engineers connect to the systems and use a tool such as WebEx or GoToAssist to allow the vendor to view while the trusted engineer controls the mouse and keyboard.
Attempt to Minimize User Error
It is not uncommon for a misconfiguration to cause a major outage. Not following proper procedure can cause major problems. Not all compromises are due to malicious behaviors; some may be due to mistakes made by trusted personnel.
Establish Proper Patch Management Procedures
Corporations today are struggling to keep up with all the vulnerabilities and patches for all the platforms they manage. With all the different technologies and operating systems it can be a daunting task. Mission-critical storage management gear and network gear cannot be patched on a whim whenever the administrator feels like it. There are Web sites dedicated to patch management software. Microsoft Windows Software Update Services (WSUS) is a free tool that only works with Windows. Other commercial tools can assist with cross-platform patch management deployment and automation:
• Live within the change window.
• Establish a rollback procedure.
• Test patches in a lab if at all possible. Use virtual servers if possible, to save cost.
• Purchase identical lab gear if possible. Many vendors will sell “nonproduction” lab gear at more than 50% discount. This allows for test scenarios and patching in a nonproduction environment without rolling into production.
• After applying patches or firmware, validate to make sure that the equipment was actually correctly updated.
Use Configuration Management Tools
Many large organizations have invested large amounts of money in network and software configuration management tools to manage hundreds or thousands of devices around the network. These tools store network device and software configurations in a database format and allow for robust configuration management capabilities. An example is HP’s Network Automation System,10 which can do the following:
• Reduce costs by automating time-consuming manual compliance checks and configuration tasks.
• Pass audit and compliance requirements easily with proactive policy enforcement and out-of-the-box audit and compliance reports (IT Infrastructure Library (ITIL), Cardholder Information Security Program (CISP), HIPAA, SOX, GLBA, and others).
• Improve network security by recognizing and fixing security vulnerabilities before they affect the network, using an integrated security alert service.
• Increase network stability and uptime by preventing the inconsistencies and misconfigurations that are at the root of most problems.
• Use process-powered automation to deliver application integrations, which deliver full IT life-cycle workflow automation without scripting.
• Support SNMPv3 and IPv6, including dual-stack IPv4 and IPv6 support. HP Network Automation supports both of these technologies to provide flexibility in your protocol strategy and implementation.
• Use automated software image management to deploy wide-scale image updates quickly with audit and rollback capabilities.
Set Baseline Configurations
If a commercial tool is not available, there are still steps that can be taken. Use templates such as the ones provided by the Center for Internet Security or the National Security Agency. They offer security templates for multiple operating systems, software packages, and network devices. They are free of charge and can be modified to fit the needs of the organization. In addition:
• Create a base configuration for all production devices.
• Check with the vendor to see if they have baseline security guides. Many of them do internally and will provide them on request.
Center for Internet Security11
The Center for Internet Security (CIS) is a not-for-profit organization that helps enterprises reduce the risk of business and ecommerce disruptions resulting from inadequate technical security controls and provides enterprises with resources for measuring information security status and making rational security investment decisions.
National Security Agency12
NSA initiatives in enhancing software security cover both proprietary and open-source software, and we have successfully used both proprietary and open-source models in our research activities. NSA’s work to enhance the security of software is motivated by one simple consideration: Use our resources as efficiently as possible to give NSA’s customers the best possible security options in the most widely employed products. The objective of the NSA research program is to develop technologic advances that can be shared with the software development community through a variety of transfer mechanisms. The NSA does not favor or promote any specific software product or business model. Rather, it promotes enhanced security.
Vulnerability Scanning
PCI requirements include both internal and external vulnerability scanning. An area that is commonly overlooked when performing vulnerability scans is the proprietary devices and appliances that manage the SAN and network. Many of these have Web interfaces and run Web applications on board.
Vulnerability-scanning considerations:
• Use the Change Management/Change Control process to schedule the scans. Even trained security professionals who are good at not causing network problems sometimes cause network problems.
• Know exactly what will be scanned.
• Perform both internal and external vulnerability scans.
• Scan the Web application and appliances that manage the SAN and the network.
• Use more than one tool to scan.
• Document results and define metrics to know whether vulnerabilities are increasing or decreasing.
• Set up a scanning routine and scan regularly with updated tools.
System Hardening
System hardening is an important part of SAN security. Hardening includes all the SAN devices and any machines that connect to it as well as management tools. There are multiple organizations that provide hardening guides for free that can be used as a baseline and modified to fit the needs of the organization:
• Do not use shared accounts. If all engineers use the same account, there is no way to determine who logged in and when.
• Remove manufacturers’ default passwords.
• If supported, use central authentication such as RADIUS.
• Use the principle of least privilege. Do not give all users on the device administrative credentials unless they absolutely need them. A user just working on storage does not need the ability to reconfigure the SAN switch.
Management Tools
It is common for management applications to have vulnerabilities that the vendor will refuse to fix or deny that they are vulnerabilities. They usually surface after a vulnerability scan or penetration test. When vulnerabilities are found, there are steps that can be taken to mitigate the risk:
• Contact the vendor regardless. The vendor needs to know that there are vulnerabilities and they should correct them.
• Verify if they have a hardening guide or any steps that can be taken to mitigate the risk.
• Physically or logically segregate the tools and apply strict ACLs or firewall rules.
• Place it behind an intrusion prevention device.
• Place behind a Web application firewall, if a Web application.
• Audit and log access very closely.
• Set up alerts for logins that occur outside normal hours.
Separate Areas of the SAN
In the world of security, a defense-in-depth strategy is often employed with an objective of aligning the security measures with the risks involved. This means that there must be security controls implemented at each layer that may create an exposure to the SAN system. Most organizations are motivated to protect sensitive (and business/mission-critical) data, which typically represents a small fraction of the total data. This narrow focus on the most important data can be leveraged as the starting point for data classification and a way to prioritize protection activities. The best way to be sure that there is a layered approach to security is to address each aspect of a SAN one by one and determine the best strategy to implement physical, logical, virtual, and access controls.
Physical
Segregating the production of some systems from other system classes is crucial to proper data classification and security. For example, if it is possible to physically segregate the quality assurance data from the research and development data, there is a smaller likelihood of data leakage between departments and therefore out to the rest of the world.
Logical
When a SAN is implemented, segregating storage traffic from normal server traffic is quite important because there is no need for the data to travel on the same switches as your end users browsing the Internet, for example. Logical Unit Numbers (LUN) Masking, Fibre Channel Zoning, and IP VLANs can assist in separating data.
Virtual
One of the most prevalent uses recently for storage area networks is the storing of full-blown virtual machines that run from the SAN itself. With this newest of uses for SANs, the movement of virtual servers from one data store to another is something that is required in many scenarios and one that should be studied to identify potential risks.
Penetration Testing
Penetration testing like vulnerability scanning is becoming a regulatory requirement. Now people can go to jail for losing data and not complying with these regulations. Penetration-testing the SAN may be difficult due to the high cost of entry, as noted earlier. Most people don’t have a SAN in their lab to practice pen testing.
Environments with custom applications and devices can be sensitive to heavy scans and attacks. Inexperienced people could inadvertently bring down critical systems. The security engineers who have experience working in these environments choose tools depending on the environment. They also tread lightly so that critical systems are not brought down. Boutique security firms might not have $100k to purchase a SAN so that their professional services personnel can do penetration tests on SANs. With the lack of skilled SAN technicians currently in the field, it is not likely that SAN engineers will be rapidly moving into the security arena. Depending on the size of the organization, there are things that can be done to facilitate successful penetration testing. An internal penetration testing team does the following:
• Have personnel cross-train and certify on the SAN platform in use.
• Provide the team access to the lab and establish a regular procedure to perform a pen test.
• Have a member of the SAN group as part of the pen-test team.
• Follow practices such as the OWASP guide for Web application testing and the OSSTMM for penetration-testing methodologies.
OWASP
The Open Web Application Security Project (OWASP; www.owasp.org) is a worldwide free and open community focused on improving the security of application software. Our mission is to make application security “visible” so that people and organizations can make informed decisions about application security risks.
OSSTMM
The Open Source Security Testing Methodology Manual (OSSTMM; www.isecom.org/osstmm/) is a peer-reviewed methodology for performing security tests and metrics. The OSSTMM test cases are divided into five channels (sections), which collectively test information and data controls, personnel security awareness levels, fraud and social engineering control levels, computer and telecommunications networks, wireless devices, mobile devices, physical security access controls, security processes, and physical locations such as buildings, perimeters, and military bases. The external penetration testing team does the following:
• Validates SAN testing experience through references and certification
• Avoids firms that do not have access to SAN storage gear
• Asks to see a sanitized report of a previous penetration test that included a SAN
Whether an internal or external penetration-testing group, it is a good idea to belong to one of the professional security associations in the area, such as the Information Systems Security Association (ISSA) or Information Systems Audit and Control Association (ISACA).
ISSA
ISSA (www.issa.org) is a not-for-profit, international organization of information security professionals and practitioners. It provides educational forums, publications, and peer interaction opportunities that enhance the knowledge, skill, and professional growth of its members.
ISACA
ISACA (www.isaca.org) got its start in 1967 when a small group of individuals with similar jobs—auditing controls in the computer systems that were becoming increasingly critical to the operations of their organizations—sat down to discuss the need for a centralized source of information and guidance in the field. In 1969 the group formalized, incorporating as the EDP Auditors Association. In 1976 the association formed an education foundation to undertake large-scale research efforts to expand the knowledge and value of the IT governance and control field.
Encryption
Encryption is the conversion of data into a form called ciphertext that cannot be easily understood by unauthorized people. Decryption is the process of converting encrypted data back into its original form so that it can be understood.
Confidentiality
Confidentiality is the property whereby information is not disclosed to unauthorized parties. Secrecy is a term that is often used synonymously with confidentiality. Confidentiality is achieved using encryption to render the information unintelligible except by authorized entities.
The information may become intelligible again by using decryption. For encryption to provide confidentiality, the cryptographic algorithm and mode of operation must be designed and implemented so that an unauthorized party cannot determine the secret or private keys associated with the encryption or be able to derive the plaintext directly without deriving any keys.13
Data encryption can save a company time, money, and embarrassment. There are countless examples of lost and stolen media, especially hard drives and tape drives. A misplacement or theft can cause major headaches for an organization. Take, for example, the University of Miami14:
A private off-site storage company used by the University of Miami has notified the University that a container carrying computer back-up tapes of patient information was stolen. The tapes were in a transport case that was stolen from a vehicle contracted by the storage company on March 17 in downtown Coral Gables, the company reported. Law enforcement is investigating the incident as one of a series of petty thefts in the area.
Shortly after learning of the incident, the University determined it would be unlikely that a thief would be able to access the back-up tapes because of the complex and proprietary format in which they were written. Even so, the University engaged leading computer security experts at Terremark Worldwide15 to independently ascertain the feasibility of accessing and extracting data from a similar set of back-up tapes.
Anyone who has been a patient of a University of Miami physician or visited a UM facility since January 1, 1999, is likely included on the tapes. The data included names, addresses, Social Security numbers, or health information. The University will be notifying by mail the 47,000 patients whose data may have included credit card or other financial information regarding bill payment.
Even thought it was unlikely that the person who stole the tapes had access to the data or could read the data, the university still had to notify 47,000 people that their data may have been compromised. Had the tape drives been encrypted, they would not have been in the news at all and no one would have had to worry about personal data being compromised.
Deciding What to Encrypt
Deciding what type of data to encrypt and how best to do it can be a challenge. It depends on the type of data that is stored on the SAN. Encrypt backup tapes as well.
There are two main types of encryption to focus on: data in transit and data at rest. SNIA put out a white paper called Encryption of Data At-Rest: Step-by-Step Checklist, which outlines nine steps for encrypting data at rest:16
1. Understand confidentiality drivers.
4. Perform data flow analysis.
5. Determine the appropriate points of encryption.
Many of the vendors implement encryption in different ways. NIST SP 800-57 contains best practices for key management and information about various cryptographic ciphers.
The following are the recommended minimum symmetric security levels, defined as bits of strength (not key size):
Type of Encryption to Use
The type of encryption used should contain a strong algorithm and be publicly known. Algorithms such as ASE, RSA, SHA, and Twofish are known and tested. All the aforementioned encryption algorithms have been tested and proven to be strong if properly implemented. Organizations should be wary of vendors saying that they have their own “unknown” encryption algorithm. Many times it is just data compression or a weak algorithm that the vendor wrote by itself. Though it sounds good in theory, the thousands of mathematicians employed by the NSA spend years and loads of computer power trying to break well-known encryption algorithms.
Proving That Data Is Encrypted
A well-architected encryption plan should be transparent to the end user of the data. The only way to know for sure that the data is encrypted is to verify the data. Data at rest can be verified using forensic tools such as dd for Unix or the free FTK17 imager for Windows. Data in transit can be verified by network monitoring tools such as Wireshark.
Turn on event logging for any encryption hardware or software. Make sure it is logging when it turns on or off. Have a documented way to verify that the encryption was turned on while it had the sensitive data on the system (see Figure 34.2).
Figure 34.2 Notice the clear, legible text on the right.
Encryption Challenges and Other Issues
No method of defense is perfect. Human error and computer vulnerabilities do pose encryption challenges (see Figure 34.3). A large financial firm had personal information on its network, including 34,000 credit cards with names and account numbers. The network administrator had left the decryption key on the server. After targeting the server for a year and a half, the attacker was able to get the decryption key and finally able to directly query the fully encrypted database and pull out 34,000 cards.
Figure 34.3 Notice Encrypted Data on the right-hand side.
Logging
Logging is an important consideration when it comes to SAN security. There are all sorts of events that can be logged. When a security incident happens, having proper log information can mean the difference between solving the problem and not knowing whether your data was compromised. NIST has an excellent guide to Security Log Management. The SANS Institute has a guide on the top five most essential log reports.
There are multiple commercial vendors as well as open-source products for log management. Log management has evolved from standalone syslog servers to complex architectures for Security Event/Information Management. Acronyms used for these blend together as SEM, SIM, and SEIM. In addition to log data, they can take in data from IDSs, vulnerability assessment products, and many other security tools to centralize and speed up the analysis and processing of huge amounts of logs. More of a difference is being made between Security Event Management and audit logging. The former is geared toward looking at events of interest on which to take action; the latter is geared to compliance. In today’s legal and compliance environment an auditor will ask an enterprise to immediately provide logs for a particular device for a time period such as the previous 90 days. With a solid log management infrastructure, this request becomes trivial and a powerful tool to help solve problems. NIST Special Publication 800-9218 makes the following recommendations:
• Organizations should establish policies and procedures for log management.
• Organizations should prioritize log management appropriately throughout the organization.
• Organizations should create and maintain a log management infrastructure.
• Organizations should provide proper support for all staff with log management responsibilities.
• Organizations should establish standard log management operational processes.
Policies and Procedures
To establish and maintain successful log management activities, an organization should develop standard processes for performing log management. As part of the planning process, an organization should define its logging requirements and goals.
Prioritize Log Management
After an organization defines its requirements and goals for the log management process, it should then prioritize the requirements and goals based on the organization’s perceived reduction of risk and the expected time and resources needed to perform log management functions.
Create and Maintain a Log Management Infrastructure
A log management infrastructure consists of the hardware, software, networks, and media used to generate, transmit, store, analyze, and dispose of log data. Log management infrastructures typically perform several functions that support the analysis and security of log data.
Provide Support for Staff With Log Management Responsibilities
To ensure that log management for individual systems is performed effectively throughout the organization, the administrators of those systems should receive adequate support.
Establish a Log Management Operational Process
The major log management operational processes typically include configuring log sources, performing log analysis, initiating responses to identified events, and managing long-term storage.
What Events Should Be Logged for SANs?
For storage networks the same type of data should be collected as for other network devices, with focus on the storage management systems and any infrastructure that supports the SAN, such as the switches and servers. According to the SANS Institute, the top five most essential log reports19 are as follows.
Attempts to Gain Access Through Existing Accounts
Failed authentication attempts can be an indication of a malicious user or process attempting to gain network access by performing password guessing. It can also be an indication that a local user account is attempting to gain a higher level of permissions to a system.
Failed File or Resource Access Attempts
Failed file or resource access attempts is a broad category that can impact many different job descriptions. In short, failed access attempts are an indication that someone is attempting to gain access to either a nonexistent resource or a resource to which they have not been granted the correct permissions.
Unauthorized Changes to Users, Groups and Services
The modification of user and group accounts, as well as system services, can be an indication that a system has become compromised. Clearly, modifications to all three will occur legitimately in an evolving network, but they warrant special attention because they can be a final indication that all other defenses have been breached and an intrusion has occurred.
Systems Most Vulnerable to Attack
As indicated in the original SANS Top 10 Critical Vulnerabilities list as well as the current Top 20, one of the most important steps you can take in securing your network is to stay up to date on patches. In an ideal world all systems would remain completely up to date on the latest patches; time management, legacy software, availability of resources, and so on can result in a less than ideal posture. A report that identifies the level of compliance of each network resource can be extremely helpful in setting priorities.
Suspicious or Unauthorized Network Traffic Patterns
Suspect traffic patterns can be described as unusual or unexpected traffic patterns on the local network. This not only includes traffic entering the local network but traffic leaving the network as well. This report option requires a certain level of familiarity with what is “normal” for the local network. With this in mind, administrators need to be knowledgeable of local traffic patterns to make the best use of these reports. With that said, there are some typical traffic patterns that can be considered to be highly suspect in nearly all environments.
6. Conclusion
The financial and IT resource benefits of consolidating information into a storage area network are compelling, and our dependence on this technology will continue to grow as our data storage needs grow exponentially. With this concentration and consolidation of critical information come security challenges and risks that must be recognized and appropriately addressed. In this chapter we covered these risks as well as the controls and processes that should be employed to protect the information stored on a SAN. Finally, we have emphasized why encryption of data at rest and in flight is a critical protection method that must be employed by the professional SAN administrator. Our intention is for you to understand all these risks to your SAN and to use the methods and controls described here to prevent you or your company from becoming a data loss statistic.
1The Enterprise Cloud by Terremark, www.theenterprisecloud.com.
2Storage Network Industry Association, www.snia.org/home.
3SAN justifications: http://voicendata.ciol.com/content/enterprise_zone/105041303.asp.
4Gartner, www.gartner.com.
5Data Loss Database, http://datalossdb.org/.
6NIST Special Publication 800-34, http://csrc.nist.gov/publications/nistpubs/800-34/sp800-34.pdf.
7Information Security Policy Made Easy, www.informationshield.com/.
8PCI Security Standards, https://www.pcisecuritystandards.org/.
9DIACAP Certification and Accreditation standard, http://iase.disa.mil/ditscap/ditscap-to-diacap.html.
10HP Network Automation System, https://h10078.www1.hp.com/cda/hpms/display/main/hpms_content.jsp?zn=bto&cp=1-11-271-273_4000_100__.
11Center for Internet Security, www.cisecurity.org.
12National Security Agency security templates, www.nsa.gov/snac/index.cfm.
13NIST Special Publication 800-57, Recommendation for Key Management Part 1, http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf.
14Data Loss Notification from the University of Miami, www6.miami.edu/dataincident/index.htm.
15Terremark Worldwide, www.terremark.com
16www.snia.org/forums/ssif/knowledge_center/white_papers.
17Access Data Forensic Toolkit Imager, www.accessdata.com/downloads.html.
18NIST SP 800-92 http://csrc.nist.gov/publications/nistpubs/800-92/SP800-92.pdf.
19SANS Institute, www.sans.org/free_resources.php.