Sherri Collis & Steve Levinson
PCI DSS v4.0 was released in March 2022. For those of you keeping up with the changes in v4.0, you know that there was initially a new status called "In Place with Remediation," and it was going to be reported in both the Report on Compliance (RoC) and the Attestation of Compliance (AoC).
The PCI Community became concerned about the implications of putting this detailed information into the AOC, and the Council listened. During the 2022 North America Community Meeting in September, the Council announced that this status will no longer be included in the AoC. Where the specifications of this status aren’t yet solid, the initial thought for this would be to include it in an attachment or appendix to the ROC as “Areas of Improvement.” This is great news, and more will follow on this topic once more is known.
Note: If you missed the Community Meeting you can get up to speed on highlights from each of the three days: Day 1, Day 2 and Day 3.
The blog post that follows provides information on “In Place with Remediation” based on the PCI DSS v4.0 released in March.
There has been a significant change made to the PCI DSS v4.0 reporting template that all Qualified Security Assessors (QSAs) must use for those entities undergoing a PCI v4.0 assessment. These changes may very well affect both your Report on Compliance (RoC) and your Attestation of Compliance (AoC). Because organizations, our clients included, use the AOC to demonstrate their PCI compliance to their customers, we wanted to call something to your attention that we believe could potentially have legal ramifications for Service Providers. Typically, Service Providers have agreements with their clients that obligates them (usually via some sort of contract) to remain compliant with PCI through the duration of their contractual relationship.
The Source of the Trouble: In Place with Remediation
PCI v4.0 includes five “Requirement Findings,” or status results possible:
1. In Place
2. In Place with Remediation
3. Not Applicable
4. Not Tested
5. Not in Place
Did you do a double-take with the second one above?
‘In Place with Remediation’ is a new Requirement Finding the QSAs must select when the following is true for a requirement:
The requirement was Not in Place at some point during the PCI DSS assessment period of the entity, but where the entity remediated the issue such that the requirement was In Place before completion of the assessment. In all cases of In Place with Remediation, the assessor must have assurance that the entity has identified and addressed the reason that the control failed, has implemented the control, and has implemented ongoing processes to prevent re-occurrence of the control failure.
What Kind of Storm is Brewing?
Online’s RSP Practice has performed hundreds, perhaps thousands, of PCI assessments. We know how difficult it is to maintain PCI compliance on 100% of the requirements, 100% of the time. That’s one of the reasons we perform PCI assessments on an annual basis. Let us illustrate:
Were you able to provide the following items to your QSA in your previous PCI assessments at the beginning of the engagement?
- Current configuration standards inclusive of required detail
- Four quarters of (clean) external scans
- Four quarters of (clean) internal scans
- Passing penetration test (passing means including remediation of exploitable vulnerabilities and rescans)
- Up-to-date and accurate inventory
- Current network diagrams
- Current data flow diagrams
- Two firewall rule set reviews six (6) months apart
- Logs going back one year
- Evidence of your quarterly compliance reviews (rqmt 12.11)
Now think about whether these things have ever been an issue:
- A server wasn’t patched
- Unnecessary and insecure services were found on a server
- Antivirus wasn’t on a server
- Logs for a couple of servers weren’t being sent to the SIEM
- SIEM alerts quit triggering for the UNIX devices
- Password complexity rules weren’t configured to the company’s configuration standard and had some non-expiring passwords in use
All of these items are PCI requirements that we commonly see slip-through-the-cracks (which are addressed via remediation) during PCI assessments. Let’s face it, these gaps may surface in many organizations when:
- They are short-handed
- There are personnel or role changes
- Many changes taking place in the environment and/or with the business
- A reorganization occurs
Here’s where it gets “stormy.” With the new v4.0 reporting templates, the QSAs basically will have to ‘tattle’ on you by marking those requirements “In Place with Remediation” if they were perceived to have not been in place sometime since the prior year’s PCI assessment, as experienced by the QSA when they performed interviews, observations, system reviews, etc.
This reporting requirement puts the QSAs and assessed entities in a very uncomfortable position – the QSA Company wants to do ‘right by the client’ by not putting the client in a potentially financially risky position (by reporting “in place with remediation”) but at the same time needs to do what’s right by the rules established by the PCI Council. The interesting dichotomy of this situation is that it is based on the PCI Council’s desire to build compliance into their business-as-usual processes (so one can be thematically compliant all the time) combined with more thorough PCI assessments, yet it may drive a good number of these entities to use check-the-box QSA Companies to avoid being flagged with this potentially litigious status.
Where is “In Place with Remediation” Reported?
In the RoC Executive Summary (Section 1.8), the QSA must list every requirement that doesn’t meet the “In Place” status. This singles out which requirements were “In Place with Remediation,” “Not Applicable,” “Not Tested,” and “Not in Place.” These same statuses must be used in the AoC. The only difference is that in the AOC, the QSAs aren’t required to enter the actual requirement numbers that weren’t immediately in place upon assessment. This IS good news because you would be telling people outside of your organization where potential vulnerabilities might exist (e.g., inconsistent patching, scan timing issues, etc.)
What Could Go Wrong?
For Merchants: The impact on Merchants reporting their PCI compliance to their acquiring banks or Card Brands may vary from nothing at all to being quite a big deal. It’s possible that these financial institutions will provide less-than optimal terms for entities that reported they have possibly had PCI compliance transgressions/gaps in the past.
For Service Providers: There is potentially much more at stake for Service Providers who may be contractually obligated to their customers to maintain PCI compliance at all times. For these entities, there may be risks associated with contractual fines, lost business, or breach of contract.
Preparing for the Storm: Are There Any Easy Answers?
First and foremost, don’t sweat this just yet. No one is REQUIRED to undergo a PCI 4.0 assessment until 2024. That gives everyone in the industry time to talk this thing out and perhaps we will land somewhere slightly different. But in the meantime, our suggestions are pretty straightforward:
- Do work to up your game in terms of improving security posture such that you can feel that much more confident that you are maintaining 100% compliance 100% of the time (this is never a bad thing, as long as it aligns with business objectives).
- Merchants: Review your bank/Card Brand agreements. See if your terms/rates could be impacted if you were to find your ROC/AOC to have an “In Place with Remediation’ status.
- Service Providers: This is a great time to review your contractual obligations with your customers to gain a better understanding as to the perceived financial risk if you were to find yourself in this status. It very well could make sense to start working on softening this contractual language such that you just need to report PCI compliance, whether or not there had been a transgression in the past
Feel free to reach out to us as you have questions or want to commiserate, strategize, or just share your thoughts. We can be reached at email@example.com.
Submit a Comment