PABP vs PCI

[lyalc]

I'm assessing a client under PCI DSS, who is implementing a PABP certified application.

When I review the PABP Implementation guide, it says to use dmcrypt and LUKS for file system encryption (to hold logs), which uses a single password to define and manage keys.
This product also uses Oracle 10g and TDE to protect PAN in the database. 'Default' use of TDE/10g has any database admin with dba/sysdba privilege able to manage keys and the key wallet. (I know Oracle 11g permits use of HSMs et al, but 10g is not that advanced, key management wise)

However PABP 2.3-2.6 says products must meet PCI DSS 3.5-3.6, but there is no way a single user meets the intent of Dual Control or Split Knowledge.

Other then telling my client "sorry but you also need to address PCI 3.5-3.6" are there any views on other interpretations or options that meet PCI DSS intent?

thanks
lyalc

[jbhall56]

This is a common issue, not just with Oracle, but with other older versions of RDBMS solutions as well.

We get around it with a compensating control using logging of access to the keys, changing of the keys, accesses to the DB that result in decrypting of the data, making DBAs change their passwords every 30 days, limiting the number of DBAs that have access to the DB that contains the CHD, etc. Of course all of this logging needs to also result in alerts that operations must investigate.

[lyalc]

Thanks.
These are the sorts of suggestions I'm making, but the client's IT provider is saying "the PABP Implementation guide says we only need to do X".

Also, key management is a process, not totally solvable by technology alone, hence the need to drive changes in procedures as well as technology configurations.

lyalc

[jbhall56]

The PABP is one thing, but as we were repeatedly reminded in our last re-certification training, there is also PCI DSS compliance and those are not always the same things.

As a QSA, you are required to ensure that the PCI DSS assessment procedures are complied with regardless of whether or not the application in question is PABP compliant or not. Yes, the PABP certification and implementation guide helps, but those do not provide a pass on the testing of PCI DSS assessment procedures.

[wconway]

As I recall, the somewhat tortured wording around PABP/PA DSS is that when properly installed in a PCI-compiant environment, the PABP/PA DSS app will not be the cause of your being non-compliant. That is, the app itself is a good start, but it in no way is a silver bullet for PCI compliance.

[lyalc]

As I recall, the somewhat tortured wording around PABP/PA DSS is that when properly installed in a PCI-compiant environment, the PABP/PA DSS app will not be the cause of your being non-compliant. That is, the app itself is a good start, but it in no way is a silver bullet for PCI compliance.
I agree as this is my understanding too.
The Implementation Guide is intended to be a 'how to' manual to achieve the 'properly installed and operated' aspects of PCI DSS.
When that manual explicitly says to use single user account and role for database and file system key management, either the process of PADSS has failed or the PADSS goals are somehow flawed.

Basically, I have to toss out the whole PABP/PA DSS rating of the product as unreliable, and perform a fresh review the application in depth on top of reviewing the PCI DSS operational environment, and getting my client to implement PCI complaint key management despite the Implementation Guide.

lyalc

[GMagyar]

Being a software vendor and just creating a few PABP Imp Guides, I can say one thing......

We are somewhat left off the hook because of the specific terminology mentioned above. PCI Compliance is much more in depth than PABP, and provides better protection for the customer FROM THEMSELVES, as well as external threats. I applaud those QSA'a out there that take the steps above and beyond than just relying on a certification of a POS App. Well Done.