This article can also be found in the Premium Editorial Download "Information Security magazine: 2009 Security Readers' Choice Awards."
Download it now to read this article plus other related content.
It's a security practitioners dream to deploy a technology that ensures perfect data protection 100 percent of the time. Short of unplugging a computer and locking it in a vault, few technologies come as close as encryption to nearly unbreakable data security; take the data, run it through an encryption algorithm, and it's unreadable to anyone who doesn't possess the right key to reverse the process. It can be mathematically demonstrated that retrieval of encrypted data without the encryption keys is computationally impossible within the expected lifetime of the universe.
And while many strive for this level of certainty, practical issues in the use and deployment of encryption often limit benefits and negatively impact business operations. Reality has a very rude habit of shattering our security dreams.
Encryption is everywhere in IT, from network communications and stored data, all the way down to smartphones and thumb drives. When applied correctly, it's incredibly effective at preserving data privacy and integrity. When misapplied, either because it was poorly deployed or is expected to solve a problem it cannot, an organization does not get added security, but instead spends unnecessary money and slows down operations.
In reality, encryption solves only three problems: first, protecting data that moves physically or virtually, second, protecting data-at-rest, and finally, restricting access when access controls aren't sufficient. It seems simple, but
Why? Because there are assumptions, myths and even urban legends surrounding encryption. We'll debunk conventional wisdom and explain what is true, what is almost true and what is completely false.
Claim No. 1: "We need encryption because access controls aren't good enough."
This statement is fiction. Access controls are very effective at separating those who should have access to data from those who should not. Set up properly, with users assigned only to specific accounts dedicated to an explicit job function, they can even provide separation of duties. It is only when the access control system is subverted or policies are misapplied that it fails. What separates this statement from being an outright lie is in the case where encryption is used to enforce access rights as data moves outside a domain of control, or when available access controls aren't granular enough.
One such example is sharing data between partner sites, where you do not control the destination systems. Authorization policies may not be the same, controls may not be fully enforced, and without encryption the data is vulnerable. Several IT executives we have spoken with use encryption in this way to limit who sees shared data. Separating keys from the encrypted data files, and providing keys only to a select subset of partners who need access, maintains some control over who can use the data (assuming your partner doesn't share the keys). Another example is the use of transparent database encryption (TDE), where the database contents are encrypted prior to being written to the file system. In this model, the database administrators and users have access to encryption keys, but the IT administrators do not. The IT staff cannot view or alter the contents of the database by reading/writing data files, providing separation of duties between privileged administrative roles.
If traditional access control options exist, use them first! They are easier to use, easier to deploy, faster and more efficient. Using encryption to augment access controls and provide separation of duties should be considered only when you have exhausted other available options.
Claim No. 2 "Encryption thwarts Internet hackers and data breaches."
Security vendors state this in their press releases, regulatory bodies endorse it, and company spokespeople attempt to instill confidence in their customers with this message. In reality, it's little more than a lie.
Attackers will leverage every available system and resource they can to access data, including the very users and systems responsible for safeguarding the information: breaking into user accounts, rummaging through trash and stealing computers, just to name a few. The attacks come in every type imaginable, and nothing is off limits. Systems and networks are so complex, with so many entry points, that the bad guys don't need to bother attacking encryption. They can take advantage of all the other ways to get to our data. Let's review a couple of the common attacks:
- User account compromise: If an application user account or automated service is compromised by guessing a password or leveraging another account, then the attacker has access to all of the features and functions that the legitimate user did. If that includes encryption keys or data stored under some form of 'transparent' encryption, the system will decrypt data for them.
- SQL injection: Subversion of application or database logic through a SQL injection attack gives the attacker access to everything the application sees, sometimes including administrative functions. It may stop data theft if the encryption keys are protected outside of the database, but the attacker may be able to leverage the database to gain access to the keys.
- Circumvention: With the Heartland Payment Systems breach, communications were encrypted, but data was decrypted at the merchant and payment processor sites along the way. Compromise of a system that accessed data in the clear circumvented encryption entirely.
- Poor implementation: It has been demonstrated that AES, when used to encrypt browser cookies, can be broken due to poor implementations--not by breaking the algorithm, but rather by taking advantage of the way Web servers use encryption. WEP is another classic encryption implementation failure.
- Trojan horses: Insertion of malicious code, such as keystroke loggers, can collect user credentials and, through the inspection of user activity, locate valuable data. In this type of attack, the encryption is bypassed through the use of legitimate credentials.
All of these attacks are against systems and legitimate user accounts. Most information systems are designed to make data access, even encrypted data access, as easy as possible. Hijacking user accounts or programs provide hackers the same ease of use. All of these attacks can be mitigated through good key management practices, separation of duties, or alternative security controls, but they cannot be eliminated entirely.
Claim No. 3 "Full-drive encryption for laptops is easy and should be mandatory."
The single greatest cause of reported data breaches in the last decade was due to lost media, specifically through lost backup tapes and stolen laptops. As encryption is ideally suited to protect data at rest, this statement is absolutely true.
We talked to numerous senior IT managers at several Fortune 500 companies and these organizations have embraced encryption of the endpoint. Almost universally, they have implemented disk encryption for laptops. Still not everyone is satisfied. A large segment of security and IT staff are hesitant to encrypt laptops due to failures by encryption vendors to adequately support common IT tasks. The perception still exists that key management is difficult use, it does not work well with backup software, and resetting forgotten user passwords is completely broken. Despite being an effective solution, the feeling is it creates other headaches that make it unmanageable.
While the claim was true in years past, endpoint encryption vendors have addressed these issues through multiple integration and administrative improvements, including:
- Key management can be centrally administered and made invisible to IT operations.
- The systems support password recovery, including remote recovery and one-time unlock codes.
- Backups are performed by credentialed user accounts, working seamlessly with backup routines by gathering an unencrypted copy of the data.
- System management can be performed in a number of ways, including key management hierarchies and integration with access control systems, providing a gateway for configuration and patch management.
The goal of media encryption is to safeguard data in the event it is lost or stolen because a disk drive is missing, a tape falls off the back of a truck, a server gets sold on eBay, a smartphone is left on the bus, or a laptop is left at the airport. While a nuisance, it does not mean these incidences will conflict with your ability to manage these devices.
Claim No. 4 "Database encryption is difficult to implement and too slow to use."
We hear this claim from many security practitioners in the field. There is a degree of truth to the statement because database encryption can be difficult to implement, and depending on how it is deployed, requires application code changes and a database redesign. When diligently applied, however, database encryption protects data that resides on media as well as misuse of sensitive data by credentialed users, with only a marginal performance impact. Careful deployment will sidestep these issues, so we classify this statement as fiction.
Relational database vendors provide transparent database encryption; it's called transparent because it is invisible to database queries and operations, encrypting all database content by altering nothing more than a few configuration settings. Other options, such as products that intercept and encrypt data prior to being written to the file system or use of encrypted disk drives, act 'transparently' as well. While each of these variations have security advantages and detractors, they perform seamlessly and are incredibly simple to implement.
While we are categorizing this one under 'fiction,' performance can be an issue depending on your environment. How many transactions are processed per day? What type of transactions? The age of the hardware and how encryption is used all impact throughput and performance. Simple transactions consisting of single row insertions and updates offer reasonable performance. Heavy analytics or processing on encrypted tables is not suitable for encryption. It is better to remove or obfuscate sensitive information from these databases, or utilize other technologies to protect the data.
Claim No. 5 "Before I can start my encryption project, I need centralized key management and key management standards."
The most common complaint we hear as companies deploy encryption systems is the difficulties surrounding key management. Encrypting data used across multiple systems or by large numbers of users creates key management challenges that require automated support. But that does not account for the majority of data encryption systems which are self-reliant, and where centralized key management is neither necessary nor appropriate. In reality, most encryption solutions build in key management, obviating the need for some kind of "uber" centralized key management service. Since central key management needs to be considered on a case-by-case basis, this statement is false.
Support for a large numbers of users, remote sites that poorly implemented key management in an existing solution, or sharing data across applications are suitable candidates for centralized key management. The complexity of key security, key sharing, access controls and backup/recovery are best performed by specially designed, automated systems. There are many use cases for encryption that do not fall into those categories, such as closed systems or cryptographic systems that support a small number of users, and are not candidates for supporting management services. Examples include:
- Intra-application encryption, such as transparent database encryption, is used to safeguard data within the system from exposure. It does not need to share keys with other applications, and autonomously provides key creation, data encryption and key backup.
- Most backup and file/folder encryption solutions build key management in, and no external management is needed.
- All modern full-disk encryption solutions include centralized key management.
- Public-key systems that use external key authorities and key generation do not require additional central-key management services, unless they do a bad job of managing their keys.
Key management can be difficult and complex, but it's built in to most encryption solutions today. There's no reason to combine your database, endpoint, backup and application keys into a single repository as long as you can manage them effectively individually. You'll waste more time trying to centralize management than it takes to use what's built in.
Claim No. 6 'Free' encryption is bad encryption."
This is a lie. It is often claimed that free encryption is bad because the code cannot be trusted, when in fact, some of the finest encryption algorithms are available license-free and un-copyrighted. The http://www.schneier.com/twofish.html">Twofish Block Cipher was one of the finalists for adoption as the AES standard and is just such an example.
To get an idea of why people claim free cryptography is bad, we really need to differentiate between the quality of the theoretical cipher and the quality of the implementation of that cipher. This myth is often propagated because there is the occasional person/company who will try to recreate a well-known cipher without any understanding of the subtleties that go in coding cryptography, resulting in a very bad implementation of a very good cipher. It does not take long to locate high-quality encryption products. Trustworthy cryptographic libraries, with downloadable copies on the Internet, are freely available. You will know the quality ones as they are based upon open and public standards, their code has been reviewed and accredited by experts in the fields of cryptography and cryptanalysis, and they are widely used in the industry.
Keep in mind there are benefits to buying from an accredited vendor, namely the products provide a level of manageability, integration and support that are not found with the free versions. Free-for-use encryption is usually a toolkit or library that requires some customization or integration to work, and is therefore accessible to fewer audiences. Most enterprise IT organizations do not have expertise or time to justify building atop these libraries, and it make sense to purchase a comprehensive solution from a vendor who specializes in off-the-shelf software. But make no mistake, some of the best encryption products in the world are available for free.
In summary, encryption is an incredibly effective and powerful tool, yet it's also shrouded by misunderstanding and consistently used improperly. Focus on using it for the right problems, and you'll find yourself spending less, while being more secure.
Adrian Lane is a senior security strategist with Securosis LLC, an independent security consulting practice. He has 22 years of industry experience, specializing in database architecture and data security. Prior to joining Securosis, Lane was the CTO at the database security firm IPLocks, and he has also served as the vice president of engineering at Touchpoint, three years as the CIO of the brokerage CPMi, and two years as the CTO of the security and digital rights management firm Transactor/Brodi.
Rich Mogull has more than 17 years experience in information security, physical security, and risk management. Prior to founding Securosis, Rich spent 7 years as one of the leading security analysts with Gartner, where he advised thousands of clients, authored dozens of reports and was consistently rated as one of Gartner's top international speakers. He is one of the world's premier authorities on data security technologies and has covered issues ranging from vulnerabilities and threats, to risk management frameworks, to major application security. Rich frequently contributes to publications ranging from Information Security to Macworld.
Send comments on this article to firstname.lastname@example.org.
This was first published in September 2009