CHAPTER 36

SECURING STORED DATA

David J. Johnson, Nicholas Takacs, and Jennifer Hadley

36.1 INTRODUCTION TO SECURING STORED DATA

36.1.1 Security Basics for Storage Administrators

36.1.2 Best Practices

36.1.3 DAS, NAS, and SAN

36.1.4 Out-of-Band and In-Band Storage Management

36.1.5 File System Access Controls

36.1.6 Backup and Restore System Controls

36.1.7 Protecting Management Interfaces

36.2 FIBER CHANNEL WEAKNESS AND EXPLOITS

36.2.1 Man-in-the-Middle Attacks

36.2.2 Session Hijacking

36.2.3 Name Server Corruption

36.2.4 Fiber Channel Security

36.3 NFS WEAKNESS AND EXPLOITS

36.3.1 User and File Permissions

36.3.2 Trusted Hosts

36.3.3 Buffer Overflows

36.3.4 NFS Security

36.4 CIFS EXPLOITS

36.4.1 Authentication

36.4.2 Rogue or Counterfeit Hosts

36.5 ENCRYPTION

36.5.1 Recoverability

36.5.2 File Encryption

36.5.3 Volume Encryption and Encrypted File Systems

36.5.4 Full Disk Encryption

36.5.5 Vulnerability of Volume, File System, and Full Disk Encryption

36.5.6 Database Encryption

36.6 DATA DISPOSAL

36.7 CONCLUDING REMARKS

36.8 FURTHER READING

36.9 NOTES

36.1 INTRODUCTION TO SECURING STORED DATA.

This chapter reviews methods of securing data stored on nonvolatile media. Nonvolatile media include magnetic disks and their (hard) drives, compact discs (CDs), and digital video disks (DVDs) with their optical drives, and flash drives (also known as USB drives, flash disks, and memory keys). Volatile storage devices, which are not covered in this chapter, include random access memory (RAM) and other storage that loses its contents with a power loss.

36.1.1 Security Basics for Storage Administrators.

Storage systems have developed outside the security umbrella of other organizational assets. Because the storage arena is one of the most strategic parts of the infrastructure, professionals should take the same care in developing comprehensive security controls as those that are addressed for the remainder of the network. A number of vendors have focused on the development of secure storage environments that are scalable yet flexible; most address both the logical and physical aspects of security. However, any appropriate strategy for data storage protection includes a balance between protecting the confidentiality and integrity of the information while also ensuring its availability and utility to the system and to authorized users. Ultimately, those with a responsibility for data storage will also be tasked with maintaining this balance at a reasonable cost.

Knowing how and where data will be stored on a network, and addressing the identified risks to the data, is often a better and more efficient option in terms of resource usage (time and money) than applying the highest level of protection to all data. For example, unreleased earnings statements may have a higher impact to a company if disclosed than a job posting that ran in newspapers months before. An organization need not be a high-profile entity to suffer from a compromised pool of data. A single backup tape can contain enough concentrated personal or sensitive corporate information to experience a loss of credibility, lost revenue, and might even bring the organization to its knees. Worse, a backup that is copied illicitly may show no signs of having led to loss of control over confidential data.

36.1.2 Best Practices.

Every organization must keep its applications, servers, and end user systems up and running to make use of information and to maintain the highest degree of information availability and integrity. A tiered data protection model works best; it includes a layered defense, due diligence, and restricted management. Implemented correctly, security should be transparent. Best practices for providing a secure data storage environment include:

• Performing an audit and risk assessment on the storage infrastructure, looking for risks and vulnerabilities.
• Implementing authentication across the storage network that could coordinate authorization, password maintenance, and encryption.
• Implementing strong role-based access controls and assigning access rights to parties on a need-to-know basis.
• Adopting and enforcing data encryption and data classification policies. Based on the classification level assigned to the data, the organization's policy may require the encryption of the data at rest throughout the life cycle of the data. There may also be requirements to encrypt the data “in flight” (across the network) as well.
• Requiring strong security features and practices from storage system vendors and off-site storage providers.
• Remembering to secure the storage area network (SAN) at the switch (or fabric) level. Carving up the fabric by zones is one technique that limits access to various parts of the SAN.
• Creating a policy for discarding old devices and media, to include routinely performing tasks such as scrubbing and destroying all data storage devices and media.
• Evaluating retention policies and organizational or government regulatory issues.
• Isolating the storage management network from the organization's primary network. By not isolating the network, every employee potentially has access to the stored data.
• Establishing access log monitoring.
• Performing employee and contractor background checks as part of the human resources (HR) hiring procedures.
• Investigating physical controls in the organization to restricted access to data centers, locking storage cabinets and server racks, using locks built into some servers, and ensuring the reliability of the perimeter and building(s).
• Treating backups as an “orange alert” or heightened alarm process. Adopting secure media management tracking and handling policies that include backup requirements for financial information, employee data, and intellectual property.¹ Chapter 57 in this Handbook contains much information about data backup.

36.1.3 DAS, NAS, and SAN.

There are three primary methods for storing data: direct attached storage (DAS), network attached storage (NAS), and storage area networks (SANs).

Direct attached storage drives are those that are connected directly to the computer. DAS can either be internal, contained within the computer's case, or external and attached via a Peripheral Component Interconnect (PCI), or other bus channel. The risks to DAS devices are either their physical theft or access through the computer system that they service.

Network attached storage devices are specialized servers that run minimized operating systems and file systems designed specifically to support input/output (I/O) from other servers. The servers that attach to the NAS devices have DAS that contains their operating systems, applications, and other components but, normally, write all data to the NAS device via Transmission Control Protocol/Internet Protocol (TCP/IP) over Ethernet connections. NAS is utilized via file sharing protocol such as Network File System (NFS) for UNIX systems and Server Message Block (SMB) or Common Internet File System (CIFS) for Microsoft systems. (As CIFS grew out of SMB, the two are often listed as SMB/CIFS or CIFS/SMB.) As with any Ethernet connection, connections between a system and the NAS server that it uses are subject to being sniffed, to eavesdropping, and to packet capture. NFS and CIFS threats are discussed later in this chapter.

Storage area networks are collections of centralized disks that can be accessed by numerous servers. Using SANs can facilitate company growth, as most SANs options allow additional disks to be added to the pool as data storage needs increase, without having to take the attached systems off-line, as would need to occur if new DAS were being added to individual systems. Data backups can also be easier to control, as a single storage resource could potentially be backed up instead of each individual system. With the implementation of Redundant Array of Inexpensive (or Independant) Drive (RAID) or other disk redundancy techniques, writing data to multiple disks can be accomplished without impacting the application servers' performance. Such redundancy techniques can help to assure the availability of data stored on disks in the event that a disk crashes or otherwise becomes unusable. Systems can be attached to the SAN by various methods including TCP/IP and fiber channels. Fiber channels are discussed later in this chapter. Using IP for SANs connections enables servers to connect over the Internet—but this option must be used with caution, due to the security concerns of transferring data over the Internet.

36.1.4 Out-of-Band and In-Band Storage Management.

Managers may have to control storage locations remotely, that is, from a location other than a directly attached console. There are two approaches to such control communications, each with its own particular security issues:

1. In-band management uses the same network as the data transfers.
2. Out-of-band management uses a separate network.²

While in-band storage management uses the same channels as the data itself traverses for storage, out-of-band management uses alternative methods. For example, an out-of-band solution might have a storage administrator working from a desk and connecting to the storage system over the primary network used by all employees, while the data traverses a dedicated channel between the application server and the storage system.

With out-of-band management, consideration must be given to how to ensure that only authorized systems, such as the administrator's, are connecting to the storage system. This is especially necessary if the storage system does not require authenticated connections being established before a command is accepted. Without authentication, any system able to communicate with the storage system could issue commands that would negatively impact the storage system. Another risk is due to the interface used by management communications and the commands being sent across the wire without being encryption. For storage systems that are managed by HTTP interfaces by default, it may be possible to use HTTPS instead, in order to mitigate the risk of commands and logins being exposed and/or compromised due to network packet capture.

In-band management also has concerns. Commands sent in-band are normally sent in clear-text. Other threats of in-band storage management include:³

• Management interfaces being subjected to denial-of-service (DoS) attacks
• Commands providing information on other devices and controllers
• Set and reset commands being issued inappropriately

36.1.5 File System Access Controls.

File systems provide access control to data. UNIX file systems provide controls based on the user owner, the group owner, and “other,” or those that are not the user or a member of the group that owns the data. Microsoft Windows systems allow for data owners to be specified and access granted by either individual usernames or group accounts. Access control lists (ACLs) can also be used to provide access exceptions to the normal access permissions of the data files.

When correctly applied, these access controls can be effective in preventing unauthorized access to data through normal usage. However, the file system trusts that the computer's operating system access controls have correctly authenticated and authorized the user. If the access controls for the operating system are circumvented, then file system access controls lose their effectiveness.

For more details of operating system and local area network access controls, see Chapters 24 and 25 in this Handbook.

36.1.6 Backup and Restore System Controls.

Systems used for the backup and restoration of data need extra security consideration because the data contained on them are often critical to disaster recovery and business continuity. There are several threats to backup data that are not faced by attacks against other data stores. Although most systems only have their data stored on disk (DAS, NAS, or SAN), backup systems often write data to tapes or other removable media specifically intended for off-site storage. Another option is to back up data electronically to a remote system, either at another of the organization's data centers or with an off-site backup vendor. As with any transmission of data to remote facilities, the data must be protected during transit and at the destination facility.

Regardless of the media used, all data backups need to be stored at a secure, environmentally protected facility sufficiently distant from the originating location to mitigate the risk of losing both primary and backup data from a single major event, such as an earthquake, flood, or volcanic eruption. Additionally, the backup media storage needs to be secured by restricting access to authorized personnel only. Media used for backups needs to be evaluated to ensure that they meet or exceed the longevity needs of the data, as defined by the organization's backup policies and standards.

Additional risk from system imitation also needs to be considered. If an attacker is able to insert a system that impersonates a backup system, all of the data intended to be backed up may instead be written directly to the attacker's system. Conversely, if an attacker is able to insert a system that can masquerade as one or more data storage systems, then the attacker could request a restoration of data from existing backups, gaining unauthorized access to the information.

To mitigate such risks, interactions between data storage systems and backup systems should be authenticated. For manually controlled backups, systems could have backup accounts created that require an interactive login to authenticate the backup request. For automated backups, other options may be available, including the use of client and server certificates to authenticate both systems involved in the backup connection.

Off-site storage of data, whether written directly to a storage vendor's server or to removable media such as tape, deserves its own security considerations. For example, how does the vendor secure physical access to its site? How does it vet its employees? Most risks such as these can be mitigated by performing due diligence of the vendor prior to entering a contract and by eliminating prospective vendors that do not meet the organization's security needs.

Another mitigation strategy is to encrypt data backups before they are sent off-site. Many backup applications offer encryption methods. The use of encryption for files and other data storage systems is discussed later in Section 36.5 of this chapter. Similar techniques can be applied to backup data by encrypting it as it is written to the backup media.

For more details of backup strategies and security, see Chapter 57 in this Handbook.

36.1.7 Protecting Management Interfaces.

Management interfaces pose one of the greatest threats to the security of stored data. These interfaces provide administrative access to the data stores, allowing individuals with appropriate access the ability to manipulate data elements, update account security, and perform other housekeeping activities. Therefore, care is required when implementing a storage solution to ensure that a well-defined defense in depth exists. Although two-factor authentication is more secure, it is not always practical. At a bare minimum, each administrative user should have a set of credentials, and complex password requirements, with a regular password change frequency. In addition, the individuals responsible for administering security should not be the same individuals responsible for managing the storage environment. This separation of duties limits the ability of any one individual to circumvent security controls, without some type of conspiracy between the storage and security administrators.

Another important component of the defense-in-depth strategy involves the use of audit logs. Logging should be enabled to detect violations of policy and of prescribed procedures. However, logs are valueless unless subjected to regular and random review, with follow-up if anomalies are detected. It is unrealistic to expect an individual to pore over voluminous log files on a daily basis. However, log aggregation and correlation technology can be employed to provide an additional layer of confidence as anomalous activity across systems can be related—potentially identifying an attack pattern or other irregular activity that would not be apparent from a single log. Regardless of the final implementation, the use of audit logs, and restrictions on the ability to access and modify those logs, plays an important part in guaranteeing that no data corruption occurred.

Mitigating these risks to the management interface requires careful monitoring and control of who can access and install these interfaces. With the movement to Web-based interfaces, this discussion comes down to strict user access control and authentication. In any case, it is imperative that only trusted users with aneed to know be allowed access to the management interface. Once inside, individuals can manipulate the environment as needed to support their goals, whether to further organizational objectives or to perform malicious actions.

36.2 FIBER CHANNEL WEAKNESS AND EXPLOITS.

Fiber channels, while very economical, present unique challenges to the storage environment. The term “fiber channel” refers to more than just a fiber-based communication pathway, but rather a complex communication protocol. There are a number of inherent weaknesses in the technology, some of which are fairly straightforward and manageable, while others introduce questions of the viability of the technology in larger storage environments.

One of the most serious security weaknesses with a fiber channel is that all communications occur in clear-text. Fortunately, when fiber channel implementations occur completely within a data center or other secured area, this is not a major concern, as the ability of unauthorized individuals to intercept traffic on the “wire” is limited. However, fiber channel does not natively support authentication or data integrity checking, leaving the potential for unauthorized tampering.

From a vulnerability perspective, attackers can use the Internet Protocol (IP) to craft exploits against fiber channel, since both protocols use a frame-based communication scheme. Unfortunately, based on the clear-text issue just discussed, an attacker could sniff frames off the fiber channel connection and gain information needed to craft an attack. This section focuses on three types of common attacks: man in the middle, session hijacking, and name server corruption. It is important to note that most attacks on a storage network require physical access to that environment or access to the appropriate sniffing hardware, which increases the overall complexity of the attack.

36.2.1 Man-in-the-Middle Attacks.

Man-in-the-middle attacks take advantage of weaknesses in the frame-based communications that fiber channel employs. Similar to IP-based attacks, man-in-the-middle attacks involve an attacker intercepting communications, stealing or changing data, and passing that frame on to the intended destination. Fiber channel includes a sequence ID and sequence count, both intended to ensure consistent communication from sender to receiver. Much like IP, the sequence count is a very predictable, sequential number, allowing an attacker to anticipate the next sequence number and forward a packet ahead of the sending system. This allows the attacker to intercept the stream without the authorization of either party. Mitigating this issue requires data integrity checking to guarantee reception of the correct information.

36.2.2 Session Hijacking.

Session hijacking presents the same type of problem as man-in-the-middle attacks and occurs in much the same way. However, this type of attack focuses on the lack of authentication in fiber channel environments. Instead of the attacker manipulating data in each frame and passing it on, knowledge of the sequence ID and sequence count is used to intercept and control the session, making the recipient believe that the attacker is really the original sender. The newly controlled session can then be used to extract whatever data or other information the attacker wishes. Mitigating this issue requires strong authentication to provide a guarantee that the original sender is still the same system throughout the length of the connection.

36.2.3 Name Server Corruption.

The last type of attack in this section involves address spoofing, similar to DNS spoofing in the IP world. Each fiber channel connection registers its name with World Wide Name (WWN) service, through two processes, a Fabric Login (FLOGI) and a Port Login (PLOGI). Typically, name server corruption occurs during the PLOGI process, by allowing an incorrect host to register itself with the fiber channel switch (which contains the WWN service) using a spoofed address. The switch would register that host under that address as if it were valid, due to the lack of any host authentication. When the real host tries to connect, the switch would deny that connection, because the incorrect host is already connected. This type of attack requires some timing on the attacker's part but can be easy to accomplish due to the weaknesses previously discussed.

36.2.4 Fiber Channel Security.

This short examination of fiber channels has pointed out that many weaknesses exist. However, this does not mean that fiber channel should be dismissed as a suitable technology. When implementing fiber channel into an environment, care must be taken to address these vulnerabilities, taking into consideration location, distance, and availability of the implementation to individuals, systems, and other devices on the network. Taking this one step further, consideration must also be given to the physical placement of the devices and wiring to mitigate the risks associated with using fiber channels. Vendors are also answering the call by offering technology to help secure fiber channel. Although that discussion is outside the scope of this section, zoning and LUN masking are two options for securing fiber channel implementations.⁴

36.3 NFS WEAKNESS AND EXPLOITS.

Network file systems (NFS) provide a service allowing a user on a client machine to access network-based resources as if they were local to that user. This service is built upon the remote procedure call (RPC) service. While very useful in a networked computing environment, NFS presents a number of security issues that must be addressed prior to implementation. NFS is typically geared toward high-bandwidth environments, such as a LAN, or networks sharing nonsensitive information. Since NFS does not provide encryption between hosts, using this technology for other networks, especially those exposed to the Internet, introduces additional risk. This section describes three of the most common weaknesses and exploits for NFS: user and file permissions, trusted hosts, and buffer overflows.

36.3.1 User and File Permissions.

Although a full treatment of NFS weaknesses is outside the scope of this chapter, it is important to call out the major issues. Aside from the aforementioned lack of encryption, NFS allows user access based on the particular host connected to the NFS share. This means that any user connected to that host can access the network resources. Restricting users to read-only access eliminates the potential to use NFS as a collaborative technology, because users can no longer create or update information on the shares. This leads to another issue when mounting shares as read-write. Any user connected to the host can access another user's files, as the only protection the file has is its permissions. Administrators attempt to mitigate this risk by forcing all users to access the share under a group or common set of read-only credentials, but this approach eliminates some of the benefits that a network share provides. The read-only share then requires administrators to update or edit files providing a library-style approach, rather than a collaborative file management environment.

36.3.2 Trusted Hosts.

Problems with the trusted host technology specifically concern the authentication of hosts to the NFS environment. Because NFS controls mount requests based on the host connecting, and not a particular user, a rogue host could request an NFS mount and make changes to resources. Additionally, an attacker could compromise a DNS server used by the system exporting the NFS and then modify the DNS entry to point to an unauthorized machine, thus allowing an unauthorized system to mount the file share. Because there are no login credentials shared prior to mounting NFS shares, if the hosts are not trusted, there are no additional checks to validate the integrity of the host.

36.3.3 Buffer Overflows.

In many implementations of NFS, data input checking does not occur before processing a request. This presents an opportunity for a buffer overflow attack. Where a directory removal request comes to an NFS server from a user with read-write privileges, the server does not check the length of the path name, and the user can include additional instructions beyond what the server should normally receive. Those instructions, probably malicious, could then be executed by the server as an administrative account, such as “root” or “administrator.” As a result, unintended or unauthorized data manipulation can occur.

36.3.4 NFS Security.

NFS provides benefits to network-connected users by its ability to share files, directories, and other resources, but there are inherent security weaknesses in the technology. Recent implementations of NFS have included Kerberos authentication to help validate the users and what they are able to do. In addition, the same validation can be used to validate hosts before they connect to the NFS server. However, these improvements are only partial solutions. Buffer overflows continue to be discovered, and it would be unwise to assume that NFS, or any other network technology, can be completely secured.

36.4 CIFS EXPLOITS.

The Common Internet File System (CIFS), an Internet-enabled Server Message Block (SMB) protocol, builds on that protocol by including encryption and secure authentication to the existing resource sharing capabilities of SMB. Unfortunately, from a security perspective, CIFS blends some of the new with some of the old, and the result includes a number of security issues.

36.4.1 Authentication.

CIFS implementations provide either a straight password-based authentication scheme or a challenge-response scheme. Both of these approaches occur in clear-text, allowing anyone with wire access to intercept and capture authentication credentials to the network share. Even with the challenge-response approach, attackers could spoof a transaction and gain access to the share. Recent implementations of CIFS rely on Kerberos for authentication and, much like NFS, while providing additional security, introduce Kerberos-based vulnerabilities, which are outside the scope of this section. Some CIFS implementations also provide a “share-level” security model rather than a “user-level” security model. In essence, rather than each user maintaining individual credentials, the share has only one set of credentials, which all users share. The weaknesses inherent to a share-level model are similar to those found with the use of group or shared accounts on any other system.

In addition to the authentication issues, CIFS is also vulnerable to dictionary and brute-force attacks against a user's credentials. These generally involve a chosen plaintext attack, helped by intercepting challenge-response pairs during the authentication process. However, both online and off-line dictionary attacks are available to the attacker depending on the amount of time available to watch the connection attempts.

36.4.2 Rogue or Counterfeit Hosts.

It is important to identify the differences between the attack surface of CIFS and that of NFS. Man-in-the-middle and the trusted host issue both apply to CIFS, with some different concerns. Improperly configured CIFS clients can be fooled into thinking that they should supply a password instead of interacting with a challenge-response scenario, thus supporting man-in-the-middle attacks. Additionally, if a CIFS environment does not enable session or message authentication, it removes security controls designed specifically to protect against these types of attacks.

CIFS shares many of the same security issues with NFS. However, most of the issues can be avoided by enabling security features included with the protocol. Man-in-the-middle and session-hijacking attacks, in addition to replay and spoofing attacks, can be avoided by message and session authentication. This does not suggest that CIFS can be completely secured; rather, care must be taken during the configuration step of implementation to make use of all available security controls.

36.5 ENCRYPTION.

Many individuals and organizations focus on encrypting data while it is in motion and transiting networks, especially the Internet. The use of encryption for data while at rest, or stored, is equally important. As previously mentioned, stored data are compromised by security breaches more often than data in transit. With the use of a sufficiently strong algorithm and sufficiently sized key, data that are stored encrypted can be made unusable for those without the ability to decrypt them. Even if an attack is successful at gaining full control of the data for brute-force attempts at decryption, a proper algorithm and key can prevent the data from being decrypted for a reasonably sufficient period—long enough that any personally identifiable information (PII) or other sensitive, confidential, or proprietary information would be of no value except to historians.

See Chapter 7 in this Handbook for more details of cryptography; see Chapter 37 for details of the public key cryptosystem.

36.5.1 Recoverability.

Key principles of information assurance (IA) include protecting the availability and utility of data. By its nature, encryption can take away these protections in exchange for protecting the authenticity, confidentiality, and integrity of the data while it mitigates the risk of losing possession of the data. When using data encryption, it is important to consider the possible need to recover the data in the event that the user or primary key is unable to be located. There are several ways to accomplish this.

Key escrow is one method to facilitate the recovery of encrypted data. By storing the key with a trusted party, a lost key can be removed from escrow and used to decrypt the data. With public key encryption, additional decryption keys (ADKs) can be used with some encryption tools. Corporate ADKs are keys that can be used during the encryption process to encrypt the data automatically with a key that is tightly controlled and used only by designated individuals for the recovery of encrypted data.

36.5.2 File Encryption.

The use of encryption on a file-by-file basis is a good method for securing data. With file encryption, a user can pick and choose which files to encrypt. Files containing sensitive data can be encrypted while nonsensitive files are stored without encryption. This method has the least impact on a system, but it puts most responsibility on a user, who must determine which files should be encrypted.

Operating system files cannot be encrypted, so configuration files that may contain information on the organization's systems are left as risk—as are application code files. These code files may be for the organization's proprietary application that provides a significant competitive advantage. However, such files are rarely encrypted, as doing so can provide a hindrance for users, who must remember to decrypt each and every file when required.

36.5.3 Volume Encryption and Encrypted File Systems.

Both volume encryption and encrypted file systems offer protection to data and can be easier for users than per-file encryption. The ease of use comes from the single operation required to access multiple files. Depending on its configuration, a location can remain decrypted and accessible for a few minutes or several hours.

A critical difference between file encryption and volume encryption is that decryption is carried out at the driver level as data are moved from disk into RAM. The entire volume is not decrypted in its totality. For example, an entire 4 GB partition encrypted by PGP Desktop would take several minutes to decrypt, whereas access to the PGP container for the volume is granted within a second when the encrypted volume or folder is mounted. In addition, dynamic decryption ensures that there is no large decrypted copy of the original materials stored on the hard disk for reverse cryptanalysis in case of an aborted shutdown.

With partial encryption of a disk, only a portion of the data stored on the disk and specifically written to the encrypted partition is protected. Usually operating system and application files are not encrypted, so a stolen or otherwise compromised disk is vulnerable to attackers who would gain access to any file not saved into the encrypted volume or file system. If a user forgets to encrypt a file containing sensitive data, then the data are accessible to anyone who can activate the operating system or read the disk drive.

36.5.4 Full Disk Encryption.

Author Ryan Groom lists cogent reasons for using full disk encryption on laptops.⁵ These can be restated for any system. The primary reasons to use full disk encryption are that it protects data if a drive is lost or stolen, it is safer and more effective than volume encryption or encrypted file systems, it can be transparent to users, and it helps comply with legal and regulatory issues.

Full disk encryption secures the file system and operating system files but leaves a small boot portion of the drive unencrypted. The unencrypted region allows the encryption software to load; to request the password, passphrase, or token needed to initiate dynamic decryption of the drive contents on demand; and to continue loading the operating system.

Depending on the solution chosen, users can see relatively little difference between a system using full disk encryption and a system that does not. The primary visibility to users is that on a system boot, the user will be prompted to decrypt the drive. System performance is somewhat reduced, primarily during the boot of the system while significant data from the disk are decrypted, and again on shutdown as unencrypted data are cleaned up to prevent readability without authorization. This minimal impact on users is greatly outweighed by the protection afforded by full disk encryption.

As with volume encryption, full disk encryption involves dynamic decryption of ciphertext as it flows from disk to memory buffers. With modern data-transfer speeds and processor capabilities, there is no significant performance delay due to on-the-fly decryption once the operating system has been loaded.

When a system is lost or stolen, an attacker has, essentially, an unlimited amount of time to gain access to the data. If the data are not encrypted, they can simply be read. With encrypted file systems or volume encryption, only a portion of the data is stored encrypted. Data that are not in one of these encrypted locations are vulnerable—including swap spaces and temporary file locations used by the operating system. With full disk encryption, the entire contents of the drive are protected. Even with full physical access to the disk (e.g., by installing it into another computer under the attacker's control) or with a copy of the encrypted disk, an attacker must break the encryption in order to gain any information—an almost impossible task with the key sizes currently in use, except perhaps by government cryptanalysis labs using massively parallel architectures for brute-force cracking. With strong encryption, management may be able to satisfy the concerns of clients if an organization has to disclose the loss of equipment and must provide an assurance that, even though the disk was lost, the client and organization's data cannot be accessed.

36.5.5 Vulnerability of Volume, File System, and Full Disk Encryption.

As strong as the protection provided by volume, file system, and full disk encryption, there is one significant weakness. Once a user is authorized to access the data, and the operating system dynamically decrypts data as required, the system is vulnerable to attacks by any interloper who has physical access to the unlocked, unprotected session. For example, if a system contains sensitive data and is connected to a network, any attack over the network can potentially compromise the data when the authorized user's session allows access to the decrypted data. Additionally, some researchers have identified attacks against keys while they are stored in RAM by freezing the RAM using substances such as liquid nitrogen and putting the RAM in another machine to read it. The practicality of this attack is limited as RAM is volatile memory and the period during which an attack could occur is limited.

This vulnerability must be stressed to users who may misunderstand the implications of encryption, especially those who insist on storing sensitive data on their laptops. Although full disk encryption protects the data when the system is not booted, once the user decrypts the disk at boot, the data are available not just to them but to anyone else who gains access to the system. Systems must use defense-in-depth strategies with personal firewalls to prevent unauthorized network access to the system; users must maintain physical possession of the system, especially once they have entered their decryption key. If a user with a Windows operating system on a laptop locks the screen and then walks away, the data are protected only by the strength of the system password.

Especially sensitive data should be encrypted at the file level. Alternatively, volume and file system encryption can be used with reasonable timeouts applied. Both of these options provide increased protection of data while a system is booted. Combined with full disk encryption, the risks to data are greatly reduced. Moreover, what could be worse for an attacker who broke the full disk encryption only to find that the information is encrypted another time, or two if file encryption, volume encryption, and full disk encryption are all in use?

36.5.6 Database Encryption.

For many organizations, the databases that are the primary location for storing data are also an excellent target for attackers. By employing database encryption, the time an attacker needs to gain access can be greatly increased.

Databases can be protected by placing them on a system that can be accessed only via a secured connection and one that employs volume or full disk encryption. In addition, there are database encryption tools designed to protect the data held within these stores even without disk encryption. These tools employ encryption at the field (individual data element), column (a collection of fields that align in a column when seen in a tabular view), and full database encryption. One of the advantages of database-specific encryption is that it can support stricter control around access, as users would need different keys, passwords, or passphrases in order to access the different databases instead of all users being able to use a single credential to access multiple databases.

In an article for SearchSecurity.com, James C. Foster points out that applying database encryption as a tactical way to address compliance with laws, regulations, or company policy is not without risk, as application speed and performance can be negatively impacted if the encryption is not implemented correctly.⁶ Foster recommends considering these factors to help mitigate this risk:

• Encryption of foreign or super keys should not be done as the keys are used to provide relational connections between tables, schema, and/or databases. Since these values are not encrypted, they should not contain information that is personally identifiable or needs to be encrypted, such as a customer's credit card or Social Security Number.
• Encryption key protection needs to be addressed as if a single key is used for all data. The database is vulnerable to being fully compromised if control of the key is lost.
• Full versus partial database encryption needs to be determined as performance is impacted due to the need to encrypt and decrypt data as it is written to or read from the database. Consider only encrypting columns that contain sensitive data; often this is all that is required or suggested to be protected by regulations or laws.

36.5.6.1 Improving Vendor Provided Options.

Database vendors such as Oracle Corporation and Microsoft have encryption options that are specifically designed to protect the information in their databases. These options have improved over time and are becoming more robust and mature.

Microsoft SQL Server 2005 offers enhancements to column encryption. Also introduced was “an integrated and hierarchical infrastructure for managing encryption keys.” The product documentation continues: “Built-in encryption functions and application programming interfaces (APIs) make it easier for an organization to create an encryption security framework.”⁷

Oracle Database 10g Release 2 improves on existing encryption options within Oracle databases by introducing Transparent Data Encryption (TDE). When using TDE, a database administrator is able to specify that a column needs to be encrypted, and the database automatically encrypts data during insert operations and decrypts the data during selects. This can be achieved “without writing a single line of code.”⁸ Arup Nanda provides a good overview of this feature in the September/October 2005 issue of Oracle Magazine.⁹

36.5.6.2 Implementation Considerations.

As with any implementation of encryption, careful consideration must be given to determining the method and process for implementing the solution as well as to the data that are being encrypted. Encrypting a key field needs to be avoided. If sensitive data are in the key field, significant work may be required to create new key fields and re-create table linkages, or the organization may decide to accept the performance degradation that could occur with encrypting the key field. That is, of course, assuming that encrypting the key field does not cause the database to become unusable.

The costs associated with implementing an encrypted database solution must also be weighed against the business risk. For companies that have little data needing encryption, database encryption may be inappropriate. Legal and regulatory requirements also need to be considered; database encryption may be mandated in order to protect data and to avoid criminal or civil liabilities. The attendant loss of public and customer confidence, in the event of a data breach, is also a powerful incentive.

36.6 DATA DISPOSAL.

A final consideration for securing stored data is the disposal of the media that contains the data.

For sanitizing electronic media, United States Department of Defense 5220.22-M can provide guidance.¹⁰ Essentially, the media should be sanitized such that the data originally written to it cannot be recovered. One method for achieving this can include these four steps:

1. Erase the data.
2. Write random or meaningless data to the media.
3. Erase the data.
4. Repeat until the desired level of sanitization is met.

For information stored on paper, the paper should, at a minimum, be shredded before being discarded. Use of a cross-cut shredder is preferable as it increases the difficulty of piecing the documents back together. Additional steps can that can be taken if needed, and facilities are available that burn the shredded paper and mix it with water to speed its deterioration. Over the past several years, vendors specializing in on-site paper destruction have become commonplace. These vendors bring trucks to a client's site and collect paper that is then shredded on-site before being taken to a facility that recycles, burns, or otherwise disposes of the waste in a secure manner.

For more information about data disposal, see Chapter 57 in this Handbook.

36.7 CONCLUDING REMARKS.

The security of stored data is of critical importance. More data breaches occur against data in unsecured storage locations than is compromised during transit. With proper data storage security, there is less risk to data from all kinds of threats, internal and external. Using secure channels for writing data to disk and protecting the disks themselves is of increasing importance as attackers usually have one of two goals: causing systems or data to be made unavailable, or compromising the confidentiality and integrity of data. By combining secure communication channels, data encryption, and physical protection of data storage devices, the security of information can be better assured.

36.8 FURTHER READING

Barker, E. B., W. C. Barker, and A. Lee. “Guideline for Implementing Cryptography in the Federal Government,” NIST Special Publication 800-21. National Institute for Standards and Technology, Technology Administration, United States Department of Commerce. Accessed online at: http://csrc.nist.gov/publications/nistpubs/800-21-1/sp800-21-1_Dec2005.pdf.

Barker, W. C. “Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher,” NIST Special Publication 800-67. National Institute for Standards and Technology, Technology Administration, United States Department of Commerce. Accessed online at: http://csrc.nist.gov/publications/nistpubs/800-67/SP800-67.pdf.

Chudnow, C.. “Storage Area Network Security: The Human Factor,” Computer Technology Review (Fall 2006). Accessed online at: www.wwpi.com/index.php?option=com_content&task=view&id=1580&Itemid=44.

Curtis, W. C. Backup & Recovery. Sebastopol, CA: O'Reilly, 2007.

Curtis, W. C. Using SANs and NAS. Sebastopol, CA: O'Reilly, 2002.

Dwivedi, H.. Securing Storage: A Practical Guide to SAN and NAS Security. Chapter 2: “SANs: Fibre Channel Security”. Boston: Addison-Wesley: 2006. Accessed online at: www.awprofessional.com/content/images/0321349954/samplechapter/Dwivedi_ch02.pdf.

FalconStor Software and Ologic. “Fibre Channel Security White Paper,” White Papers, ITtoolbox, October 11, 2005. Accessed online at: http://storage.ittoolbox.com/white-papers/fibre-channel-security-white-paper-3422.

Foster, J. C. “Look before Leaping into Database Encryption.” Compliance Counselor, SearchSecurity.com, September 29, 2006. Accessed online at: http://searchsecurity.techtarget.com/tip/0,289483,sid1^gci1219561,00.html.

Harris, S. All-in-One CISSP Certification Exam Guide, 2nd ed. New York: McGraw/Hill/Osborne, 2003.

Polk, W. T., D. F. Dodson, and W. E. Burr. “Cryptographic Algorithms and Key Sizes for Personal Identity Verification,” NIST Special Publication 800-78. National Institute for Standards and Technology, Technology Administration, United States Department of Commerce. Accessed online at: http://csrc.nist.gov/publications/nistpubs/800-78/sp800-78-final.pdf.

Regan, K. “Mounting Data Spurs Corporate Storage Spending,” E-Commerce Times, March 13, 2007. Accessed online at: www.ecommercetimes.com/story/56270.html.

Shepler, S., et al., Network Working Group. “RFC 3530 Network File System Version 4 Protocol” (April 2003). Proposed Standard Requests for Comment, Internet Engineering Task Force. Accessed at: http://tools.ietf.org/html/rfc3530.

Troppens, U., R. Erkens, and W. Muller. Storage Networks Explained: Basics and Application of Fibre Channel SAN, NAS iSCSI and InfiniBand. Hoboken, NJ: John Wiley & Sons, 2004.

United States National Security Agency. “Fact Sheet NSA Suite B Cryptography.” Accessed online at: www.nsa.gov/ia/industry/crypto_suite_b.cfm.

Verhelst, W. “Securing NFS,” Free Software Magazine, Wouter Verhelst's Blog, November 26, 2006. Accessed online at: www.freesoftwaremagazine.com/blogs/securing_nfs.

36.9 NOTES