Do QSA’s Understand PCI?

Posted: March 19, 2009 in Policy and Compliance, Security Governance

I guess that title should say “Can anyone clarify PCI?” or “Can we get some PCI consistency please?.  I find myself in discussion day after day on topics around PCI.

 

What is required for web app test?  Is it authenticated? Is it just a scan?  Is it just my external environment?  Is it only my card holder systems?

 

I know the council is trying to do their best with outlining the standards but there still is a serious lack of consistency across QSA’s and organizations.  I found this so frustrating that I developed the cartoon below to represent my opinion.

 

pci-compliance

Basically Mr. CEO here is not meeting PCI compliance and his QSA’s are all telling him something different.  Even better is the new standards and enforcement that all the QSA’s themselves are trying to understand?  Will any big enterprise be able to make compliance?

Advertisements
Comments
  1. bindu sundaresan says:

    Hey Jason,

    Hope you are doing well. Good blog. Check this blog out..lots of useful PCI information.

    http://blogs.verisign.com/securityconvergence/

  2. Jason says:

    Hey Bindu how are you these days?

    I looked at Branden’s blog and there are some good things listed. I think some of the problems with PCI can be explained pretty quickly just based on his “Art of Compensating Control” postings. For example, on April 8th, he points out two words/phrases “legitimate” and “perform a risk analysis”.

    The problem is the QSA is the one deciding what is legitimate. On the other hand the term risk analysis could mean anything. There needs to be some guidelines around these compensating controls that make then standard. Risk analysis needs to be defined better otherwise I could put 3 columns in an Excel and write “Low impact + Low threat = Low risk” with no data backing any of those ratings.

    The real issue is that everything is open to the QSA’s interpretation and there needs to be some consistency across organizations.

  3. Mark says:

    One area I believe where QSA’s have very differing opinions in “scope” is especially in the area of “on premise tokenization systems” where the on premise token system includes a database for mapping tokens, encrypted PANs, the encryption systems/tools to encrypt live PAN’s, some key management on the back and and related processes to manage DR and backup – all messy items and complex in themselves.

    All of these systems, and the related authentication systems and any place where the token can be used should be in scope under PCI DSS since the token reversal method/source is on premise on the same network as the applications and API’s calling it. If the tokens are static i.e. repeatable for each PAN then the methods to avoid replay and abuse should be in scope too. A leaked token in such a case is directly usable as a PAN to the systems it came from.

    As far as QSA’s go, there seems to be many gross misinterpretation however when it comes to the scope:

    Since the “Tokenization” system vendors mislead by stating they take apps out of scope, its assumed the apps are out of scope by the QSA’s – however, there is a major difference: Tokenization services – those where the devices send data in a one way fashion to a hosted service who then links to the card issues do take the apps out of scope – partially at least so long as there is no API that can reverse mapping back to the applications – which is the analog of decryption via a service. However these don’t apply to large merchants with in house tokenization systems. the coupling point for the PAN to the token is the tokenization system as a whole.

    So, when the Tokenization system is on premise, the solution has a completely different profile: the entire Tokenization system including its mapping technique, decryption hanlding, key management and process, algorithms to create tokens, key rollover and initial encryption should be in scope and scrutinized.

    Many of the QSA boards are rife with confusing posts on this matter – especially when compared to encryption which is also mistreated and often incorrectly explained, even in the QSA trainers own forum.

    I think there’s a big need for some clarification all round – and proper definition of the scope of where the QSA’s advice finishes and where true PCI scope starts. Especially with tokenization being popular simply from its misleading scope reduction claims.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s