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)
