One of the fascinating things to do when in New York City is to visit the Federal Reserve gold vault. The vault lies 86 feet below sea level, resting on Manhattan bedrock, and holds approximately 5,000 metric tons of gold bullion. The Federal Reserve Bank does not own the gold but serves as guardian of the precious metal, which it protects at no charge as a gesture of goodwill to other nations.
Obviously, the security measures to protect hundreds of billions of dollars of gold are intense. But even if a thief were to breach the underground defenses and avoid the marksmen, how would he get the gold out? Gold is dense, difficult to transport and heavy, with each bar weighing approximately 27 pounds. Combined with the impossible-to-negotiate downtown Manhattan traffic, those facts contribute to the vault being a safe and sound way to protect the gold.
The data stored within your IT infrastructure is also quite valuable. The challenge--how do you make your data like gold, so that it is difficult to illicitly move and use? The answer is, quite simply, encrypt it.
Data that is effectively encrypted is unusable to the party who recovers it if that party lacks the proper decryption key(s) and means to decrypt. Imagine if your case of of fifty 600-gigabyte backup tapes was lost in transit. If the tapes were encrypted, you would still want to find them. But if they were not encrypted, you need to call the lawyers and immediately initiate your incident plan.
Many of the data breaches of the past few years could have turned into non-incidents if the data had been encrypted. Most recently, web hosting firm Network Solutions warned over half a million cardholders that their transaction data may have been compromised. In a statement, the firm said it found unauthorized code on servers supporting some of its e-commerce merchant's web sites. They noted that "after conducting an analysis with the assistance of outside experts, we determined that the unauthorized code may have been used to transfer data on certain transactions for approximately 4,343 of our more than 10,000 merchant web sites to servers outside the company." At no point do they indicate that encryption was used.
The PCI DSS and encryption
PCI DSS Requirement 3 details technical guidelines for protecting stored cardholder data and the requirements for encryption. The PCI DSS has perhaps been the biggest boon for encryption since the creation of PGP. Section 3 provides the high-level details around encryption. At a minimum, PCI requires the PAN (primary account number) to be rendered unreadable anywhere it is stored, including portable digital media, backup media and logs.
For merchant data, if it were all encrypted, then PCI DSS compliance would be much easier to accomplish. Note however, that even if an entity would encrypt all of its data, it would still be required to be PCI compliant if involved in the storing, processing, and/or transmission of cardholder information. The PCI Standards Security Council (PCI SSC) has been adamant and clear that the act of encrypting cardholder information does not render those systems and data involved as out-of-scope with respect to PCI compliance.
PCI is the leading driver for application and database encryption, as any entity that is required to be PCI compliant needs to deal with encryption to protect cardholder information. But even with the significant security that encryption provides, it is not without its technical and management challenges, some of which include:
* Operating system and application vendors haven't made it easy and seamless to implement encryption, especially due to a lack of support for legacy systems
* Applicable laws/guidelines often conflict or fail to provide effective and consistent guidance
* Organizations implementing encryption often lack formal documentation of cryptographic processes and procedures
* Organizations implementing encryption often do not have a person or group who formally owns and is ultimately held responsible for proper cryptographic administration
* Costs / Performance Impacts
- Up-front and on-going system maintenance costs
- Encryption is often a performance hit it to systems and applications
- Costs and overhead associated with securely managing cryptographic materials
- Required executive level support for cryptography audit and compliance requirements
Encryption challenges are often manifest in databases - encrypting indexed data is one of them as detailed in the Oracle Database Security Guide [pdf link]. Other challenges include:
* Key management
* Key transmission
* Key storage
* Changing encryption keys
PCI DSS and Data Encryption
For starters, encryption should be seen as a fundamental element of an organization's risk management program. While technologies such as firewalls and IDS/IPS are de rigueur, encryption is still lacking in far too many enterprises.
While the PCI DSS requires encryption or some other obfuscation of the PAN, the payment industry as a whole still has some perceived shortcomings. Specifically, PCI does not require encryption of data in transit over a private or internal network. The current definition of a private network has been inferred by PCI standards documentation; however, it is still unclear how to make a determination in all cases.
For example there are some public networks such as those comprised of Multiprotocol Label Switching (MPLS) and Plain Old Telephone System (POTS) elements that are most clearly public in nature, yet the PCI DSS requirements make exceptions for these.
There is also some confusion on whether satellite-based data networks are considered public or private, and hence in need of encryption capabilities or not. The authors are of the opinion that satellite-based data networks should be considered public networks unless they can be proven that they are sufficiently difficult to easily intercept and decode the transmitted data. Note that the last part of this statement sounds incredibly subjective, and it is indeed so.
This subjectivity however is the position taken thus far regarding PCI compliance of satellite networks by the PCS SSC and major card brands. They are leaving the final determination of public or private satellite network status up to the individual PCI QSA (Qualified Security Assessor) reviewing relevant implementations. So there may indeed be some variance of opinions regarding actual compliance among different QSA's. Encrypting the data regardless of the above instances renders any confusion over relevant compliance a moot point.
Many vendors and compliance professionals are now touting the holy grail of data protection which some refer to as end-to-end encryption (E2EE). E2EE implies encryption of cardholder information at the card swipe or other input source (such as being manually entered into a field within a web-page) and the data remaining encrypted until its transmission to the payment processor for authorization and processing.
Getting E2EE working, especially on a global scale, for all payment processing represents a daunting effort significant both in scale and scope, but doing so would help to ensure a robust core data protection capability. It is hoped that the future will bring stronger E2EE partnerships and integration with all of the PCI entities -- from the processors, acquirers, card brands, and myriad merchants.
In a perfect world, the card networks, issuers and payment processors would implement end-to-end encryption for anyone who uses their services and would make it a requirement for connectivity; no encryption would equal no connectivity. This would consequently create a strong level of security and not require each merchant to deal with the significant burden and problems of key management (see later section in this article about that).
In a Gartner article on the topic, they note that Spain has more than 80 acquiring banks, all of which are grouped under one of three domestic payment schemes that operate in the country, each with its own processing company that provides issuing and acquiring processing services.
One of the payment networks, ServiRed, together with its processing company, Sermepa, now serves more than 100 member banks with 40 million cards in issuance. ServiRed and its peers are participating in a systemic, countrywide solution that supports end-to-end encryption of payment card data from merchant payment terminals to the acquiring processor, where the card data is decrypted. Bank identification numbers (the first four digits of the card number) are left in the clear for routing purposes, while data is encrypted in merchants' terminal card readers. Encryption keys are stored and managed by merchant acquirers so that merchants don't need to bother with them. Their collective success story ultimately proves that E2EE processing is not only possible, but may represent an acceptable trend and model for future implementations.
Gartner notes that merchants in Spain are being asked to migrate their terminals to accept Europay, MasterCard and Visa chip cards, while simultaneously being asked to comply with PCI. The Spanish acquirers introduced end-to-end encryption to simplify all the security activities required by their merchant customers.
While Spain's payment network pales in comparison to the size and complexity of US networks, it has demonstrated that end-to-end encryption is indeed possible on a payment network. Given the hundreds of millions of records that have been breached to date, combined with the fact that there is no reason to think the number of data breaches will decrease, the need for end-to-end encryption is evident. US payment networks should consider end-to-end encryption as a long-term solution, with its official unveiling starting in the short-term.
Why isn't encryption ubiquitous?
With all of the benefits that encryption offers, why are there not many more large-scale encryption successes? While many of the encryption hardware appliances are touted as plug-and-play, getting encryption to work in the enterprise is a significant undertaking. Effective encryption requires many things, including the following:
* Attention to detail
* Good design
* Good project management
* Comprehensive documentation
* Responsible ownership
Many companies are simply not willing to commit sufficient time and effort. This has created the situation where many of the encryption roll-outs that have been attempted have been nothing more than stop-gap solutions to keep the auditors and customers happy. Simply getting it done often takes precedence over proper key management, documentation, processes, etc. These and more combine to help impede encryption implementations from becoming ubiquitous.
This effort to simply get it done does not jive with an effective and optimally deployed encryption solution. The problem is that such a reactive approach to encryption often results in a highly fragmented encryption infrastructure deployment, which may likely collapse upon itself not long after deployment.
In fact, Eric Ouellet writes in Tactical Deployment Scenarios for Corporate Encryption [registration required] that organizations should understand that it may take two or three years to complete all the activities involved within the more-complex encryption deployment scenarios. This is primarily due to internal political sensitivity, application testing and workflow or database use modifications. Organizations are recommended to break their encryption projects into smaller, more manageable portions, while keeping the bigger picture in mind when deploying solutions to address their encryption requirements. This combines both tactical and strategic planned implementation which helps to ensure the overall success of the endeavor.
According to the PGP 2009 annual study of U.S. enterprise encryption trends [pdf link], only 25% of US organizations have an encryption strategy in place that is enforced enterprise-wide. Part of the reason may be that companies are often terrified that encryption can lock them out of their own data. For that reason, some firms prohibit employees from using encryption on corporate assets, as they see it as a means to keep secrets from them. But that concern is a non-issue in a well-designed encryption program. This fear can be readily addressed with stringent cryptographic administration policies-procedures, and also by implementing key escrow and skeleton key components. The policies-procedures help to ensure proper cryptographic key management and administration and identify responsible key custodians; and key escrow helps to recover keys and also critical data in the event of an emergency.
One of the first to obviate companies from being locked out of their own data was PGP Corp. with the use of an additional decryption key (ADK). Note that in truth, it is an additional encryption key; as decryption is done by a private key. However, the terminology additional decryption key and its acronym have stuck.