Security Experts:

Don't Fall Victim to the Hidden Secrets of PCI Compliance

The latest iteration of PCI compliance regulations adds to the already increasing burdens of the typical IT security professional. With it comes fear, uncertainty and doubt for those looking to execute PCI compliance controls properly and in turn to preserve their jobs. I had a chance recently to present as a guest keynote speaker at the North America CACS ISACE conference on implementing sound compliance and audit controls for key management. This article provides valuable insight into a particularly challenging aspect of PCI compliance.

PCI Compliance TipsThe latest iteration of PCI compliance regulations adds to the already increasing burdens of the typical IT security professional. With it comes fear, uncertainty and doubt for those looking to execute PCI compliance controls properly and in turn to preserve their jobs. I had a chance recently to present as a guest keynote speaker at the North America CACS ISACE conference on implementing sound compliance and audit controls for key management. This article provides valuable insight into a particularly challenging aspect of PCI compliance. 

There is little doubt that a security compromise can cost jobs, especially for those whose responsibility security is. What’s more, ignorance is never an excuse for failure, and today’s compliance and audit requirements are proving to be complex and hard to understand, which often leads to security failures, even when IT managers think they are following appropriate guidelines.

Take PCI compliance for example—a complex arrangement of auditable requirements that dictate how to protect payment card data. Failure to achieve compliance can result in legal woes and fines, potential for data compromise and, worst of all, lost employment.

Maintaining PCI compliance requires balancing technology solutions and policies against auditing goals. This sounds like a straightforward process. However, achieving that balance means that both IT managers and compliance auditors must understand the intricacies of the requirements set forth by the PCI Council. Simply put, IT must put forth the technology that allows auditors to validate if a system is compliant.

While that may sound simple in concept, practicing that philosophy proves innately different. The biggest problem stems from interpretation of PCI regulations, or more appropriately, the misinterpretation of them.

A perfect example of that misinterpretation can be found in how PCI regulations address cryptographic keys and the management of those same keys. While some of the language used to describe the requirements is quite clear, it is open to interpretation. Worse, it is often overlooked altogether--especially by auditors who don’t fully comprehend the implications of each requirement. Let’s take a closer look at those specific requirements and how each can lead to a compliance problem, caused by nothing more than a misinterpretation or ignorance of the requirement.

• 3.5.1: Restrict access to cryptographic keys to the fewest number of custodians necessary.

• 3.5.2: Store cryptographic keys securely in the fewest possible locations and forms.

• 3.6.2: Secure cryptographic key distribution.

• 3.6.6: If manual clear-text cryptographic key management operations are used, these operations must be managed using split knowledge and dual control.

• 8.5.4: Immediately revoke access for any terminated users.

• 8.5.8: Do not use group, shared, or generic accounts and passwords, or other authentication methods.

The requirements above are arguably the ones that are the most difficult to implement, enforce and audit, simply because the majority of key management solutions do not offer integrated support for those situations. What’s more, most internal auditors tend to overlook the intricacies involved to make sure that compliance is fully in effect, simply because of the language used and the complexity of the requirements.

Take for example 3.5.1., this requirement seems simple enough on the surface, yet when you delve deeper into it, the requirement can become a nightmare. Most enterprises have to share access to cryptographic keys across multiple administrators, platforms and systems. It is the very nature of cryptographic keys that requires communicating systems to share the key for encryption and decryption schemes.

The problem stems from the sharing of that information, which has its true roots in how cryptographic keys are managed. In many enterprises, that management takes the form of a spreadsheet or other document, which can be accessed across the network. However, exposing that information to more than those that need to know creates a compliance violation. Simply put, better management needs to be implemented, along with encryption to protect that information. That in turn proves to be a difficult proposition, requiring validated third-party tools to make secure management a reality.

Much the same can be said about 3.5.2, 3.6.2 and 3.6.6. To meet these requirements, an auditable management solution must be in place, which not only protects keys, but oversees the access and provides the appropriate audit trail to ensure that a compromise cannot take place. That proves to be a challenge that is well beyond most homegrown solutions.

Add to that the requirements of 8.5.4 and 8.5.8 and you have a situation where there are many potential holes in compliance requirements. For requirements 8.5.4 and 8.5.8, the real threat comes from lack of appropriate administrative controls—where generic accounts are often created to make it easier to access information for administrators, while shared passwords sent across email or shared on an open FTP server tend to be the norm. The access to and responsibility for individual keys should be assigned to separate administrators to achieve separation of duties requirements. Yet in a quest for simplicity and expedience, many IT departments unknowingly violate those requirements, which also prove difficult to audit.

The answers to the above problems come in the form of intelligent and automated encryption key management, where technology can be used to solve the very problems it creates. The primary takeaway here is not to turn a blind eye to what may be considered simple requirements at first blush, but rather to tackle those issues head on by devising a holistic approach to encryption key management that meets the needs of auditors, while still providing IT with the access and controls needed to deliver secure payment card transactions.

The following are six typical use-case vulnerabilities where the need to manage the encryption keys for protecting data in transit becomes apparent—both in relation to specific PCI DSS requirements as well as industry best practices.

1. Shared Keystore Passwords: Administrators typically share keystore passwords across multiple keystores managed by a team, as well as with system and application owners, as they share oversight of managing a group of systems. This can lead to individuals having access to private keys for systems that they have no responsibility for managing, and frequently have no authority to use.

2. Multiple Access Points to Keys: Because of organizational failover, redundancy, and capability requirements—in both ecommerce and swipe terminal environments—systems must be able to recover and load balance. This requirement necessitates that the same private key and certificate are copied and placed across multiple systems. Generally this means that more than one administrator is involved and all have multiple points of access to the exposed key(s).

3. Private Key Manually Shared Between Applications: Organizations deploy technologies to monitor outbound network traffic (data loss prevention, customer experience and performance monitoring tools, for instance). Each of these monitoring applications must look at the data stream in order to perform its role. If this data is encrypted then the private key must be supplied to the system to allow it to decrypt the data so that it can be read.

4. Same Password Used Across Multiple Keystores: Administrators often use the same keystore password on multiple—sometimes hundreds—of systems across the infrastructure in order to more easily remember them for application and system maintenance. Each keystore contains the “secure” storage and access to the private key. Such a configuration represents a security risk and a violation of the PCI security standard. 5. Keystore Passwords Rarely Changed: Administrators often struggle to comply with corporate password rotation policies for keystore passwords (e.g. change every 90 days) and will often use the same password for years.

Subscribe to the SecurityWeek Email Briefing
view counter
Jeff Hudson serves as CEO of Venafi. A key executive in four successful, high-technology start-ups that have gone public, Hudson brings over 25 years of experience in IT and security management. Prior to joining Venafi, Hudson was the CEO of Vhayu Technologies which was acquired by ThomsonReuters. Prior to Vhayu, Hudson held numerous executive leadership posts, including CEO and cofounder of MS2, SVP of Corporate Development at Informix Software, CEO of Visioneer, and numerous senior executive posts at NetFRAME Systems and WYSE Technology. He started his career with IBM. Mr. Hudson earned a B.A. in communications at the University of California, Davis.
view counter