Top 10 Pci Dss Compliance Pitfalls

W H I T E PA P E R : TO P 1 0 P C I D S S P I T FA L L S
W H I T E P A P E R
Top 10 PCI DSS Pitfalls

and How to Avoid Them
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. Here are the top 10 PCI DSS pitfalls we’ve seen, and how
you can avoid them.
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.1
1
Source: https://www.securitymetrics.com/static/resources/orange/2017-securitymetrics-pci-guide.pdf
©2018 AlienVault, AlienApp, AlienApps, AlienVault OSSIM, Open Threat Exchange, OTX, OTX Endpoint Security, Unified Security Management, USM, USM Anywhere,
1
USM Appliance, and USM Central, are trademarks of AlienVault and/or its affiliates. Other names may be trademarks of their respective owners.
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.
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
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.
2
Source: Ponemon 2017 Cost of a Data Breach Study commissioned by IBM https://www-03.ibm.com/security/data-breach/index.html
2
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.
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.
3
Source: https://www.experian.com/blogs/ask-experian/heres-how-much-your-personal-information-is-selling-for-on-the-dark-web/
3
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)
4

Top 10 Pci Dss Compliance Pitfalls

Uploaded by

Copyright:

Available Formats

Top 10 Pci Dss Compliance Pitfalls

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Top 10 Pci Dss Compliance Pitfalls

Uploaded by

Copyright:

Available Formats

W H I T E PA P E R : TO P 1 0 P C I D S S P I T FA L L S

Top 10 PCI DSS Pitfalls

2. Failing to patch systems regularly

3. Failing to audit access to cardholder data

4. Failing to review and monitor audit logs daily

6. Failing to identify and change vendor default configurations

7. Obsession on putting things out of scope

8. Failing to track where cardholder data is stored

9. Storing sensitive authentication data after authorization

10. Addressing PCI DSS compliance only during annual audit

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)

You might also like