This tip is part of SearchSecurity.com's Compliance School lesson, Must-have compliance technologies. Visit the Must-have compliance technologies lesson page for additional learning resources.
Picture a meeting that goes something like this:
"I want to avoid data breaches from my laptop users," says the PC support team lead, "So we're deploying full-disk encryption. That will make us compliant with state disclosure acts."
The database team lead turns and comments, "We have credit card data saved in several databases, and the DBAs shouldn't be allowed to look at it. We're going to implement columnar encryption to satisfy PCI requirements."
"Well," says the storage team lead, "I need to show that there's segregation of duties between my storage admins, who reconfigure repositories, and the financial folks who save our performance numbers on the network. So we're deploying a network encryption solution, which will help us quiet the SOX auditors..."
Three different encryption scenarios, each answering an anticipated compliance mandate. With so many types of encryption available today -- whole-disk, file-level, message-level and application-layer, most notably -- how can an organization determine when or what type of encryption is the right choice? More importantly, how can anyone be sure that encryption is deployed correctly?
Where are the biggest risks?
For the security architect, a number of factors must be considered. First of all, where in the organization is information most at risk? Although encryption can be helpful, it's often not wise to deploy many disparate silos; at least, not without a comprehensive plan. Certainly, databases hold critical data, but many recent incidents have been caused by the loss of notebook computers, backup tape mishandling or other problems far removed from the database.
Further, even when encryption is deemed a reasonable control, enterprises must carefully assess how attacks take place by privileged insiders, across applications and throughout networks. This assessment directly affects at which layers encryption should be deployed, and which compliance requirements are adequately satisfied.
The following table shows common threats and the locations to deploy encryption:
| Threat |
Where to use encryption |
Other considerations and tradeoffs |
A thief stealing a device or media, or loss of a device by
an employee (compliance concern: breach disclosure acts and PCI)
|
On the media: hard disk, tape, USB memory
stick, etc.
Application and repository encryption can also be used |
Usability of the media
Recovery of the information
Forensics may be more difficult |
An
eavesdropper sniffing the network (compliance concern: any consumer data
protection or financial services regulation)
|
Data in
motion – IPsec or SSL/TLS VPN |
Network
monitoring
Network performance |
| An
administrator accessing data in an unauthorized manner (compliance concern:
special focus on SOX and PCI) |
Within
the application or possibly the repository |
Cost of application updates
Availability of authoritative or primary
information
Search may be more difficult |
| An
individual gaining unauthorized application access (compliance concern: all,
but especially PCI for credit card data in Web environments) |
Encryption
is not helpful (because the application has access to underlying cleartext) |
One-way
hashing may not only prevent the disclosure of sensitive information, but also limit
use of the information |
| Insiders
(compliance concern: all, with special consideration of HIPAA and breach
disclosure acts) |
Encryption
may not be helpful depending on the insider access |
Use
other mechanisms to detect inappropriate use |
|
|
|
Many organizations will choose several of the above options, realizing that each has tradeoffs. Regardless of the techniques chosen, coordinated planning among IT groups is a must in order to not only reduce the number of vendors involved, but also increase the shared infrastructure where possible.
In other scenarios, it makes more sense to deploy monitoring systems to observe user actions or information flows, rather than deal with the management issues associated with encryption. Often, it's prudent to prevent information from flowing to unprotected areas -- such as keeping customer data off of portable laptops -- rather than encrypting data locally and hoping that users work with it appropriately.
Technologies and processes to support encryption
But for those companies that elect to encrypt -- and many will -- they must always keep in mind the critical "supporting cast" of encryption:
- Authentication: Whether accessing a local encrypted disk or a remote encrypted file, unless users are adequately identified and authenticated, encryption itself is pointless.
- Key management: Encryption keys must be managed correctly throughout their lifecycle. They must be created with the proper strength, distributed securely to the encryption engine(s) and updated periodically as threats and risks change.
- Key and data recovery: A particularly important phase of key management, keys must be recoverable in case of user error or other problems. If keys are not archived properly, encryption can be a great way to lose information forever.
- Help desk processes: Although authentication is required, invariably users will forget passwords. The result is that help desks must be prepared to guide users through information-recovery and password-reset requests.
- Network encryption: Many compliance requirements can be answered by protection of data at rest. However, connections to repositories frequently flow over untrusted networks, necessitating transport encryption, too.
- Policy monitoring: Many central security teams create the guidelines and standards for encryption, but expect other groups to actually implement encryption measures. In such cases, it's important to monitor policy to ensure that encryption is working as intended. It's equally important to watch for rogue encryption, to make sure that compliance-related data isn't flowing out of the organization over unauthorized channels.
- Client and server management: Software exploits don't care if information is encrypted; they will happily wreak havoc after a user has authenticated. Further, privileged malware can tamper with encryption and key-handling activities directly. It's critical, therefore, to ensure that configurations are correct, and that systems are hardened against viruses, Trojan horses and other undesirables.
Choosing the appropriate layers and supporting technologies and processes for encryption is necessary, but not sufficient. When talking compliance, there's one additional ingredient: the auditor. Although you shouldn't let auditors dictate your architecture choices, their input and feedback can be valuable when selecting controls (such as encryption) to answer compliance requirements. So don't forget to make auditors your friends.
About the author:
Trent Henry is a senior analyst with Midvale, Utah-based research firm Burton Group. Henry is a Certified Information Systems Security Professional (CISSP) with more than 15 years of experience in information technology working at companies including Identrus, Digital Signature Trust, Ameritech, and Apple Computer. His past work includes PKI industry security management and technology research, Internet server and protocol product development, and operations leadership of large-scale network and distributed systems deployments. Henry has participated in security standards bodies including X9 and Internet Engineering Task Force (IETF) and contributed to the first Common Criteria Protection Profile slated to become an ANSI standard. He is a respected speaker and writer on information security, audit, and compliance topics and received his undergraduate degree from Stanford University.
