Mistakes with PAN happen! Data leaks, memory dumps, or debug logs can accidentally contain sensitive information and can leak data into unexpected places in your environment. It is now a requirement to incorporate into your Incident Response Plan the locating, managing, and protecting of PAN outside of its defined area.

On March 31^st, 2022 PCI DSS v4.0 was released. Today’s post is part of series of pieces we are publishing that explore the changes to the PCI standard and provide insight into what the changes will mean for your organization. All of our posts can be found here.

As we travel down this road to PCI v4.0 compliance, the final stop in the new Report on Compliance (RoC) Template is a new requirement related to your Incident Response Plan (IRP), 12.10.7. 

In a nutshell, IRPs will need to be updated to incorporate procedures for an incident involving the discovery of any Primary Account Number (PAN) stored outside of known locations.  Online QSAs have come across this scenario many times over the years. We believe this to be a good addition to the DSS as it requires companies to be prepared for this somewhat inevitable occurrence. 

The PCI DSS v4.0 outlines these specific elements which must be included in your IR Plan: 

• Determining what to do if PAN is discovered outside the CDE, including its retrieval, secure deletion, and/or migration into the currently defined CDE, as applicable. 
• Identifying whether sensitive authentication data is stored with PAN.  
• Determining where the account data came from and how it ended up where it was not expected. 

• Remediating data leaks or process gaps that resulted in the account data being where it was not expected. 

It is still clear in v4.0 that unless the entity is an issuer or supports issuing services, Sensitive Authentication Data (SAD), cannot be stored after authorization. This is the reason behind the specific step called out within the v4.0 Defined Approach Requirements to verify SAD was not stored inadvertently along with the newly discovered PAN. If you do find Account Data, (SAD or PAN), you must securely delete or redact that element of the Account Data as part of the remediation and document it as part of your incident. While not specifically called out within v4.0 in the Defined Approach Testing Procedures for this requirement, it is specified in the last bullet point in the Requirement that the intent is for leaked data or process gaps involving Account Data to be remediated.   

An Example 

Throughout the years, the most common occurrence has been the discovery of unexpected PAN data identified in log files. Let’s explore this requirement using an example to see why it’s important to be prepared and why documenting it as part of the IR plan makes sense.  

For the sake of simplicity, let’s say the log files contained encrypted PAN. The compliance manager and the developer both thought there was only truncated PAN in the logs.  The good news is that it’s encrypted; but what are the ramifications?  Doesn’t sound like it’s a big deal because it’s encrypted--but looks can be deceiving. The compliance manager states they may just decide to protect the logs as if they store cardholder data and according to PCI DSS requirements and document the location, but the impact requires a deeper dive.   

Let’s step through the required analysis: 

The first step of the procedure would be to do an analysis of the current state to gather more information in order to determine next steps. Some key questions to ask include:  

1. Where did this PAN and/or SAD come from?  How did it end up here?

2. Where are the logs stored?   

3. Who had access to the logs containing the PAN and/or SAD?  Did they also have access to decryption keys?  

4. Who accessed those logs over the prior year?   

5. What is the current retention for those logs; how far back does the storage go?     

6. Have the logs been backed up or moved to tape or the cloud?  Follow the bouncing ball…

7. If they were stored on a network or SIEM that had only connected systems, did our CDE expand as a result of this new repository? 

If later they determine they do not want to continue to store the data in the logs and go down the path of remediation, then additional questions come into play: 

8. Can we redact this data from the logs or our SIEM?  Or do we need to delete?

9. How can we demonstrate they were securely deleted? 

And finally, these questions need to be answered and documented within the incident regardless of the pending decision whether to continue to store encrypted PAN and/or SAD or securely delete: 

10. Is it possible we inadvertently logged sensitive authentication data along with the PAN?

11. How did this even happen?  Perform a root cause analysis.

12. How can we prevent this from happening in the future?  

Documenting the discovery of unexpected storage of PAN through the incident response process allows for a thorough analysis to be performed, documented, and reviewed. It also provides for responsible personnel, such as the CISO, to be aware of the incident so proper steps can be put in place to minimize the likelihood of it happening again. 

Conclusion 

Mistakes happen, we are all human. If they didn’t then security incidents would be few and far between. The integration of this requirement is a continuation of emphasis on the PCI Security Council’s desire to integrate requirements as part of a Business-as-Usual approach.  Documenting a thorough procedure will allow the Incident Response team to respond immediately and effectively without missing a beat.  

To summarize: 

1. Analyze how Account Data, PAN, or SAD landed in the wrong place.

2. Plug the leak.

3. Delete sensitive data (if required).

4. Determine root cause and prevent future occurrences. 

Requirement 12.10.7 is a future-dated requirement and won’t be mandatory until March 31, 2025. That said, in the real-world mistakes happen… get prepared sooner than later by integrating these improved procedures into your Incident Response Plan. Online’s team of Information Security Consultants is standing by to help with updating, creating, or even testing  your Incident Response Plan if needed.

Online is ready to assist you in developing your PCI program, helping unpack what the v4.0 changes will mean for your organization, and then designing a compliance roadmap to get you there. For additional insight and guidance from Online’s QSA team, explore our digital PCI DSS v4.0 Resource Center, where we have identified and dissected many of the significant changes and new requirements in the latest release of the PCI Standard.