Stopping the Next Heist

Storage and backup systems are rife with vulnerabilities. Take seven steps to secure them, or risk unflattering headlines and legal problems.


Storage and backup systems are rife with vulnerabilities. Take seven steps to secure them, or risk unflattering...

headlines and legal problems.

From the ChoicePoint fiasco to the CardSystems debacle, data security breaches make news all the time. Rarely does a week go by without a report of another incident of credit card accounts exposed, personal information stolen, or backup tapes disappearing. Universities, banks, government agencies and even security software companies all have been in the unfortunate spotlight after a breach. The Privacy Rights Clearinghouse tallied nearly 100 breaches between February and December last year.

Not only have storage networks created another attack point, but storage networks, networked backup and recovery systems are some of the most direct routes to your information. Why hack a server when you can go around it to get to the data? Storage systems aren't just a target-- they're a big, juicy target for a heist.

A big reason for the concern and why we're hearing about all these security problems is due to laws--such as SB 1386--that require the reporting of the loss of control over personal information. These stringent security reporting requirements, coupled with the lack of security behind most storage and backup systems, make the storage administration division of your IT department the most likely group to get your com-pany the kind of media attention it doesn't want.

But you can protect your data if you understand vulnerabilities common to many storage and backup systems, know what technologies are available to help plug those holes, and take the appropriate steps to keep your company's information safe.

Step 1:
Train storage personnel
Your first step to storage security may be convincing storage administrators that security is part of their responsibility. Network administrators understand that they can't build a network without putting in a firewall, and UNIX system administrators know to disable Telnet and FTP access to every server. However, your storage personnel may not be aware that security is as essential to their job as backups. They know to make frequent backups, and they know how to setup a RAID array, but they might not know how to protect that backup or their disk array from hackers--or that it's their job to do so.

This isn't a criticism of storage administrators. It's simply the nature of an industry that is still cutting its teeth. The concept of a dedicated storage or backup system administrator is less than 10 years old, and even some of the largest companies still don't have dedicated storage personnel. In addition, the connectivity, reliability and performance problems of many storage and backup systems put storage personnel in firefighting mode. They don't have time to learn about security; they're doing everything they can to keep the ship afloat.

Step 2:
Identify regulations that could affect you
Laws like SB 1386--and the breaches they make public--are forcing organizations to address these storage security loopholes. SB 1386 requires companies that do business with customers in California to notify those customers if the company has lost control of their personal identity information, such as a Social Security or credit card number. If you've got evidence of someone hacking into your network and accessing personal information, or you've lost control of a plaintext backup tape with personal information on it, you're required by that law to notify California customers. If you're not able to notify them "within a reasonable time," you have to notify the media and post a notice on your company's Web site. At least 17 other states have established similar laws, and there are some federal laws in the works.

In addition to laws governing personal identity information, there are a number of regulations requiring proper maintenance of other types of information, such as medical records and financial transactions. While the details vary, all of these regulations have common traits. Generally, you must be able to do the following:

  • Access the information for a certain period of time, even in case of disaster or other loss.
  • Verify that the information was not modified.
  • Ensure that only authorized personnel had access to the information.
Thus, companies subject to regulations such as HIPAA and SOX must ensure that their data is maintained in a compliant manner. In short, that means your backups must work, and your external and internal security protections must not be compromised. Noncompliance can result in huge penalties and public exposure. Depending on the size of the company and the type of incident, the fines can be in the millions of dollars.

Safeguarding Archive Data
Before discussing the security of archive data, let's define the term "archive." We're talking about an electronic filing cabinet that is specifically designed for logical retrieval of information, based on its context. The context might include the creator of the data, its purpose or what project it's attached to, but rarely has anything to do with where the data was stored. When looking for a file in a filing cabinet, you don't ask for the third folder in the fifth drawer of the fourth cabinet. You say, "Get me the Jansen file."

In comparison, a backup system is designed to restore damaged or deleted data based on where it was stored. It's used when the file cabinet catches fire, or when the Jansen file disappears. But you don't restore the Jansen file, you restore the third folder in the fifth drawer of the fourth cabinet--you must know the location of the file to restore it. However, if you ask the archive system to restore a file that was deleted yesterday, it would ask you who created it, or what the file is about.

Now that we've got our definitions straight, we can move on to the security issues. Disks or tapes for the archive system may be saved for many years, and, like the backup system, the archive system contains very valuable information. So shouldn't we encrypt its tapes as well? We probably will soon, but we have to be careful.

With a backup tape that's going to expire and be overwritten in a few months, we can afford to have format changes with the encryption system. With an archive system, we've got to be able to read these tapes for many years. The problem is that all of the current encryption systems are incompatible. If your encryption vendor went out of business, you'd have no backup plan for your long-term archives. If the day comes when you can switch vendors and still read your tapes, encryption of archives will make more sense. For now, it's probably safest to simply follow very strong physical security practices to ensure that you don't lose control of any tapes.

--W. Curtis Preston
Step 3:
Educate administrators about storage vulnerabilities
Once you've awakened your storage administrators to the need for security, you need to educate them about the concepts of authentication and authorization, as well as the evils of plaintext communication. Then, help them understand the vulnerabilities in their storage systems:
  • Plaintext out-of-band management interfaces
  • Plaintext in-band communication
  • Hostname-based authentication for the UNIX network file system (NFS) and Windows Common Internet File System (CIFS)
  • Plaintext authentication for NFS/CIFS
  • World Wide Name-based authentication
  • Soft-zoning
  • Plaintext backup tapes
  • Hostname-based authentication for backup servers
  • Admin-based authentication for backup admins
In a storage network, we refer to communications within the network as in-band (such as a host requesting data from a storage device), and communications outside the network as out-of-band (someone managing a storage device via its IP management port). Historically, all of this communication has been in plaintext. If someone can view in-band traffic, they might be able to read data they're not supposed to, or learn something that might assist in an attack. If they can view out-of-band management information, they could take control over the storage network and give themselves access to information, or conduct DoS attacks.

Step 4:
Implement encryption solutions
The key to solving both of these problems is encryption. For out-of-band communication, more and more storage vendors are supporting secure communication protocols, such as SSH or HTTPS, on their management ports. For in-band support, there are host-based encryption systems and hardware encryption appliances. Only host-based encryption can encrypt data from the point of departure, but encryption software is very CPU-intensive. This can slow the transfer of data by as much as 50 percent. The other in-band choice is an encryption appliance that can go in the storage network and encrypt data as it's stored on the device, preventing readability even if a hacker is able to gain physical access.

Another vulnerability has to do with NFS and CIFS, which allow the sharing of files between multiple servers. This is collectively referred to as Network Attached Storage (NAS). A major challenge with NFS and CIFS is their simple host-based authentication mechanisms. If your IP address resolves to the appropriate hostname, you are given access to the shared directory. In addition, much of the authentication mechanism is sent in plaintext, telling a hacker exactly what addresses he or she needs to spoof.

Also vulnerable to spoofing are World Wide Names (WWNs) in a storage area network (SAN). WWNs are the Fibre Channel equivalent to MAC addresses. The ability to change the WWN is built right into the driver. Therefore, the common practice of WWN-based authentication is easy to defeat.

The same host-based encryption software and appliances described above can help tackle these authentication issues surrounding WWNs and NFS/ CIFS. Two pieces of software--one running on the appliance and one running on the server to be authenticated--pass encrypted authentication information between each other to verify each other's identity. Someone simply spoofing the secure host's WWN wouldn't have this additional information. A recent advancement in Fibre Channel switches can also improve WWN-based authentication--the concept of port binding, where a WWN is bound to a particular port and is only granted access if it's seen at that port.

Step 5:
Turn off soft-zoning
But there's another authentication problem in Fibre Channel SANs--the use of soft-zoning. A zone is the Fibre Channel equivalent of a VLAN, with some differences. With hard-zoning, only members of a zone can access the devices in that zone. With soft-zoning, you can communicate with a device if you have its WWN, which is relatively easy to determine. While the solution to this seems simple--turn off soft-zoning--it hasn't been that easy. Usually, soft-zoning goes hand in hand with WWN-based authentication, and many people use WWN-based authentication to make easy changes. Today's switches let you pick and choose which authentication and zoning methods you want to use. The most secure combination, of course, would be hard-zoning with port-binding-based authentication.

Step 6:
Encrypt backup systems
Finally, let's talk about backups. Backup systems' most obvious security flaw is the plaintext backup tape. There are many encryption options for protecting this media, including host-based file system and application encryption, encryption in the backup software, and a number of appliances that sit in the hardware data path and encrypt the data as it's written to tape.

These hardware appliances are expensive, but they are much easier to implement and maintain than the other options. In addition to encrypting at line speed and providing superior key management, they also support compression. Since encrypted data can't be compressed, some have a compression chip that compresses the data before it's encrypted. This gives these appliances a major advantage over the other solutions--application encryption and backup encryption--since their en-crypted data will not be compressed by the tape drive.

Step 7:
Boost backup authentication and authorization
Another security issue with backup systems is that they have typically used hostname-based authentication to check the backup server and client against each other. A hacker with a spoofed IP address could do two things to exploit this vulnerability: First, the attacker could create a rogue backup client and ask the server to restore data for the real client, thus stealing the information. A rogue client could also populate the backup server with bogus versions of backed-up files. Second, a malicious hacker could create a rogue backup server and back up any client authorized by the server. This, of course, would be a perfect way to steal all kinds of data. Some backup products have addressed this serious vulnerability with additional levels of authentication beyond the hostname. Unfortunately, the added complexity of such authentication systems has made them less than attractive to backup administrators.

Finally, backup systems have taken an "all or nothing" approach to administrative authorization. For example, by giving a new administrator the ability to eject tapes from the library, you also give them the ability to delete or change every backup policy, delete all backup history and overwrite every tape you own with garbage. This presents the possibility of a novice administrator pushing the wrong button and accidentally erasing all the tapes in your tape library. (A healthcare company actually had this happen a few years ago.) Some backup software products have begun resolving this problem by introducing role-based administration, so you can give each person only the capabilities needed to do their job.

The introduction of role-based administration in backup software, along with other functionalities to secure stored data, shows that storage vendors are waking up to the importance of security. If your products don't support this kind of secure functionality, you need to pressure your vendors to see that they do--it's critical for protecting your most precious data from thieves.

This was first published in February 2006

Dig Deeper on Enterprise Data Governance






Forgot Password?


Your password has been sent to: