PCI DSS Compliance

The Payment Card Industry Data Security Standard (PCI DSS) is very prescriptive, which can make it difficult to comply with the letter, spirit, and intent of every control.

In this blog post, we’ll share Tevora’s tips for addressing 10 of the most problematic PCI DSS controls. These tips are based on our extensive experience assessing merchants and service providers of all sizes and levels of complexity for PCI DSS compliance since the standard’s inception in 2004.

What Makes a PCI DSS Control Problematic?

Here are some of the key factors we’ve used to identify problematic controls:

• During gap assessments, the control is almost never fully implemented.
• The control is difficult or expensive to implement, so clients cut corners.
• No provision is made for the auditability of the control; it may be in place but there is no way to independently verify it.
• Applicability of the control is misinterpreted. This is usually between Cardholder Data Environment (CDE) systems that store, process, and transmit card data versus other systems that do not handle cards but support PCI DSS requirements.

Tips for the 10 Most Problematic Controls

In this section, we’ll describe Tevora’s tips for addressing 10 of the most problematic PCI DSS controls. For each control, we’ll present the control requirement and requirement number followed by tips for addressing the control.

PCI DSS Requirement 1.2.1

Restrict inbound and outbound traffic to that which is necessary for the cardholder data environment, and specifically deny all other traffic.

Tips

The issue is twofold: traffic that is “necessary” is subjective, and both ingress and egress traffic need to be controlled.

Necessary traffic includes, but is not limited to:

• Card authorization and settlement.
• Remote administrative access.
• Log aggregation.
• Access to patch management systems.

It is common to see ingress control but not egress. Make sure you configure your firewalls accordingly and document the rationale for all allowed traffic.

PCI DSS Requirement 3.6.x

Fully document and implement all key management processes and procedures for cryptographic keys used for encryption of cardholder data, including those listed below.

Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at http://csrc.nist.gov.

Tips

The key management requirements include:

• Secure generation and distribution of symmetric keys and the use of key-encrypting-keys in select cases.
• Secure key storage and retrieval.
• Management of key lifecycle.

The most common issue is that keys are generated but never changed and there is no policy or procedure for changing the keys. Use a KMS where possible, especially if you are coding platforms that handle card data.

Another issue is key expiration, including:

• Confusion about what it means to retire a key. You are allowed to keep the key and use it for data retrieval. You do not need to purge the key or re-encrypt data.
• There is no plan for retiring or revoking keys. Understand the cryptoperiod for the cipher you are using.
• Do not roll your own crypto code. Use standard crypto libraries for established and reputable vendors and open-source projects.

PCI DSS Requirement 6.1

Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.

Tips

Process considerations are often lacking when assessing this requirement. There must be an established vulnerability management policy covering vulnerability identification and risk ranking. Do not just rely on your vulnerability scanning product to assign a criticality—there must be risk evaluation criteria built into your process for vulnerability identification.

Here’s an example of a good process:

• A vulnerability scanner is deployed with updated vulnerability signature data on a weekly basis.
• Vulnerability scans are conducted monthly.
• Scan results are reviewed by a committee, which identifies criticality levels and makes recommendations for addressing identified vulnerabilities.
• Remediation and a change ticket is created for approval and execution through the change control process.
• A process variance is created for vulnerabilities that will not be remediated, including documented rationale for the variance that can be supplied to an auditor.
• A change ticket is created for change deployment, change rollback if necessary, and a check to ensure that the change was effective.
• Periodic review of a threat intelligence source for vulnerability and threat information. Some attacks are not tied to a specific vulnerability but arise from system and network configuration. These issues will not come through on a vulnerability scanner, so a process to receive threat news, intelligence, or other kinds of risk information is required.

PCI DSS Requirement 6.2

Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

Tips

When faced with critical vulnerabilities, 30 days to patch can be way too long. However, many companies struggle with completing a patch and testing cycle within this window. The key here is to tie patching back to the vulnerability and asset management process as follows:

• Establish asset classification: Public services (internet-routable services listening on ports) should have the highest criticality classification.
• Critical vulnerabilities identified on high-risk systems should trigger a process to fast-track the approval, testing, and deployment of patches to these systems within the 30-day window.
• All PCI assets that don’t meet the above criteria can follow a different patching process if constraints exist.

It is possible to patch beyond 30 days and remain PCI compliant provided you establish a formal PCI compensating control (PCI DSS Appendix B) and the Qualified Security Assessor (QSA) or the person performing the self-assessment accepts the compensating control. Compensating controls for this requirement are common and should include vulnerability criticality as defined by the vendor—this is the inherent risk. The residual risk to the CDE and systems that support PCI controls may be different based on the structure of the network and system in question, therefore the residual risk is lower than “critical” and can be patched using a different process.

PCI DSS Requirement 6.4

Follow change control processes and procedures for all changes to system components.

Tips

All changes to production systems must be performed through a change control process that includes a description of the change to be made, direction on how to perform and rollback the change, and change validation steps. Other elements of compliant change control include:

• Approval for the change pending review of the security impact to card data.
• Testing of the change in a pre-production environment.
• Separation of duties between development, test, and production environments.

PCI DSS Requirement 10.5.5

Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).

PCI DSS Requirement 11.5

Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

Tips

These tips address Requirements 10.5.5 and 11.5.

You must deploy a dedicated file-integrity monitoring (FIM) solution to endpoints to prevent log tampering. This is different from the requirement requiring log aggregation. You cannot skip putting FIM on your endpoints and rely on log aggregation as the only means to ensure complete system logging.

Anti-virus solutions and OS services like Windows Defender usually don’t detect or prevent the tampering of logs. However, most current Endpoint Detection and Response (EDR) solutions will. This is not a control to leave to chance since being able to provide a complete log of what was accessed and when can drastically limit the scope of a breach investigation and your liability.

Test any solution you deploy.

A good free solution is OSSEC.

PCI DSS Requirement 10.6

Review logs and security events for all system components to identify anomalies or suspicious activity.

Tips

Auditing this control is often not possible since no record of daily reviews is made. You may have a 24/7 security operations center looking for alerts and responding to incidents but there is no way for an auditor to review this process in practice over a period of time.

This requirement has very specific sub-controls that should be included in a daily checklist. The best checklists are change tickets that get created and closed daily once the check is performed. Do not underestimate a low-tech solution here either: a binder with a daily sign-off sheet can be very effective.

The other concern is what constitutes anomalous or suspicious activity. There are no hard and fast rules for this so metrics need to be based on each specific environment. A baseline for “normal” behavior must be established and methods for detecting deviations from that baseline must be part of the daily checks. Good examples include:

• Login velocity: users or administrators logging it on unusual systems, multiple systems, or at unusual times.
• Password changes; failed and successful login attempt volume.
• Services stopping and starting.
• Network ingress and egress volume spikes.

PCI DSS Requirement 11.2

Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).

PCI DSS Requirement 11.3

Implement a methodology for penetration testing that includes the following:

• Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115).
• Includes coverage for the entire CDE perimeter and critical systems.
• Includes testing from both inside and outside the network.
• Includes testing to validate any segmentation and scope-reduction controls.
• Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5.
• Defines network-layer penetration tests to include components that support network functions as well as operating systems.
• Includes review and consideration of threats and vulnerabilities experienced in the last 12 months.
• Specifies retention of penetration testing results and remediation activities results.

Tips

These tips address Requirements 11.2 and 11.3.

The vulnerability management process needs to include not only vulnerability identification but the creation of an auditable record of what action was done to remediate or accept the vulnerabilities. Every vulnerability with a CVSS score 4.0 or higher should be addressed through remediation or acceptance through a documented process variance. The same vulnerabilities showing up month after month without being addressed is a common problem on PCI assessments.

To make sense of the vulnerability scanning and penetration testing requirements, it’s important to understand some of the key terms involved, including:

• Vulnerability scanning: enumeration and identification of a potential methods of attack against systems, including servers, workstations, network devices, and any other kind of host on the network. Results will include false positives, false negatives, and informational alerts, which may or may not be applicable.
• ASV scanning: PCI DSS requires that an Approved Scanning Vendor perform certain vulnerability scans—this is not something you can do yourself.
• Penetration testing: exploitation of vulnerabilities or the use of other methods to compromise the integrity of a system or the confidentiality of company data. Penetration testing provides validation of vulnerabilities through empirical testing.
• External network: hosts that are publicly routable from the internet and may or may not be listening on select ports.
• Internal network: hosts that are not publicly routable from the internet.
• Cardholder Data Environment (CDE): a subset of external and network hosts that store, process, and transmit cardholder data.

Here are Tevora’s recommendations for vulnerability management and penetration testing in practice:

• Perform quarterly ASV scans against external network and remediate items with a CVSS score of 4.0 or higher.
• Perform monthly vulnerability scans using your own tools against your internal and external networks and remediate items with a CVSS score of 4.0 or higher.
• Perform an annual penetration test against the external and internal network. Any web applications that handle cards must also receive a web application penetration test.
• If network segmentation is used, annual validation of each segmentation method (not each segmentation instance) must be performed. This is usually best paired with the annual penetration test.
• If there is a major system, application, or architecture change, a penetration test must be performed.

Other Requirements

These controls are commonly missed but there is no tip, special fix, or guidance needed—just make sure you have these in place:

PCI DSS Requirement 8.1.3

Immediately revoke access for any terminated users.

Finding user accounts for former employees is a huge red flag when doing PCI assessments. It shows that change control and access control is lacking. You must establish a process to deprovision accounts for terminated users—no exceptions!

PCI DSS Requirement 10.2.x

Implement automated audit trails for all system components to reconstruct the following events: all individual access to cardholder data; all actions taken by any individual with root or administrative privilege; access to audit trails; invalid logical access attempts, use of and changes to identification and authentication mechanisms; stopping or pausing audit logs; creation and deletion of system-level objects.

Each one of the 10.2 sub requirements is very specific so be sure and follow the requirements to the letter. Generally, it’s best to run through mock scenarios for past changes: pull up last month’s vulnerability scan, identify one of the vulnerabilities and ensure that change ticket was created for remediation. Find the authentication log for the administrator that performed the change in your central logging system. Validate that any log data that captures the details of the change is also present in the logs.

We Can Help

If you have questions about PCI DSS in general, or tips for addressing problematic PCI DSS controls, Tevora’s team of security specialists can help. Just give us a call at (833) 292-1609 or email us at sales@tevora.com.

About the Author 

Clayton Riness is a Principal Consultant at Tevora.