This blog is written by one of our Senior GRC Technical Consultant, Ben Dalton.
Last week I sat down with Craig Moores, head of SureCloud’s risk advisory practice, to discuss the new draft (version 4) of the PCI Data Security Standard in our “What to expect with PCI DSS v4.0” webinar. As a former Qualified Security Assessor (QSA), Craig provided some unique and valuable insight into how organizations might need to adjust their compliance program to best align with the upcoming changes—I highly suggest you take a listen to our conversation.
One topic that came up frequently during our discussion, as well as the audience Q&A, is the concept of scoping the cardholder data environment (CDE) appropriately. This is a crucial step in any organization’s PCI journey; if too broad, you may be spending unnecessary time and effort ensuring that PCI requirements are met on out-of-scope systems. Too narrow and you are met with an increased risk of compliance failure or, more importantly, a data breach. With this in mind, it’s important to accurately scope the CDE and ensure this is maintained. Also consider reducing the compliance scope as much as possible since reduced scope means saving time, resources and, ultimately, cost.
When determining the CDE scope, best practice is to assume that everything is within the scope of compliance, until confirmed otherwise. Start by defining and documenting data flows to map where cardholder data (CHD) is stored, transmitted, or processed as part of the business payment channels and work your way out from there. Essentially, the goal is to define all system components that form part of the cardholder data flow.
Once we understand these flows, we need to list the components. These typically include a combination of websites, network infrastructure, servers, applications, people, and other systems that process or transmit cardholder data. Remember that any system that connects to, has access to, or can impact the overall security of the CDE should be considered in-scope. Therefore, answering these questions forms the foundation of your PCI scope.
We all know that network segmentation is a great tool that organizations can use for preventing breaches and limiting the impact of a Threat Actor. Did you know it’s also a great way to reduce your PCI scope? If you have a flat network (or portion of your network), you might have cardholder data or processing systems mixed with infrastructure that doesn’t form part of a payment channel such as back-office systems. In this scenario, all systems would be considered in-scope for PCI and you’ll end up increasing your work effort required to be PCI compliant.
Segment payment processing activities and components appropriately and you’ll reduce your effort and increase your overall security posture—a win-win!
As with all security best practices, the rule of least privilege for individuals and systems is critical in reducing single points of failure or single attack vectors. This also allows organizations to achieve a greater level of control over access rights to sensitive information. By limiting which business departments have access to cardholder data, an organization can reduce its overall scope of compliance. For example, if a department doesn’t absolutely need access to cardholder data to perform its primary function, then don’t allow them access to the relevant system components that form the CDE. The fewer people who have access to cardholder data and the environment, the smaller your PCI scope.
It’s also important to consider the type of data to which each department has access. Marketing and customer service functions are likely to need some level of access to CHD to provide value to the business and its customers. But, do they really need to see full cardholder information? Probably not. Masked or truncated card numbers and anonymized/pseudonymized data will likely balance the requirements of the business and will keep your PCI scope to a minimum.
Want to really slash your PCI scope? Some organizations are eliminating CHD from being stored in any part of their environment by outsourcing payment processing activities to a PCI compliant service provider—the most common approach for this is by tokenizing the data. To put the process simply, tokenization is the process of substituting highly sensitive payment card information for a “token” which is a random set of digits (often derived from the original information) that cannot be decrypted or restored back to their original value.
Tokenization is a great way to reduce your scope of compliance from a storage standpoint. But remember that data transmission and processing still require analysis—including any payment processing vendors! If you’re interested in more information about tokenization vendors, I’d recommend taking a look at TokenEx.
Properly defining, managing and, where possible, reducing your scope is the first step in saving time, resources and costs during the PCI compliance process. If you’re interested in how SureCloud can help you save even more time and effort after you’ve established your scope, drop us a line—we’d love to show you how you can ditch the spreadsheets and work smarter!
Ben has spent the majority of his career in the IT security & GRC industry—both on the product side as well as a practitioner. At the Walt Disney company, Ben implemented processes and technology to help streamline and automate the PCI compliance program at Disney Parks & Resorts.