The PCI Data Security Standard (PCI DSS and PCI 2.0) is nothing more than a series of guidelines that constitute security best practice.
Companies that institute programs to better protect cardholders’ data can also improve and extend these efforts throughout their business, ensuring that all other sensitive corporate and partner data is better protected. As the new PCI Point-to-Point (P2P) roadmap points out, there are still significant threats to the data as it moves within and beyond organisational boundaries.
Encryption is a critical element of any security strategy and is widely leveraged to protect data and, when properly managed, satisfies a growing body of regulations like PCI DSS. The reality is that digital certificates and encryption keys are being used extensively to protect data and secure network communications more inside the firewall than outside to secure web browsing. Certificate-based encryption deployments have exploded within large organisations in recent years, where nearly every IT system and application relies on certificates for trusted communications.
Yet managing the increasing encryption key and digital certificate volumes has reached a tipping point as enterprises increase their encryption deployments. Poorly managed, lost or stolen encryption keys can lead to costly failed security audits, data breaches and unplanned system downtime.
PCI DSS and Key Management
The PCI standard provides specific guidelines for achieving and maintaining compliance. The twelve primary sections are broken into a number of requirements. Requirements 3.5 and 3.6 of Section 2 offers specific language that defines how encryption keys are to be managed in order to achieve compliance.
Note that the standard does not distinguish or suggest priority treatment between symmetric and private key management. Both key types must be properly secured in order to be PCI DSS compliant. PCI requirement 3 mandates proper key management to protect against “both disclosure and misuse” and must be fully “documented and implemented” for all key types.
When data is protected by encrypting it with a private key and a certificate, the key becomes the data that must be protected. If the key is not well managed and protected, the risk of data loss or theft increases dramatically. In many organisations, the individuals or admins who install the certificates to protect the data often have unfettered access to the private keys for those same certificates. This means that the certificates can be copied, used maliciously or given to a third party to do so. Such an oversight compromises the security of the certificate and the data it’s meant to secure.
This threat becomes particularly acute when data is protected by keys that reside in a container or “keystore” (or on multiple keystores) with shared, administrative access. The keys that protect the data are often accessible to multiple administrators with no audit or access controls, and are often distributed widely and insecurely within organisations. By failing to segregate the private key access from the certificate installation, organisations are derelict in the most basic security principle of segregation of duty and access control.
Private Key Management
Two of the twelve PCI DSS requirements apply specifically to the use and proper management of SSL certificates and the private keys they rely on to ensure protection of data in transit. Section two of the PCI standard mandates that cardholder data be encrypted when stored or transmitted over open networks. The data is protected as long as the decryption or private key is protected—as the encrypted data cannot be decrypted and consumed without the key. A lost or mismanaged key can mean that companies may become locked out from their own data.
How do typical organisations secure and manage private keys—the keys required to encrypt data in transit? How are the keys protected against loss, misuse or theft? These become especially important questions given that, according to Gartner, the majority of data breaches are executed from inside organisations. In most cases, these private keys are not being protected.
The PCI DSS requirements for private key management cannot be accomplished in an IT environment that relies on manual processes. There are both security risks and operational challenges when administrators attempt to perform these steps manually. The problem with administrators performing these steps manually is that doing so exposes organisations to a host of security vulnerabilities, either because the administrators are not following best practices (including those in PCI DSS) or because they have malicious intent.
In fact, in spite of best-practice suggestions and specific key management requirements in the PCI standard, private keys are not well protected—both from lax distribution processes as well as the poor and infrequent keystore password rotation practices—and are frequently protected with the same password across hundreds of administrative keystores. Administrators also often have direct access to the keystore(s) and duplicate the keys in them for distribution, and reuse them on other systems and applications throughout the infrastructure.
These keys—shared by all and protected by none—are, in essence, the keys to the kingdom. With them, an insider with privileged keystore access can, working alone or with an outside hacker, gain access to the protected data or even to the authentication (user name and password) information meant to secure it.
In its report, “Where Does End-to-End Encryption for PCI End?” Gartner recommends that companies encrypt all sensitive data in transit—even when the data is being transmitted over internal, private networks. This goes beyond what PCI DSS requires, yet is certainly a best practice. Gartner also specifically calls out the importance of properly protecting decryption keys, which for data in transit means private keys. This implies an inherent security risk in poorly managed private keys used to secure network traffic.
When SSL is used to encrypt data in transit, the certificate is used to authenticate the client to the server and then the public key contained in the certificate is used to encrypt a symmetric key that is used to encrypt the ensuing two-way communication.
Thus, if administrators are able to gain access to the “decryption key”, which in this case is the private key that resides on the server, they can access the symmetric key and decrypt the data. This can be done asynchronously if the network stream is captured. If the wrong person has access to or obtains a copy of that key, then the data is at risk and can be compromised.
The need to protect these keys with good key management and access control systems from hackers becomes even more significant in the context of Gartner’s other finding: “The Gartner survey found that retailers are mostly concerned about unauthorized access to their systems by insiders, not outsiders….
Insiders typically cause the most damage because they know where to find sensitive corporate personal, financial account and other information” and “As you secure your enterprise systems, remember that insiders with privileged and knowledgeable access can cause significantly more damage than an outside hacker acting alone.”
In most organisations, these private keys are not being protected from either external or internal threats. In fact, despite best practices and specific key management requirements in the PCI DSS standard, keys are not rotated at appropriate intervals and are frequently protected with the same password across hundreds of keystores.
Enterprise key management and accompanying initiatives have been among the most “hot-topic” IT and security trends in recent years. Yet, according to industry analysts, large organisations with vast encryption deployments are overly focused on protecting data and managing the encryption keys within specific technology silos (such as databases, file servers and endpoints). To be successful, enterprises need to view the encryption management challenge more holistically.
The cost of preventative measures – including automated management tools – is often far less than the total cost of a breach, particularly when long-term costs like lost business opportunities are considered.
According to The Ponemon Institute’s Cost of a Data Breach study, “The investment required to prevent a data breach is dwarfed by the resulting costs of a breach. With average breach costs totaling $6.6 million, the return on investment (ROI) and justification for preventative measures is clear.” If nothing else, fines and other financial incentives make a strong business case for a PCI compliance program.
Organisations should evaluate more enterprise-focused encryption management solutions. Such solutions must address enterprise digital certificate and encryption key management (ECKM) across the entire infrastructure, independent of the encryption provider, encryption asset, application or operating environment. The PCI 2.0 may be nothing more than a series of guidelines but they are ones the enterprise ignores at its peril.