Top PCI Ambiguities

[djnavetta]

Hello all, I am writing a paper for a security journal on ambiguities in PCI and their resolution. I am trying to get a sense of some of the more ambiguous sections of PCI. Ambiguities can be inherent in the actual wording of the Standard itself (what is "proper due diligence" under 12.8.3) OR ambiguities may arise when the Standard is applied to a particular situation (e.g. must satellite transmissions be encrypted under Requirement 4).

Can you give me your top 5 or 10 ambiguities that you have wrestled with (in real life)? Please identify the section, explain the ambiguity, and if it is an ambiguity as applied to a particular situation, please describe that as well (identifying info stripped obviously).

Much thanks in advance!

[dbergert]

There is a recent post her about actual requiring physical labels for requirement 9.7.1 - I think that to be a good example.

[jbhall56]

Keep in mind that the PCI DSS is the outgrowth of the Visa CISP standard. The Visa CISP standard was developed by a well known Big Four auditing firm for Visa. As a result, the terminology used has a lot of basis in accounting and risk management, as well as in security and technology. So, what a lot of people see as ambiguities are actually just a lack of understanding the various points of view that came together and were used to originally develop the standard.

While the PCI SSC has attempted to correct this through wording changes, their FAQ and the publication of white papers, there will always be what appear to be ambiguities if the reader does not have a diverse background in risk management, auditing as well as the technical aspects.

I have to admit, I have not thought about there being any ambiguities in the PCI DSS. Being a QSA, we are taught how to interpret the PCI DSS, so the ambiguities get resolved, so to speak. The SPSP certification training program also provide the necessary training for non-QSAs to remove the ambiguities.

However, the ambiguities you perceive can also be considered the flexibility in the standard to rapidly respond to the rapidly changing threat landscape. The threat landscape changes daily and it would be impossible for any organization to create an incredibly detailed standard and also keep it up to date. As a result, you get standards such as ISO 27001, FISMA, PCI DSS and the like that are somewhat open ended so that they convey the intent of the standard, not a detailed, step-by-step approach.

That said, I do want to take a moment to straighten out what you perceive as ambiguities.

Ambiguities can be inherent in the actual wording of the Standard itself (what is "proper due diligence" under 12.8.3) OR ambiguities may arise when the Standard is applied to a particular situation (e.g. must satellite transmissions be encrypted under Requirement 4).

As I stated earlier, the term "proper due diligence" is an accounting and risk management term. "Proper due diligence" is typically defined by the accounting people as a process used to minimize the risk presented by performing a function, either internally or externally. Typically, risk is much higher using outside third parties for services as you are relying on the strength of their internal controls to maintain your own control environment.

Due diligence involves a number of things. There is the obvious issue of the financial stability of the organization. But there is also the issue of whether or not the organization's control environment is sufficient to be an extension of your own control environment. This is the purpose of an AICPA SAS 70 report. This sort of report describes and tests the control environment of the outside organization to give reasonable assurance that the controls are appropriate and are functioning as designed. How often an organization conducts proper due diligence, is determined by the amount of risk perceived in the outside organization. The higher the risk, the more often your due diligence should be updated and then reviewed by management to determine if a change should be made.

In regards to encrypting satellite transmissions. While it was recently proven that satellite transmissions can be intercepted, the equipment and techniques used are well beyond your typically attacker. However, now that it has been shown to be possible, I would recommend that organizations begin encrypting their transmissions over satellite because the risk is proven to be much higher than most of us in the telecommunications field thought.

[jonassono]

There is a recent post her about actual requiring physical labels for requirement 9.7.1 - I think that to be a good example.

I suspect this reference is to one of my previous posts and the ambiguity in this example is the PCI-DSS statement in a FAQ "they do not require physical labeling of media".

When PCI-DSS states they do not require physical labeling, that does not mean that physical labeling of media is forbidden or should not be done - it simply means it is not a PCI requirement.

Typically, the PCI standard states what needs to be done and not how to do it. The "how" is left to the judgment of the information security specialist based on the merchant or service provider's specific circumstances, technical environment & infrastructure, backup/restore process and the collection of other unique variables.

However, let's imagine a public library full of unlabeled titles and periodicals, a grocery store with 100's of unmarked boxes, cartons and other packaged foodstuffs or a tape library full of unlabeled media reels, cartridges and CDs/DVDs.

Whilst one would think interpreting this PCI citation would be obvious to anyone who can see lightning and hear thunder, tis not so as I discovered - hence the ambiguity.

A final and personal comment on PCI-DSS ambiguities in general. There are far fewer ambiguities in the standard for those of us who are skilled in the art and apply sound business and technical judgment, based on years of dedicated career experience in the vocation of information technology.

[djnavetta]

Keep in mind that the PCI DSS is the outgrowth of the Visa CISP standard. The Visa CISP standard was developed by a well known Big Four auditing firm for Visa. As a result, the terminology used has a lot of basis in accounting and risk management, as well as in security and technology. So, what a lot of people see as ambiguities are actually just a lack of understanding the various points of view that came together and were used to originally develop the standard.

While the PCI SSC has attempted to correct this through wording changes, their FAQ and the publication of white papers, there will always be what appear to be ambiguities if the reader does not have a diverse background in risk management, auditing as well as the technical aspects.

I have to admit, I have not thought about there being any ambiguities in the PCI DSS. Being a QSA, we are taught how to interpret the PCI DSS, so the ambiguities get resolved, so to speak. The SPSP certification training program also provide the necessary training for non-QSAs to remove the ambiguities.

However, the ambiguities you perceive can also be considered the flexibility in the standard to rapidly respond to the rapidly changing threat landscape. The threat landscape changes daily and it would be impossible for any organization to create an incredibly detailed standard and also keep it up to date. As a result, you get standards such as ISO 27001, FISMA, PCI DSS and the like that are somewhat open ended so that they convey the intent of the standard, not a detailed, step-by-step approach.

That said, I do want to take a moment to straighten out what you perceive as ambiguities.



As I stated earlier, the term "proper due diligence" is an accounting and risk management term. "Proper due diligence" is typically defined by the accounting people as a process used to minimize the risk presented by performing a function, either internally or externally. Typically, risk is much higher using outside third parties for services as you are relying on the strength of their internal controls to maintain your own control environment.

Due diligence involves a number of things. There is the obvious issue of the financial stability of the organization. But there is also the issue of whether or not the organization's control environment is sufficient to be an extension of your own control environment. This is the purpose of an AICPA SAS 70 report. This sort of report describes and tests the control environment of the outside organization to give reasonable assurance that the controls are appropriate and are functioning as designed. How often an organization conducts proper due diligence, is determined by the amount of risk perceived in the outside organization. The higher the risk, the more often your due diligence should be updated and then reviewed by management to determine if a change should be made.

In regards to encrypting satellite transmissions. While it was recently proven that satellite transmissions can be intercepted, the equipment and techniques used are well beyond your typically attacker. However, now that it has been shown to be possible, I would recommend that organizations begin encrypting their transmissions over satellite because the risk is proven to be much higher than most of us in the telecommunications field thought.

Thanks Jeff, much appreciated. Although I am not sure we are disagreeing at the end of the day. For example, in general I agree with your definition of "proper due diligence," but I have also heard from QSAs that a letter from a service provider stating they are PCI compliant equates to "proper due diligence." No validation, no checking of controls, no risk measurement. That is why I think that term is ambiguous in PCI -- it is subject to multiple interpretations and potentially could mean something different in different contexts.

From a legal standpoint (I am a lawyer and my article coming out in the ISSA journal) these are exactly the types of interpretations that are going to be scrutinized by judges, juries, plaintiff's attorneys and regulators. How these decisions are made and the rationale for them may dictate whether an organization wins or loses in court (or at least may pose legal risk, which is typically not accounted for when the decision is made).

[jbhall56]

As an attorney, I would ask you if there is anything anyone can really do? Everyone sues everyone these days regardless of culpability.

Given that security is not an exact science, there will always be a certain amount of risk that an organization's management must accept. The questions will be was that amount of risk acceptable to a reasonable man and did the organization execute their controls to keep the risk at the acceptable level? It's the execution that seems to be the biggest problem since human error is no longer acceptable in our society. We are all human and fallible, but that just doesn't count.

One of the problems I have with statements from a number of Visa executives is their portrayal of the PCI standards as the 'Holy Grail' and the implicit understanding that it is the mythical 'silver bullet'. As a result, the expectation to the world is that the PCI standards are a complete, perfect solution that, when followed to the letter, absolutely keeps cardholder data safe, when, in actuality, there is no such solution. I think that is where your issue regarding ambiguities is located, witht he card brands' marketing of the PCI standards, not with the standards themselves.

Just my two cents. However, if you want more than two cents, I've written more about some of this on my blog at http://pciguru.wordpress.com

[ADail]

How about the term "connected". Systems that store, transmit, or process cardholder data.. or connected systems.

What exactly does that mean? Connected on the OSI Model? Pretty much all systems are connected at layer 1, does it start at layer 3?

The scope of IDS / IPS and File Integrity monitoring could change by half-a-million bucks depending on how that is interpreted.

[El_Luke]

I always found the standard's wording around pre-authorization CHD very ambiguous. Some requirements apply only to post-auth CHD, but what about other requirement's that don't specifically call that out? A reasonable person could read the standard and think they don't have to worry about pre-auth data, but that is not the case. That whole topic needs to be spelled out with specific examples.

[jbhall56]

I thought that pre-auth CHD had finally been dealt with in v1.2 in that v1.2 applies to all CHD, regardless of whether the CHD is pre-auth or post-auth?

[ADail]

PCI DSS is applied to CHD post-authorization. Pre-auth isn't full post-authorization. According to the person I spoke to today at the PCI SSC they have a working group looking at pre-auth.

[jbhall56]

I just had my recertification training and they told us that pre-auth is still open for debate. You're still required to protect pre-auth data with the same diligence as post-auth, it's just not covered in the PCI DSS - yet.