Have you ever felt frustrated about security compliance? Well, you're not alone. We've all got some kind of 'Kryptonite' when it comes to Compliance. I asked some of our InfoSec auditors to share their Kryptonite. Their answers focused on the pain du jour, PCI DSS new version 4.0 and 4.01. So, dear reader, let's get into it.

First up is Chris Camejo, Compliance Practice Lead:

Never Been Asked

"My compliance kryptonite is when an organization asks why we’re making them do something for compliance that they never had to do before. Often these are security controls that were approved by previous auditors. It makes me question my understanding of the framework (and sometimes sanity). Saying “every other auditor you’ve talked to is wrong” seems egotistical, so I often go back to the source material to check my understanding, but I usually find myself looking at a fairly clear requirement backed up by guidance documents and FAQs that often contain specific relevant examples."

"I’ve come to the conclusion after many years, that there are auditors out there that fall into the same trap as the organizations they’re assessing: They make assumptions about what a requirement means without really understanding it in context or looking at additional guidance (I hate to say it, but I probably was that guy earlier in my compliance career). This does a disservice to organizations being assessed, as they are faced with sudden audit surprises if they get a new auditor with a better understanding of the requirements than their previous auditor. Sometimes this works the other way as well. I find organizations doing things that are not required ‘for compliance purposes’ due to a misreading of the requirements."

There All Along

"There have always been misconceptions about how PCI DSS (and other compliance frameworks) define their scope and what is acceptable for certain requirements. Many of these misconceptions were addressed in a variety of guidance documents and FAQs that none but the most dedicated compliance nerds took the time to read and understand. I see many of the “changes” in the PCI DSS version 4.0 pulling information from the guidance documents and FAQs into the standard itself and thereby, consolidating what was always expected in one place where it is more likely to be seen. One example is the scope flowchart added to PCI DSS section 4 that has rearranged many organizations’ understandings of what is in and out of scope. The secret is this flowchart has been hiding in the PCI Scope and Segmentation Guidance document for years, where very few people noticed it and only now has it been brought over into the DSS itself."

New to You

"I’ve had quite a few clients blame changes on something that needs to be done to align with the new PCI DSS version 4.0 when the result of the change is something they should have been doing all along. On one hand, this means the changes are effective: they are forcing organizations to converge on a single cohesive understanding of PCI DSS scope and requirements instead of some organizations getting away with cut corners. On the other hand, as a consultant, it hurts to have to tell a client that they’ve been doing it wrong and need to rethink how they’ve approached compliance."

I’ve Been Framed

"As a practice lead, I’m often involved in presales engineering, helping scope compliance engagements for our potential clients. I regularly deal with organizations that are scrambling because compliance with a specific framework is contractually required by one of their partners or customers. Very often, I find myself trying to explain that the compliance framework doesn’t apply to their organization for one reason or another. This is often because the organization doesn’t handle the type of information the framework applies to, or their organization isn’t in the type of business that the framework applies to. The real reason though, is that the partner or customer asking the organization for compliance doesn’t understand what the compliance frameworks themselves and are asking the wrong questions. After dealing with way too many of these calls, I’ve put together a post explaining the applicability of the frameworks that are often applied inappropriately."  

Service Providers

"Per PCI requirement 12.8.5, merchants need to document service provider responsibilities, but getting this information out of service providers has always been difficult. New requirement 12.9.2 should make this easier as service providers are now required by PCI DSS to help their customers understand their responsibilities. There’s a catch though: Some large organizations are publishing responsibility matrices that leave more questions than answers (e.g., Microsoft Azure’s matrix has all of the x.1.1 and x.1.2 sub requirements marked as the sole responsibility of the customer, even for requirements where Microsoft has claimed shared or sole responsibility for other sub requirements). If Microsoft has responsibility for some sub requirements, then they must also be responsible for their own policies, procedures, and role assignment for those responsibilities as per the x.1.1 and x.1.2 sub requirements. Service providers have a long way to go to help their customers accurately understand what their responsibilities are."

Chris had quite a bit to say!

Next up is Lee Quinton, another long-standing PCI QSA and works in the United Kingdom.

Dragging Their Feet

"To Chris’ last point specifically, they are also running into the issue of their compliance being required in the next two to three months, yet the PCI Third Party Service Provider (TPSP) doesn’t need to comply for six to nine months, and they don’t have any kind of developed responsibility matrix to help their customer comply with requirement 12.8.5."

The trouble with PCI requirement 12.8.5 was echoed by every QSA I interviewed.

Next up is Linus Garin, PCI QSA. While he is TrustedSec’s youngest and newest QSA, he has amassed experience across several frameworks and industries.

Is This a MAP?

"I am also experiencing similar pain points regarding requirements 12.8 and 12.9. I am helping Chris make a TPSP responsibility matrix for a client and it is BRUTAL. Mapping out the responsibilities for each of their TPSPs feels like a guessing game, especially when the TPSPs don’t provide a version of their responsibilities or an AOC (Either they don’t have one or client is unable to collect from them for whatever reason). And for the TPSPs that do have their own responsibilities matrix, such as Azure and Cloudflare, like Chris said, there are some discrepancies within the matrix that create more questions than answers. There are controls that are marked not applicable for the TPSP when they clearly should be, such as 12.10 stuff. Do I follow their Responsibility Matrix or use “QSA judgement and interpretation” to override their responsibility matrix?"

"So, the client ends up with a TPSP saying one thing and a QSA saying another, which is not great for their experience (and ours)."

Next up is Illustrious author and QSA, Arthur Cooper (Coop).

Keeping Up With the Joneses

“You are CORRECT, Sir. In my very humble opinion, this issue with TPSPs has been the WORST part of my time as a QSA.”

Coop also seeks timely resolution of industry security standards with PCI. For instance, many currently approved POS/POI payment devices utilize Triple Data Encryption Standard (3DES) within the Derived Unique Key Per Transaction (DUKPT) scheme, but as of December 31, 2023, the National Institute of Standards and Technology (NIST) has deprecated this scheme and advised that organizations transition away due to security concerns and the availability of more robust encryption algorithms.

As the original author of the PCI DSS requirement 10 during his time in the PCI Council, Coop frequently asks the current council to clarify on various aspects of the standard.

Up next is Steph Saunders, PCI QSA and longtime security implementer. She has supported security controls across the enterprise, and sees many challenges at many companies with the overall coverage and consistent configuration of IAM, especially with MFA right now. 

Identify Yourself

“For companies that have existed through multiple rounds of technical innovation, many IAM configurations simply aren’t compatible nor centralized. Technical differences aside, the decentralized management also often means that disabling accounts in a timely, consistent, or transparent fashion is completely different for different systems.”

"Many compliance standards like PCI aren’t very prescriptive about how to configure MFA correctly (e.g., best practices for preventing the re-use of tokens). Many standards like PCI don’t yet include acceptable passwordless authentication, despite many existing mature options."

The Next XZ Utility Backdoor

"With new PCI requirement 6.3.2 requiring an inventory of all bespoke and custom software, how far must one go? For example, to how much detail must a company inventory and manage open source libraries? How about the libraries called by those libraries? How about five levels deep and to what level of assurance? Many companies don’t know where the diligence should end."

How much diligence would have prevented the XZ utility backdoor attack?

"Many companies are unsure which of their service providers are in scope for compliance. Very commonly, the manufacturers of operating systems (e.g., Microsoft) and network devices (e.g., Cisco) are treated as commodity providers and not also as service providers. But if those same providers don’t provide timely updates, they may still be the weak point for the next data beach. How far must due diligence go?" 

Next up is your blogger, Steve Maxwell, a PCI QSA amongst other standards.

What, These Old Rags?

What is my biggest compliance kryptonite? Like others have said, it is the challenge of tracking security coverage by TPSPs. Service providers publicly advertise the taking of compliance troubles away from their customers, but the fine print shared privately with their customers is often far more modest.

They are like royalty dressed ‘to the nines’ for the red carpet entrance. Once inside, when asked about their regalia answer with “What, these old rags?” Having it both ways is making it difficult for their customers to demonstrate their own compliance.

Many PCI customers are finding it necessary to demand better information than what TPSPs are currently offering. The PCI industry may need to hold TPSPs accountable to accurately documenting support for customer security controls. Until most TPSPs become more accurate, customers attempting to demonstrate their own compliance may be wise to demonstrate and document where their ability to impact security ends, and intuitively, where the TPSP is proven to be supporting or at least not allowing access or controls from the customer. It is not a perfect solution, but it is the only option that many dependent PCI customers currently have.

It is a Feature, Not a Bug

Reflecting on Chris’ ‘There All Along’, I call this as a problem of ‘no single source of truth’. For example, I see some reporting requirements within only a reporting template, only in the DSS, only in a FAQ, or only in a ROC template but somehow not in the SAQ D template.

Having truth in many places means that, at best, one should search all possible places before drawing conclusions. At worst, it means drawing a wrong conclusion from a single source when there are others. Suffice it to say, that I must keep a list of apparent contradictions across the various PCI sources. As much as many dislike the room for ‘QSA discretion’ in interpreting PCI scope and requirements, the need is so widespread as to be considered a feature.

 Document Control Limitations

If clarity is still lacking, the customer’s only option might be to test and document their limits in being able to impact the security of cardholder data. For example, if a payment processor that performs all storage of cardholder data does not claim to own all logical access controls to the stored data, the customer may need to list and test all users and any ability to access or administer access to data. If there is no access to stored data, then document that and hope that TPSPs soon become more accurate and helpful with their reporting.

Reference the Customized Approach Objective

My simplest method for interpreting confusing DSS controls is to read the customized approach objective. If the assessed entity is thoroughly addressing the objective, they are likely to be able to demonstrate coverage. Conversely, if an entity has met the PCI prescription within the defined approach, but they haven’t met the objective of the customized approach, then they are likely to be failing multiple other requirements. The Customized Approach Objective is the simplest way to avoid bad interpretations.

Dear reader, did any of this resonate with your experience? Our consultants provide help on all of the above, so feel free to reach out for help.