The Importance of a Complete Cardholder Data Environment for PCI DSS
A complete understanding of your cardholder data environment (CDE) is a cornerstone of a successful PCI DSS compliance program, but for that, you need to ensure you include all the systems, technologies, processes, and people that comprise it because if not, an omission or lack of controls applied could lead to non-compliance.
If you lack a clearly defined CDE, you may even be operating in a state of non-compliance right now without even knowing, and wouldn’t that make for a nasty surprise for you and your stakeholders when your next assessment rolls around? As PCI DSS QSAs, we’ve seen it happen.
To help you avoid this fate, we’re going to explain all you need to document and understand about your cardholder data environment—including what the PCI DSS requirements say you need—as well as the other risks beyond noncompliance that you run from incomplete knowledge.
The Risks of an Incomplete CDE
In our experience, many companies think they understand their CDE only to find there’s cardholder data (CHD) in more places than they realized—like in informal or unofficial business processes that lead to CHD being stored locally on desktops or in file shares that are outside of the “understood” CDE, whether it’s in spreadsheets, recordings backups, receipts/reports, and notes—whether they’re handwritten, printed, or digital.
That’s why—though you’re likely used to making periodic inspections of those areas that usually involve CHD are a good start—you should also be conducting regular inspections or interviews with a broader range of business process owners to discover any possible situations where CHD could also reside. If you don’t, you may open yourself up to:
- Missed Vulnerabilities:
- A lack of a complete and accurate system inventory is one of the most common shortfalls we experience with clients, and if yours is lacking, not only might those systems get skipped for the required quarterly vulnerability scanning and annual penetration testing, but the security gaps would be allowed to persist in those devices due to missing patches, etc.
- Misconfiguration of Devices/Systems:
- PCI DSS requires many explicit configuration settings for devices in the CDE, including password requirements, multi-factor authentication (MFA), and password storage encryption, among others, but if certain systems are inadvertently left out of the scope, they’ll not only be non-compliant way, but CHD storage, processing, or transmission may be left more vulnerable (which increases the risk of a breach).
What You Need to Know About Your Cardholder Data Environment (CDE)
To help discern those “hidden” spots—locations that may have been thought to be “out of scope”—where CHD may be so that you can implement the proper handling and safeguarding procedures, you can use scripts that search for it in file shares or local storage.
You can also use the PCI DSS Information Supplement: Guidance for PCI DSS Scoping and Network Segmentation, which not only provides guidance for reducing your CDE through the use of either segmentation within the environment or the use of third-party service providers, but also criteria for the three key components of the things that should be included in your CDE: personnel, business processes, and technologies.
Personnel
Take note of all of the people do handle and who could possibly handle CHD in the course of their normal daily duties—that includes:
- Customer service representatives;
- System administrators; and
- Database administrators, among others.
Business Processes
Among others, relevant processes include those for:
- Taking sales orders (mobile orders, telephone orders, or e-commerce);
- Taking payments for services rendered; and
- Any services you’re providing for clients that involve CHD.
Technologies
Technologies that store, process, or transmit CHD are your:
- Network devices, like firewalls, switches, routers, etc.;
- Systems, like servers, domain controllers, containers, etc.;
- Applications;
- Databases; or
- Any other technology that comes into contact with or is used to protect a client’s CHD.
PCI DSS v4.0 and Your CDE
Regarding the technologies specifically, the PCI DSS requires the inventorying of all devices that are included in your CDE. The new version of the standard still requires all the inventories from v3.2.1—though some do have new control requirement reference numbers—and those include:
|
Requirement |
Inventory Specifics |
|---|---|
|
Requirement 3.6.1.1 (formerly v3.2.1 Requirement 3.5.1) |
Any hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management |
|
Requirement 9.4.5 (formerly v3.2.1 Requirement 9.7.1) |
Logs of all electronic media with cardholder data |
|
Requirement 11.2.2 (formerly v3.2.1 Requirement 11.1.1) |
Authorized wireless access points, including a documented business justification |
|
Requirement 12.5.1 (formerly v3.2.1 Requirement 2.4, though there is some new language in v4.0) |
System components that are in scope for PCI DSS, including a description of function/use |
But PCI DSS has also added requirements for brand new inventories, which—in creating them—can help you become more proactive and better in managing your CDE:
|
Requirement |
Inventory Specifics |
|---|---|
|
Requirement 4.2.1.1 |
An inventory of your trusted keys and certificates used to protect primary account numbers (PAN) during transmission. |
|
Requirement 6.3.2 |
An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software (to facilitate vulnerability and patch management). |
|
Requirement 6.4.3 |
An inventory of all payment page scripts with written justification as to why each is necessary. |
|
Requirement 12.3.3 |
An inventory of all cryptographic cipher suites and protocols in use, including their purpose and where used. |
Of course, you’ll need to maintain all these inventories—keep them current and complete—to remain compliant with v4.0, but these new inventories will also help ensure the completeness of your CDE, as you’ll now be forced to search out these items and document them.
Take the aforementioned Requirement 6.4.3, which now requires a review of payment pages and an inventory of any scripts running on those pages. Before this new mandate, it was assumed you had a process like this in place, but in fact, you may or may not have been aware of the use of such scripts or whether they were the proper scripts—now that you’re required to know, it’ll help shore up the security of your overall CDE.
Get Further Guidance on Your CDE
When you don’t include all the people, processes, and technologies that interact with CHD in your CDE, it puts you at risk, not just of non-compliance with the PCI DSS standard, but also of missed security vulnerabilities that can lead to devastating breaches. But now that you better understand what inventories and components you need to include, as well as the relevant v4.0 requirements, you can move forward more confidently.
Still, if your organization is new to PCI, you may feel more comfortable using a company like Schellman to conduct a PCI DSS v4.0 Readiness Assessment or workshop with your Information Security Team, as we can assist you in defining your CDE and point out the lacking areas that need to be addressed to fully comply. The report we’ll provide will catalog your applicable controls and their compliance status, which you can then use as a punch list for the items that still need to be addressed.
If you’re interested in taking this step that will help to ease the angst and time required for your first ever assessment—or your first assessment against the new standard—contact us today.