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 organization 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