PCI DSS Version 4.0: Responding to Sensitive Data Discovery Incidents

This blog was originally published by PKWARE here.

Written by Marc Punzirudu, Field CTO, PKWARE.

At the end of March, the PCI Standards Security Council (PCI SSC) publicly released the most recent update to the PCI Data Security Standards (DSS), version 4.0. While much speculation has occurred as to the contents of the new standards—and much of that speculation turned out to be correct—now it’s time to begin digging into the details and uncovering how to prepare for compliance. PCI DSS version 4.0 won’t officially go into effect for two years, but the wise among us know that that on-ramp is shorter than it seems. Now is the time to put solutions in place that will empower you to meet and maintain PCI DSS compliance with version 4.0.

Expecting the Unexpected

With the release of the new PCI DSS version 4.0, a number of clarifications and controls have been added based on industry assessment of evolving technologies, stakeholder feedback, and the results of breach investigations. PCI DSS is a baseline minimum set of controls designed to protect payment card data, and as technology evolves over time, protection requirements must as well. With version 4.0, for example, PCI DSS has shifted focus to objective-based requirements.

One of the new areas of focus is including cardholder data within the incident response procedures any time it is found in unexpected areas. Requirement 12.10.7 adds this to the standard as simply a “best practice” until March 31, 2025, after which it becomes a firm requirement for all organizations.

Requirement 12.10.7: Incident response procedures are in place, to be initiated upon the detection of stored PAN anywhere it is not expected, and include:

• 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

Finding What You’re Looking For

Performing data discovery on a system or within an application every quarter, six months, or worse, annually is not going to provide any assurances that this control is actually providing value to an organization. While the intent of the control is to ensure that organizations have a documented response when a violation of their scope occurs and the correct action is performed, it’s important to note that sensitive data being in places it doesn’t belong is and always has been a security incident. PCI DSS regulations may not have specifically called it out in the past, but card data that is found where it doesn’t belong should be treated as a security incident. Otherwise the entity is by default confirming that that location is approved for card data storage or transmission.

Find and Destroy (or Remediate!) with Automated Discovery

What can an organization do to better enhance its data security and governance program? Properly implementing these controls in a mature and automated manner can go a long way to increasing the security maturity of an organization, as well as providing a massive leap toward risk reduction, all while maintaining compliance. Still, the challenge remains to find data in places it’s not expected to be, especially when those locations exist outside of the defined PCI scope.

Performing automated discovery on workstations, servers, and other devices can help combat the data sprawl which is prevalent in today’s world. With many individuals who previously worked in offices now taking technology home, businesses have struggled to maintain processes and workflows that both secure the organization while also enabling productivity.

Fortunately, there are platform solutions capable of performing real-time discovery across a myriad of platforms, including all common user technologies, whether the organization considers the location part of the PCI scope or not. When data is discovered, these platforms can stream its events in syslog and other common formats, allowing organizations to properly alert on sensitive data discovery. This allows data discovery events to be handled in the same way that the security teams manage existing incidents, without the need for new or additional applications or complexity.

Any time data is detected, these all-in-one platforms further enable the information security team by automatically classifying, encrypting, redacting, quarantining, or even deleting the discovered data based on the location, user, type of data, or other criteria defined by the organization. This allows for an immediate response, which further supports the organization’s incident response process by allowing the teams the time they need to properly triage an incident with the confidence that the data has already been protected and/or devalued.

The world has certainly changed since the last major update to PCI DSS in 2018. Version 4.0 changes may seem like a lot to prepare for in only two short years, but you don’t have to do it alone.