The “New” PCI DSS Is Coming Next Month

Not a surprise and really not that big a deal.

The Council announced on their blog that v3.2.1 of the PCI DSS will be released sometime next month.

No major changes just as they promised earlier this year on a QSA update call.  They will remove all of the deadline dates that have or will soon pass, they will update Appendix A2 to reflect changes in SSL and early TLS and do the requisite punctuation and spelling updates.

Advertisement

Audit Fatigue Is Real

I was talking with a client at a very large organization and they were lamenting about their audit processes.

“It’s like I get one auditor out of my office and another one is waiting.  All it seems I do these days is answer the same questions over and over and over again.” – Anonymous Auditee

I had to concur with their comment because I encounter this and similar comments a lot, particularly with IT personnel.

To address this, there have been a lot of schemes put together in the last few years in a vain attempt to try and reduce this audit fatigue.  These schemes would be great except for one little flaw – the scope they cover.

For PCI assessments, the scope is focused on the systems that process, store or transmit sensitive authentication data (SAD) or cardholder data (CHD).  But with most organization’s focus on segmenting PCI away from everything else to reduce scope, a PCI assessment will likely focus very narrowly on point of sale (POS) and little else.  But the PCI DSS brings a whole new level of detail to the assessment process.  Where most security standards ask if an organization has for example firewall configuration standards, the PCI DSS goes above and beyond by asking if they are implemented and followed and to prove it by reviewing samples of firewall configurations.

For Sarbanes-Oxley (SOX) audits, the scope of the audit covers systems and technology that have a material effect on the financial statements of the organization.  From what I have seen over the years, that has placed focus of the audit on the accounting systems and little else in the organization.  The result of the audit is to ensure that the information in those financial systems can be trusted to provide accurate information to the external auditors.

For HIPAA HITECH assessments, the focus is all about where patient information is processed, stored or transmitted and the security surrounding that environment.  This results on a focus on an organization’s electronic medical records (EMR) solution, health care monitoring devices and the networks that connect all of this to the hospitals and clinics.  As with PCI, most health care organizations have focused a lot on isolating their health care systems away from the rest of their systems and networks.

As a result of these differing foci, is it any wonder why some areas of the organization feel inundated with auditors and assessors?

But it gets worse.  Thanks to the certifying bodies for PCI assessors and HIPAA assessors, these people are taught to not trust any of the others’ work products.  Interestingly, accountants have a process in place to allow the reliance of others’ work product.  But given the positions of PCI and HIPAA organizations, is it any wonder that some people feel that they never get rid of auditors/assessors?

But to add insult to injury, the attempts to bring rationality to the situation have totally messed up the mapping of the various assessment processes by misinterpreting the requirements in each and then incorrectly mapping them together.  Having been involved in SOX, HIPAA and PCI assessments, I know the programs and I have found significant errors in a number of these attempts to integrate the programs.  As a result, there are a lot of people running around thinking they are doing a world of good and not realizing that they are actually doing more damage because they are missing tests and not conducting the tests to the proper level of detail.  So, is it any wonder why the PCI and HIPAA organizations do not trust the results of others?

Ultimately the problem of audit fatigue persists and is still not being addressed.  So here are my thoughts and a possible solution.

• All security standards focus on certain common control subjects such as change management, software development, device configuration standards/procedures, user management and other common controls. Audit/assessment planning will define the common control environment and all auditors/assessors will approve the common environment.
• The audit/assessment will use the lowest common denominator for testing (likely the PCI DSS), merge any special control tests from any other work programs and have that new, consolidated work program conducted for the entire common environment. This will ensure that the entire environment is properly assessed to the right level of detail by the right number of controls that all other auditors/assessors can reference.  The auditors/assessors will agree to the work program to be conducted.
• Any auditor/assessor is welcome to participate in the common assessment process.
• Sampling of anything is done to the AICPA’s haphazard sampling methodology.
• The audit/assessment will follow the AICPA principles outlined in AT section 101 as it pertains to non-financial audits. This will likely result in larger sampling as well as sampling done over a period of time (usually 12 months).
• The auditors/assessors are responsible for reporting the results of this common audit/assessment approach in their specific reporting formats.
• Evidence will be retained by all auditors/assessors involved unless that violates the client’s security or privacy policies/standards. Then the client will be required to comply with the various audit/assessment work paper retention and standards bodies review requirements.

With the common areas assessed, the auditors/assessors would be free to conduct the rest of their work programs as necessary covering their specific scope.

This is the only rational way I see this issue of audit fatigue getting addressed.