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 defences 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 unauthorised 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.
* 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
* Organisations implementing encryption often lack formal documentation of cryptographic processes and procedures
* Organisations 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 US enterprise encryption trends [pdf link], only 25% of US organisations 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 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.
As stated already and as will be reiterated in this article, data encryption projects require attention to detail to the extreme. Project plans need to be created that are tactical and focused to the specific application of the encryption services needed. They should also employ concise strategic objectives and milestones.
If encryption is not done correctly, there can be negative impacts to the performance of applications, systems and people who are supposed to use it. It can also adversely impact existing Service Level Agreements with business partners, customers, service providers, and other third party entities.
Many encryption rollouts have failed due to the fact that the company did not give sufficient attention to the design and testing phases preceding implementation. Far too many companies think that encryption is plug-and-play, which it most often is not. Effective encryption roll-outs take time and require significant attention to detail, and cannot be rushed.
As mentioned previously, an effective encryption roll-out requires a strategic approach. Forrester's Paul Stamp writes in Adopting an Enterprise Approach to Encryption that there are two main considerations when adopting a more enterprise-wide approach to encryption. They are as follows:
* Make sure that users and administrators can use the system transparently and simply in concert with other operational processes
* Ensure that the organization can track and demonstrate that encryption requirements are effective and being carried out properly
Achieving this across all the areas where encryption is used is by no means a small undertaking. When creating an encryption strategy, note that encryption for different scenarios requires different approaches. Your data backup encryption approach will be quite different from your mobile device encryption, as will messaging encryption be different from database encryption.
Finally, many simply underestimate the administrative and technology overhead associated with the proper management of cryptographic keys and required compliance validation documentation. Also, when considering PCI, note that cardholder data can be not only on databases and file servers, but also on laptops, PDAs, USB, floppies/CD-ROM/DVD, and other mobile devices. Make sure all such applicable media is included in your encryption deployment.
Also remember that section 3.4.1 of the PCI DSS Requirements and Security Assessment Procedures stipulates the following: If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed independently of native operating system access control mechanisms (for example, by not using local user account databases). Decryption keys must not be tied to user accounts.
This is to ensure that anyone compromising user accounts cannot automatically have access to critical encrypted data repositories on the systems hosting those accounts.
The importance of encryption for mobile devices can't be overemphasized. Today's workforce is extremely mobile, and such mobility requires strong controls around the data that is moving about.
Documentation and Policies
An effective encryption deployment, like any other technology implementation, requires formalized documentation of relevant policies, process and procedures. The authors can't overemphasize the fact that encryption must be supported by optimal policies, process and procedural documentation as well as a formal asset risk management program. This will help to demonstrate that the work was adequately planned and supervised, and also shows that internal controls have been studied, valuated and can be accounted for.
The encryption policies must be endorsed by management and effectively communicated to end-users, business partners and all third-parties that handle sensitive data. If they can't comply with your policies, don't give them access to your data.
Also, the policy must be flexible enough to deal not with just merchant data on statically deployed systems, but also laptops, PDAs, mobile devices, and more.
Finally, policy shows that the work around the encryption project has been adequately planned and supervised and also demonstrates that internal controls have been studied and evaluated.
Encryption data discovery
Before you can start encrypting data, you need to identify precisely where all PCI and other relevant, requisite critical data elements are stored. This process should be preceded by having properly defined a formalized set of data classification and retention requirements. PCI and other data integrity compliance requirements should drive the criteria defining what is considered to be sensitive data, what constitutes acceptable protections for it, how long it should be retained, and how to securely destroy it when no longer needed.
An enterprise-wide audit of all data repositories should be completed, taking great care to ensure all possible data storage locations have been identified. Note that this is a significant undertaking for large enterprises, and the process can take a few months in larger organizations.
Some of the items to include:
* Create and maintain up-to-date network and infrastructure documentation that details all PCI related data flows as now required by the PCI DSS v1.2
* Manually review data flows within PCI POS application to find the origins of all PCI data collection including, but not necessarily limited to: card swipe data, cardholder information input into web pages or electronic forms, faxes, etc.
* PCI compliance staff should view relevant electronic data storage locations and verify they are not storing full track data, or what is also known as sensitive authentication data or magnetic stripe or chip data
* Validate any logical separation and protections between systems storing cardholder information and those that do not
There is no one size fits all or even one size fits most when it comes to data encryption. The method and type of encryption you decide to use is one that must be based on requirements specific to your organization. They should also be based upon industry standards and proven encryption algorithms as well as robust encryption key lengths. The authors can attest that the most successful encryption deployments are when the client drives the projects and brings in external expertise to assist when needed.
Disaster will often strike when clients have no idea of the encryption requirements and will look to encryption vendors to solve problems for them. Vendors can provide best practices and invaluable assistance, however their objectivity may be skewed; and they may be more interested in selling their product, rather than helping to achieve an optimal solution. Always remember that specific requirements must be driven by client requirements.
There are many different encryption types to consider, each with its own set of advantages and disadvantages. A list of some of the most common are:
1. Host-Based Encryption (at rest)
This is where data is encrypted at creation, and is the first possible level of data security. Even if the encrypted data is intercepted (either accidentally or maliciously), the encryption renders it unreadable:
* Can increase processing overhead up to 50%
* Requires additional processing power/expense
* Highly secure and well-suited to active data files
* Large-scale data encryption can be unwieldy and impact performance
2. Appliance-Based Encryption
The data leaves the host unencrypted, but then goes to dedicated appliance for encryption. After encryption, the data enters network or storage device. This is the quickest to implement but can also be the easiest to bypass:
* Not easily scalable
* Good quick fix - for extensive data storage encryption, cost and management complexity of encrypting in-band can increase significantly
3. Storage Device Encryption
* Data transmitted unencrypted to storage device
* Easiest integration into existing backup environments
* Supports in-device key management
* Easy to export encrypted data to tape
* Easy to implement and cost-effective
* Best suited to static and archived data or encrypting large quantities of data for transport
* Large numbers of devices can be managed from single key management platform
4. Database Encryption
* DBMS-based encryption may be vulnerable when encryption keys used to encrypt data are stored in the database table inside the database, and only protected by native DBMS access controls
* Users who have access rights to encrypted data often have access rights to the encryption-decryption keys. This creates security vulnerabilities because encrypted text is not separated from means to decrypt it. It also doesn't provide adequate tracking or monitoring of suspicious activities
* Key management and administration capabilities come as built-in features of the product
* Those who have a need for database encryption should read Cryptography in the Database: The Last Line of Defense, which is an excellent reference.
The two most terrifying words to those involved in encryption are key management (KM). Part of the reason is that many technical and security professionals work in their own fiefdoms and never really have to interact to create a solution. And just as in driving a car, one does not have to intimately understand the underlying technologies at work to operate them. In addition, management often doesn't clearly understand the technical consequences of the encryption requirements, and the technical engineers often don't clearly see the impact of the solution on the business.
This is not the place to outline a long-formal overview, but KM is essentially the generation, distribution, storage, recovery, and eventual destruction (or end-of-life) of encryption keys. Many encryption failures are due to ineffective KM processes. To give you a feeling for the importance of KM, the IT Compliance Institute notes that 80% of 22 SAP testing procedures related to encryption are about KM.
It should be noted that if your encryption effort is being driven primarily by compliance requirements, KM becomes even more important. An organization must be able to demonstrate the security of its entire KM lifecycle, from key generation, storage, renewal, and destruction. It has often been said that effective KM is as important as protecting the data itself.
Like all of encryption, effective KM policy and design requires significant time and effort. Start your KM effort by asking a lot of questions. Some of them include:
* How many keys do you need?
* Where are keys stored?
* Who has access to keys?
* How will you manage keys?
* How will you protect access to encryption keys?
* How often should keys change?
* What if key is lost or damaged?
* How much key management training will we need?
* How about disaster recovery?
Your organisation likely has many keys in use now that you hopefully already know about -- from VPN keys, to SSL, PKI, third-parties, and more.
We could write 50 pages on KM, but let's summarize some high-level steps. Your encryption roll-out must start with a requirements analysis. You need to define the business, technical and legal drivers of the requirements. All of the requirements must be clearly identified and analyzed. If not, we suggest you stop and consider engaging outside consultants who specialize in their proper analysis and formalization. We have seen far too many projects fail due to requirements that were never fully identified and analyzed.
Next, start thinking about the encryption architecture. Who are the important parties involved? What are the operating and trust models that you are going to use? An important and often overlooked point is application integration. Not every application you have will be able to seamlessly add or even support encryption capabilities. While encryption is much easier for newer web-based implementations, what about that POS application that runs off an AS/400? The POS vendor may be long-gone, may not have addressed PABP or PA-DSS compliance, or may not want to re-write their application. Once the architecture is detailed and developed, ensure that adequate security related testing is done prior to roll-out.
Also, ensure that encryption is part of your Disaster Recovery/Business Continuity Plan. Encryption functionality must be available 24 x 7. If your encryption appliance fails at 3:00 AM, a good BCP ensures that it does not bring down your entire merchant system and interrupt commerce. Also protection of encryption keys and encrypted data go hand in glove, and should not be overlooked when working through DR/BCP exercises.
Also, physical security is paramount. It should be noted that every vendor of network operating systems places the foundation of the network operating systems' security architecture at physical server level. If an unauthorized individual has physical control of your encryption appliance and encryption keys, that could be an utter disaster in the making.
Once you have completed those steps and your encryption program is deployed, you are still not finished. Your post-deployment plans are almost as important as your pre-deployment plans. All systems are subject to change -- and encryption is no exception. A well-designed encryption program should be able to seamlessly integrate new requirements without significant re-engineering of production systems. This includes upgrading systems to accommodate new releases, increase performance, capacity/availability requirements, hardware upgrades, and new end-user applications.
PCI DSS Key Management Requirements
PCI is superb at providing details on how to deal with KM. PCI DSS requirement 3 - Protect stored cardholder data creates the requirements. The specific encryption requirements refer to section 3.6 of the PCI DSS requirements and includes the following:
3.6.1 Generation of strong keys
3.6.2 Secure key distribution
3.6.3 Secure key storage
3.6.4 Periodic changing of keys
3.6.5 Destruction of old keys
3.6.6 Split knowledge and establishment of dual control of keys
3.6.7 Prevention of unauthorized substitution of keys
3.6.8 Replacement of known or suspected compromised keys
3.6.9 Revocation of old or invalid keys
3.6.10 Requirement for key custodiansWhile the PCI DSS give a good amount of background on the requirements, it is important and highly recommended to review additional documentation surrounding this topic. The PCI Council references the NIST Key Management publication (SP 800-57) as a guideline for managing cryptographic keys.
Encryption is often seen as a quick and dirty way to fix years of security neglect. Sometimes it is considered scary and difficult to understand. While encryption is extremely powerful, it can only protect your data when its requirements are properly defined, and its implementation is properly deployed.
If you follow that advice and ensure your technical processes align with your business processes, you will find that your encryption deployment is both effective and efficient. Hopefully this article has shown you that encryption is something to be embraced - not to be intimidated by.
Ben Rothke, CISSP, QSA ([email protected]), is a Security Consultant with BT Professional Services and the author of Computer Security: 20 Things Every Employee Should Know (McGraw-Hill Professional Education).
David Mundhenk, CISSP, PCI-DSS & PA-DSS QSA, QPASP ([email protected]), is a Security Consultant with a major professional services firm.