Evan Schuman's StorefrontBacktalk

Joel Weise is a Principal Engineer and Chief Technologist for the Sun Microsystems GSS Security Program Office. Prior to that, Joel was a security practitioner with Visa International where he established the original IT security department and worked in the R&D and Risk management departments.

Although there are many qualified security assessors (QSAs), a few who simply do not have the background and expertise in systems security manage to distort the original intent of PCI.

I often hear of QSAs that simply use PCI as a checklist, without thinking about an organization’s overall security posture or architecture. For instance:
• Do you or do you not have an antivirus package?
• Do you or do you not have a firewall?
• Do you or do you not have unique user IDs?

Great. But a good QSA would ask not only if an antivirus package existed or if a firewall appliance was installed or if a unique user ID policy was followed, but also how these were designed, architected, implemented, configured and monitored. In addition, a good QSA would ask to what security policy must applicable operational procedures adhere and whether anyone looks at the alerts and logs generated by the antivirus or firewall products.

When these questions are not asked, a poor understanding of the intent of PCI is typically at issue. But is this the result of a lack of qualification on the part of the QSA? Or is this poor understanding of PCI just one component of a larger problem where the inherent ambiguities of PCI are reflected in assessments? Or, worse still, is it because a QSA can both assess an organization and function as a consultant—someone who is available to remedy flaws uncovered in an assessment (which can, perhaps, suggest ulterior motives)? I would say that many of the current problems with PCI are a result of all of these possibilities.

Given the questions that I hear regarding how a QSA should apply PCI, it is clear that some QSAs are simply not qualified to function as security assessors. This is problematic in and of itself, but when we add in the issue that a QSA can not only find fault with an organization’s compliance with PCI but turn around and sell a solution to address out-of-compliance findings, it’s not unreasonable to question that person’s motives.

The obvious ambiguities we find in PCI complicate matters. But at the base of the problem are the associated struggles to address an organization’s insistence that its solution satisfies PCI when a QSA will not accept that solution. Although the PCI Security Standards Council is chartered to evaluate these ‘disputes,’ what we often see is the council’s deferral to the QSA.

For example, the FAQ on the PCI Security Standards Council Website (https://www.pcisecuritystandards.org/) lists the question, "What is meant by ‘adequate network segmentation’ in the PCI DSS?" The response, "….the PCI Security Standards Council is not able to offer an opinion about how your organization can achieve adequate network segmentation since it requires an understanding of security features and controls implemented in your environment. We encourage you to contact a Qualified Security Assessor (QSA) to assist in scoping your cardholder data environment and recommend methods specific to your organization to help reduce the scope of your PCI DSS assessment…."

What if your QSA thinks that segmentation must be done via physical separation and you are using a virtualization technique? Who is the ultimate arbiter here?

The Key PCI Questions

Many people ask me, "How does PCI really work? Why does it appear as a simple checklist? How do I ‘pass’ a PCI assessment (or better, why didn’t I pass my assessment)? Why is it such a hassle? What are compensating controls?"

All of these questions are quite understandable, given what PCI has morphed into and how the cottage industry that has grown up around it has interpreted PCI. To help you understand what PCI is and is not—right or wrong—here are some of my thoughts.

First off, some personal background, to give credence to my stance. I spent my formative years at Visa. It was great fun being on the bleeding edge and inventing new, innovative ways of greasing the skids of worldwide commerce. I still look back quite fondly on those days. I participated in the creation of many of Visa’s internal and external security efforts, including erecting the first security office internally. I also participated in the development of technology such as SET, EMV and the Open Platform chipcards. One of my favorite activities was working on technology risk.

Among other reasons, PCI was originally developed as a response to some of the early attacks on e-commerce sites. Merchants often would rush to build their e-commerce sites without giving much thought to the security of those sites. As with many things in life, it sometimes takes a catastrophe to get people thinking about the issues and risks at hand.

When e-commerce sites started to experience external attacks from the Internet, it was recognized that credit card holders, banks (both acquirers and issuers) and Visa (and other brands) were at risk for basic fraud. But more importantly for Visa, such attacks had an adverse impact on the brand. Trust in the brand and in merchant-bank-interchange relationships is paramount. PCI was the card associations’ response to this. It attempted to recommend best practices for securing sites.

The goal of PCI was to instill trust in e-commerce in general and in the brand and its merchant-bank-interchange relationships and capabilities that support e-commerce in particular, thereby enabling the reduction of risk and liability for the various participants (i.e., Visa, the banks and merchants). The issue of trust is critical to the success of e-commerce. It doesn’t take many poorly designed e-commerce systems that could enable identity theft to turn people away from the Internet as a safe
and sane place to do business.

PCI is a living standard. It is intended to grow over time and be flexible enough to allow the use of new technology (e.g., virtualization). This means that a QSA should not disallow the use of new technology such as virtualization simply because there is no provision within PCI explicitly allowing its use. It also means that a good QSA keeps abreast of current technologies and keep an eye out for future possibilities and how they affect the security of both the data and the systems that data resides on. A better QSA expands upon such knowledge and seeks to understand how new technologies can be leveraged to better secure an infrastructure.

Its intent was to ensure organizations implement a comprehensive security architecture. In other words, PCI is not a checklist but rather a baseline against which one can evaluate their security posture or architecture. It is not a hard and fast list of mandatory elements dictated by the powers that be. The intent is to ensure that a holistic security effort exists and includes various security elements and constructs to limit the threats and risks to sensitive information and processing resources.

Being a QSA means understanding security architecture for what it is—an art form. QSAs must be capable of understanding how PCI can be implemented in an unlimited number of ways. This is not to say that any organization that states they have a security architecture, published security policies, a complete security awareness training program, and manages and monitors their systems will necessarily comply with PCI. But those that have a security program that exhibits such characteristics have a better chance of satisfying PCI.

Besides getting hassled about PCI in general, most questions I get involved compensating controls. According to version 1.1 of PCI, "Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a technical specification of a requirement, but has sufficiently mitigated the associated risk."

This statement really gets to the core of PCI. For example, if you do not have an anti-virus system enabled, what compensating controls do you have that will prevent the spread of a virus and more importantly, prevent the disclosure, destruction, or loss of integrity of some sensitive data element? Possibly you are using a hardened Unix OS that is not "commonly affected by viruses." The question here would be, "If I’m using a hardened Unix OS, do I even need compensating controls?"

So what is a compensating control? For better or worse, this is left up to the QSA to determine, And where does that leave the organization being assessed?

The good news here is that the intent of compensating controls is to allow an organization undergoing a PCI assessment to argue that the particular controls they implemented have "mitigated the associated risk." Thus a risk analysis indicating that the controls put in place do in fact reduce risk should be sufficient justification to allow those controls to be used, assuming that a QSA is convinced the reduction in risk is adequate.

One of my favorite is "Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters." Buried inside here is: "2.2.1. Implement only one primary function per server (for example, web servers, database servers, and DNS should be implemented on separate servers)."
Let’s forget for a moment the issue of why a requirement for passwords and security parameters includes a process separation requirement. I have heard this interpreted by QSAs as meaning any and all functions related to credit card processing must be on physically separate servers.

Notice that PCI does not make any mention of physical separation. The original intent here was to ensure compartmentalization of risk by isolating sensitive data. That of course is a reasonable goal. A good QSA should have a solid understanding of security architecture separation techniques. And one of the most popular today is virtualization. Thus virtualization is a reasonable security separation technique and a good QSA should consider a properly architected and configured system using it to be in compliance. Yet, many QSAs do not understand virtualization and then reject its use out of hand.

Key Management

One of the more critical yet esoteric requirements of PCI covers key management. "Requirement 3: Protect stored cardholder data" includes 3.5’s "Protect encryption keys used for encryption of cardholder data against both disclosure and misuse."

Unfortunately, this is yet another case of a laundry list of requirements. And of much greater concern for one being assessed, how many QSAs are actually qualified to evaluate cryptographic systems and operational key management processes?

Many people think that encryption of data is a general panacea for addressing all threats of confidential data disclosure. Encryption done properly will certainly help to address this, but often overlooked is the necessity for solid key management processes. A failure of key management will most likely nullify any benefits derived from using encryption.

Let’s look at just a few of the key management requirements listed in PCI. 3.5.1 notes that access to keys must be "restricted" and 3.5.2 states that one must "store keys securely."

Does this mean access to a public key should be restricted? Since PCI discusses encryption in a generic sense, we will put aside the discussion of public key [asymmetric] crypto-systems vs secret key [symmetric] crypto-systems for another day.

How would one go about restricting access to keys? And then how does one test that the restriction methods are adequate? Should keys be store securely via physical means such as locked in a safe or via logical means or both?

Cleartext secret key components, for example, are often stored on paper, tokens or chipcards. Must all of these be physically secured? It is left to the QSA to make the critical value judgments needed to evaluate the methods used for restricting this access and determine their adequacy.