Top 10 PCI DSS Compliance Pitfalls

November 14, 2018 | Sanjay Ramnath
X

Get the latest security news in your inbox.

Subscribe via Email

No thanks. Close this now.

Despite the fact that PCI DSS has been in effect for over a decade, and most merchants are achieving compliance, some of the world’s largest retailers have been hit by to data breaches. The sad truth is that achieving compliance doesn’t guarantee data protection, even for large organizations.

For example, more than five million credit card numbers were stolen in 2018 hacks of two major retailers. 

Earlier this year, I hosted a webcast with Jacques Lucas from Terra Verde (one of our partners) covering challenges and best practices for achieving and maintaining compliance with PCI DSS. In his role as a QSA, Jacques has "seen it all" in terms of what commonly causes stumbling blocks for organizations on their compliance journey, which he summarized in a slide covering the Top 10 Pitfalls for PCI DSS Compliance.

As a follow-on from the webcast, I wanted to dive into that area further to provide tips and best practices to help companies address those Top 10 Pitfalls for PCI-DSS. 

1. Improper scoping

The PCI DSS standard defines the scope of the cardholder data environment (CDE) as all of the systems, people, processes, and technologies that handle cardholder data. A common misconception is to overlook the systems that support and secure the CDE, and fail to include them in scope.

Specifically, any systems involved in managing the security of in-scope systems are also considered in-scope, and need to be secured and monitored. Some examples include: IAM servers; Domain controllers; Key Management servers, Firewalls/IDS/IPS systems; Log management/SIEM systems; AV Management servers and more.

Pro-tip: Segmentation and monitoring are the two critical success factors in avoiding the pitfalls associated with improper scoping. Isolate in-scope assets from the rest of your environment with granular network segmentation and access control policies. Additionally, monitor all access activity to validate compliance and respond to emerging risks.

2. Failing to patch systems regularly

PCI DSS requirement 6 outlines the need to patch systems on a regular basis. Additionally, it specifies that critical security patches must be installed within a month of their release. The challenge is that patching processes can be very disruptive, and even well-established companies can easily fall behind. For example, in one high profile breach it took the company more than four months to identify an unpatched vulnerability that provided a foothold for their devastating data breach.

Pro-tip: Identifying unpatched assets and applications is a must. Be sure you schedule regular vulnerability assessment scans and prioritize patching and remediation procedures for your in-scope systems. Monitor your in- scope systems with a combination of security controls including host-based and network-based IDS, file integrity monitoring, and SIEM event correlation.

3. Failing to audit access to cardholder data

PCI DSS requirement 8 outlines how to secure access to cardholder data, specifically requiring two-factor authentication for remote access to all in-scope systems. While many organizations have implemented two-factor authentication, they often fail to audit this access to verify that these controls are working as expected.

In fact, SecurityMetrics reports that insecure remote access was the largest single origin of compromise being used in more than 39% of investigated breaches against merchants.

Pro-tip: Implement two-factor authentication on all of your CDE assets. Schedule periodic audits against these assets, to verify that controls are working properly. Additionally, enable monitoring on all CDE assets to capture a baseline.

Finally, configure your SIEM to trigger alarms for all activity that falls outside this baseline so you can respond quickly to potential threats.

Source: 2017 SecurityMetrics Guide To PCI DSS Compiance

4. Failing to review and monitor audit logs daily

PCI DSS requirement 10 covers all of the implementation details for logging and log monitoring within the CDE. Unfortunately, these logs are worthless unless and until you have a process to review them and technology to support it. By reviewing logs on a daily basis, you’ll discover errors and anomalies that may signal a threat - before they do any damage.

Fact: It takes an organization an average of 206 days to detect a data breach2. If most organizations were successfully reviewing logs on a daily basis, they’d find breaches within hours rather than days (or, months).

5. Failing to shut down third party vendor remote access after use

Third party vendors often request remote access for a variety of valid reasons - to post, download, or transfer data,  to update systems and applications, or to troubleshoot any of the above. The challenge is lack of follow-up once that access is no longer needed, leaving gaping holes in your network.

Pro-tip: Automate the termination of third party access once it’s no longer needed. Regularly review accounts and their access level (especially the privileged ones) to determine if they’re still necessary. Monitor third party access and trigger SIEM alerts when activity is outside the norm. Keep asset inventories continually updated, and document vendor access requests to facilitate follow up.

6. Failing to identify and change vendor default configurations

2084 passwords. That’s the current number of default passwords stored on CIRT.net for over 500 different technology vendors. Failing to change the vendor’s default password leaves the door wide open to cyber criminals keen to steal credit card holder data to sell on the dark web.

Pro-tip: In addition to changing vendor default passwords, here are some additional best practices:

Change the name of default administrator accounts to ones that are unrecognizable as “privileged”

Change Wi-Fi configurations for Wi-Fi routers connected to the CDE (rename default SSID names, encryption keys, and SNMP community strings)

Develop, implement, and assess configuration standards for each of your in-scope asset groups

Disable unnecessary services and protocols

Monitor configuration changes to critical system files with File Integrity Monitoring

Source: Ponemon 2017 Cost of a Data Breach Study commissioned by IBM 

7. Obsession on putting things out of scope

It’s understandable that some IT teams would want to reduce the scope of the CDE, since that can shrink the cost,  time, and effort in achieving, maintaining, and demonstrating PCI DSS. There are a few techniques on reducing PCI DSS scope, such as reducing the number of systems that process cardholder data locally. As an example, tokenization eliminates CHD from being stored locally, within your environment by outsourcing to a payment services provider.

While these scope reduction techniques may help reduce some of your overall risk, they’re not a silver bullet. You’re still on the hook to verify and demonstrate that your customers’ CHD is protected, no matter where it resides or how it’s being managed.

Pro-tip: Don’t waste time obsessing over ways to narrow your exposure. Do the right thing and secure and isolate any systems that handle CHD, secure and monitor them. After all, your QSA may not agree with your narrow scope definition (even after all that hard work).

8. Failing to track where cardholder data is stored

Some merchants may mistakenly believe that outsourcing CHD storage will offset their PCI DSS responsibility. It doesn’t. In fact, even if you outsource payment processing to a third party provider, you’re still responsible for knowing and attesting to where and how the CHD is stored, managed, and accessed. And since some payment processing providers may conduct business globally, it’s essential to verify these details before deciding to outsource to them.

Pro-tip: Regardless of whether you’re storing CHD locally or outsourcing to a provider, ensure that you’re actively tracking where and how it’s being stored, who is accessing it, how they’re accessing it, and when and why they need to. Actively assess security controls with periodic vulnerability scanning, update inventories, and continually monitor activity to respond to threats and verify compliance.

9. Storing sensitive authentication data after authorization

PCI DSS mandates the protection of Sensitive Authentication Data (SAD) which is comprised of full magnetic stripe data, CAV2, CVC2, CVV2, CID, PINs, PIN blocks, and more. Cyber criminals put a high value on SAD or “magnetic stripe data” because access to this raw data enables them to clone stolen credit cards for resale.

Some merchants who rely on recurring billing may falsely believe that they must store all SAD for this purpose.  Instead, reduce your exposure by using a third party credit card vault and tokenization provider. In this setup, the CHD is replaced with a token during billing and payment authorization procedures.

Fact: Credit card numbers remain in the top 10 most popular types of stolen data traded on the dark web. The value of stolen credit card account numbers varies from $5-$110, with CVV data adding a $5 uplift, full bank info another $15 and a full package of name, SS#, birthdate, and other personal data adding another $303.

Source: Here’s How Much Your Personal Information Is Selling for on the Dark Web

10. Addressing PCI DSS compliance only during annual audit

Let’s face it. PCI DSS compliance is deadline-driven. This can often lull IT folks into only following good monitoring practices when an audit or assessment is approaching. The downside is that you’ll find yourself constantly playing catch-up.

As we know, security and compliance work is never done. Security and compliance are more easily achieved and maintained when they become embedded into your standard operating procedure.

Pro-tip: Consolidate event correlation and threat detection technologies into a single platform for continual assessment and automated compliance status reporting. Implement security platforms that enable continuous monitoring and vulnerability assessment to achieve sustained PCI DSS compliance.

In summary, remember that compliance is more of a journey than a destination. Considering the need for continuous due diligence, look for security approaches that support a rapid, scalable, and orchestrated response. Specifically, multi-functional security monitoring platforms simplify threat detection and response while also helping your team scale to meet the complexities of changing compliance requirements.

Thanks to our valued partner Terra Verde for their input and collaboration in developing this Top 10 list.

Glossary of Terms

PCI - Payment Card Industry

PCI DSS - Payment Card Industry Data Security Standard

PCI SSC - Payment Card Industry Security Standards Council

CHD - Cardholder Data

CDE - Cardholder Data Environment

SAD - Sensitive Authentication Data

AOC - Attestation of Compliance

ROC - Report on Compliance

SAQ - Self-Assessment Questionnaire

QSA - Qualified Security Assessor

ASV - Approved Scanning Vendor

CAV - Card Authentication Value (JCB)

CVV - Card Verification Value (Visa and MasterCard)

PAN CVC - Card Validation Code (MasterCard)

CSC - Card Security Code (Amex)

Sanjay Ramnath

About the Author: Sanjay Ramnath
Vice President, Product Marketing at AlienVault
Read more posts from Sanjay Ramnath ›

‹ BACK TO ALL BLOGS

Watch a Demo ›
GET PRICE FREE TRIAL