Adventures In PCI Wonderland:

An Engineer Goes Through the Looking

Glass

“Who Are You?” •  Michele Chubirka aka @MrsYisWhy •  Security architect, engineer,

analyst. •  Blogs and hosts Healthy

Paranoia, information security podcast channel of Packetpushers.

www.healthyparanoia.net •  Researches and pontificates on

topics such as security architecture and best practices.

Overview

•  Background of PCI DSS •  Compliance vs. Non-compliance •  Basics of Standard •  What’s New in PCI 3.0 •  The Jabberwocky: Scoping and

Compensating Controls •  Common Myths •  Getting it Right

“The time has come," the Walrus said, “To talk of many things:

Of PINs and POS and CDEs Of SAQs and ASVs

And why the sea is boiling hot And whether QSA’s have wings."

Please ask questions!

•  Proprietary framework released in 2004 by PCI Security Standards Council to ensure secure handling of credit card data.

www.pcisecuritystandards.org •  Founded by five global payment brands. •  Enforcement of compliance and penalties for non-

compliance determined by each brand, not the council.

•  Related standards include: Payment Application Data Security Standard (PA-DSS) and PIN Transaction Security (PTS)

PCI DSS: Payment Card Industry Data Security Standard

Why Does PCI DSS Matter?

2014 MILESTONES• The PCI Data Security

Standard (DSS) turns ten years old

• DSS 3.0 becomes effective and validation assessments start (January 1)

• DSS 2.0 expires and compliance validation against version 3.0 becomes mandatory (December 31)

Verizon 2014 PCI Compliance ReportINTRODUCTION2014 will be a pivotal year for merchants and service providers looking to comply with PCI standards.

A DECADE ON, AND MORE IMPORTANT THAN EVER

Payment card data is becoming more important as cards supplant cash, and as our DBIR data shows, it’s a prime target for attackers. As we are putting the finishing touches to this report, the FBI has issued a warning to retailers to be wary of “card-targeting malware” thought to already be responsible for the breaching of over 100 million people’s card data.1

The PCI DSS is designed to standardize and assess how organizations are protecting the card data they hold from this and other threats. The PCI Security standards apply to all organizations that handle cardholder data. The core standard, the PCI DSS, has been around for nearly a decade; and service providers, merchants, and financial companies of all sizes and from around the world have adopted it. PCI DSS is the most widespread and established standard of its kind: it’s broadly accepted, widely discussed, and it’s not going away.

So it’s widespread. But is it effective in achieving security? Our evidence suggests that it is.

ORGANIZATIONS THAT ARE BREACHED TEND TO BE LESS COMPLIANT WITH PCI DSS THAN THE AVERAGE OF ORGANIZATIONS IN OUR RESEARCH.

As we enter the tenth year of PCI DSS, there has been important progress. With version 3.0, PCI DSS is more mature than ever, and covers a broad base of technologies and processes such as encryption, access control, and vulnerability scanning to offer a sound baseline of security. The range of supporting standards, roadmaps, guidance, and methodologies is expanding. And our research suggests that organizations are complying at a higher rate than in previous years.

After an uncertain start, many organizations now feel comfortable with and better understand what the DSS is about, and accept that complying with it is not only a necessary part of accepting card payments, but also a solid baseline of controls for protecting cardholder data.

Most analysts agree that, while the PCI standards are imperfect, they have evolved to clarify expectations and address feedback from the industry, and today they provide an increasingly mature framework for organizations to work toward.

So why is PCI compliance still worth talking, and indeed writing a major piece of research, about?

$10B

$12B

$0

$6B

$4B

$2B

$8B

Global Card Fraud Losses ($Billions)

‘00 ‘01 ‘02 ‘03 ‘04 ‘05 ‘06 ‘07 ‘08 ‘09 ‘10 ‘11 ‘12Data from The Nilson Report, August 2013Figure 2: The cost of card fraud; data from The Nilson Report, August 2013

5VERIZON 2014 PCI COMPLIANCE REPORT

“Payment card data remains one of the easiest types of data to convert to cash, and therefore the preferred choice of criminals. 74% of attacks on retail, accommodation, and food services companies target payment card information.” - Data from Verizon Data Breach Investigations Reports (DBIRs), 2011, 2012 and 2013

Who’s Compliant?

Payment card data remains one of the easiest types of data to convert to cash, and therefore the preferred choice of criminals. 74% of attacks on retail, accommodation, and food services companies target payment card information.Data from Verizon Data Breach Investigations Reports (DBIRs), 2011, 2012 and 2013

COMPLIANCE REMAINS A MAJOR ISSUE

But our research also shows that the vast majority of organizations are still not sufficiently mature in their ability to implement and maintain a quality, sustainable PCI Security compliance program, and they continue to struggle to provide the required compliance evidence at the time of the annual compliance validation assessment.

There’s significant variation across the individual requirements, controls, and subcontrols; as well as across industries and regions. Despite a decade of discussion, clarification, and education, there are fundamental disagreements and misunderstandings around critical areas of security and compliance, including how to define the scope of compliance itself, and how compliance is assessed. Some even regard the DSS, even in its latest 3.0 guise, as taking fundamentally the wrong approach to security.

According to our research, only around one in ten organizations were fully compliant with PCI DSS 2.0 at the time of their baseline assessment. Despite the increasing maturity of the standard and organizations’ understanding of it, attaining compliance remains far from easy — and so it should. Protecting cardholder data is important and the threats to it are very real.

And the drivers for investing in security and compliance are more pressing than ever. The very payment card data breaches that PCI DSS was designed to help avoid are growing in frequency and scale, with compromised records often numbering in the millions. As consumers and businesses continue to ditch cash and do more of their shopping online, the risk and impact of breaches is set to grow further. The related disciplines of security and compliance are, consequently, still a top business priority.

100%

0%

50%

25%

75%

Percentage of companies that passed

2 3 4 5 6 7 8 9 10 111Number of requirements

% co

mpa

nies

12

11.1%

95.6% 95.6%

77.8%

71.1%

60.0%

51.1%44.2% 42.2%

31.1%24.4%

100.0%

11.1% of companies passed all 12 requirements

Over half (51.1%) of companies passed 7 requirements.

Figure 3: Percentage of companies that passed; dataset 2013

6 VERIZON ENTERPRISE SOLUTIONS

Pass or Fail? •  11.1% met all requirements of DSS 2.0 in 2013,

an increase of 3.6 percentage points from 2012. •  In 2013, companies were compliant with an

average of 85.2% of controls.

“…one in five organizations came close to complying — they passed 95%+ of controls. Of these organizations, more than half failed Requirement 11 [Regularly test security systems and processes].”

- From Verizon’s 2014 PCI Compliance Report

Does It Work?

Its effectiveness is determined by the organization’s implementation, not the auditor.

“Off With Her Head!”: The Consequences of Non-compliance

•  Lawsuits and countersuits •  Insurance claims •  Suspension of merchant status with

processor or in-depth assessments if breached.

•  Payment card issuer fines •  Possible government fines (depending

upon where you do business) •  Damage to reputation and business

“Will you, won't you, will you, won't you, will you join the dance?”

•  Any organization that accepts, processes, stores and/or transmits member-branded card data must comply.

•  It’s like a game of cooties, if you touch CC data, you’re infected.

•  Compliance with standard is a binary yes | no.

Example: Target Breach •  Target CIO “resigned” after breach

of 40 million credit card and debit records.

•  At least 80 100 lawsuits filed. •  Earnings down 46% in 2013 4th

quarter. •  Total losses could reach one billion. •  Reportedly validated as

“compliant” •  Target’s QSA, Trustwave, is also in

litigation with banks.

PCI DSS 101

Important Taxonomy •  Merchant – any entity that accepts payment cards •  Payment Card – card/device bearing logo of founding members of PCI SSC •  Issuer – entity issuing payment cards or performs, facilitates or supports issuing services. •  Service Provider or Merchant Service Provider (MSP) - furnishes all or some of payment services

for a merchant •  Payment Processor – type of MSP •  Acquiring Bank – connects to card brand network for payment processing •  QSA – qualified security assessor •  SAQ – self assessment questionnaire •  ASV – approved scanning vendor •  PAN – primary account number •  CVV – card verification value •  CSC – card security code •  POS – point of sale •  CDE – cardholder data environment •  ROC – report on compliance •  AOC – attestation of compliance •  AOV – attestation of validation •  Scoping – process identifying all system components, people and processes included in an

assessment From PCI DSS and PA DSS “Glossary of Terms, Abbreviations, and Acronyms” V. 3.0, January 2014

“Speak English! I don't know the meaning of half those words, and I don't believe

you do either!”

Sometimes PCI is a hill, and sometimes it’s a

mountain.

•  Six domains, 12 requirements

•  The goal is to reduce risk of fraud

•  Simple, right?

Validation Requirements •  Compliance vs. validation, what’s

the difference? •  Merchant and/or service provider

status •  Based upon volume of transactions. •  Method of acceptance •  Whether the merchant has ever

been breached. •  Varies by payment card brand. •  Can change. Expect stricter

requirements in the future.

Merchant Levels •  Level 1 – processes > 6MM Visa, MC or Discover

transactions annually, 2.5MM Amex, 1MM JCB •  Level 2 – 1 to 6MM Visa, MC or Discover, 50k to

2.5MM Amex, < 1MM JCB •  Level 3 – 20k to 1MM Visa or Discover card-not-

present transactions, >20k MC , <50k Amex •  Level 4 – Everyone else

Service Provider Levels •  Level 1 – All 3rd party providers (TPP), all data

storage entities (DSE) that store, transmit or process > 300k MC, >=2.5MM Amex, >300k Visa

•  Level 2 – DSEs < 300k MC, 50k to 2.5MM Amex, <300k Visa

•  Level 3 < 50k Amex

Visa Canada and Europe have slightly different rules.

Validation Requirements

•  Level 1 – ASV scan, QSA on-site assessment •  Level 2 – ASV scan, Visa SAQ, MC QSA/ISA on-

site assessment or assisted SAQ. •  Level 3 – ASV Scan, SAQ •  Level 4 – ASV scan if requested, SAQ Amex requirements differ slightly - https://www209.americanexpress.com/merchant/services/en_US/data-security

SAQ Validation Types •  Type A – Merchants who keep only paper reports or receipts with cardholder data, do

not store cardholder data in electronic format and do not process or transmit any cardholder data on their systems or premises. Does NOT apply to face-to-face merchants.

•  Type B - Imprint-only merchants with no electronic cardholder data storage, or standalone, dial-out terminal merchants with no electronic cardholder data storage.

•  Type C-VT - Merchants who process cardholder data only via isolated virtual terminals on personal computers connected to the Internet. This SAQ option applies only to merchants who manually enter a single transaction at a time via a keyboard into an Internet-based virtual terminal solution.

•  Type C – Those with payment application systems (for example, point-of-sale systems) that are connected to the Internet (for example, via DSL, cable modem, etc.) either because: –  The payment application system is on a personal computer that is connected to

the Internet (for example, for e-mail or web browsing), or –  The payment application system is connected to the Internet to transmit

cardholder data. •  Type D – All others

Caution: Make sure to carefully read the “Self-Assessment Questionnaire Instructions and Guidelines” document, not just the questionnaire itself.

PCI DSS Domains

1.  Build and maintain a secure network. 2.  Protect cardholder data. 3.  Maintain a vulnerability management program. 4.  Implement strong access control measures. 5.  Regularly monitor and test networks. 6.  Maintain an information security policy.

That Doesn’t Seem So Bad

Requirements 1.  Install and maintain a firewall configuration to protect cardholder data. 2.  Do not use vendor-supplied defaults for system passwords and other

security parameters. 3.  Protect stored cardholder data. 4.  Encrypt transmission of cardholder data across open, public networks. 5.  Protect all systems against malware and regularly update anti-virus

software or programs. 6.  Develop and maintain secure systems and applications. 7.  Restrict access to cardholder data by business need to know. 8.  Identify and authenticate access to system components. 9.  Restrict physical access to cardholder data. 10.  Track and monitor all access to network resources and cardholder data. 11.  Regularly test security systems and processes. 12.  Maintain a policy that addresses information security for all personnel.

PCI DSS V3.0 is 112 pages

•  That doesn’t even include the additional guidance documentation.

•  Every requirement has sub-requirements, testing procedures and now guidance (new in 3.0).

•  Example: requirement one has 23 sub-requirements.

Payment Card Industry (PCI) Data Security Standard, v3.0 Page 24 © 2006-2013 PCI Security Standards Council, LLC. All Rights Reserved. November 2013

PCI DSS Requirements Testing Procedures Guidance 1.3 Prohibit direct public access between the Internet and any system component in the cardholder data environment.

1.3 Examine firewall and router configurations—including but not limited to the choke router at the Internet, the DMZ router and firewall, the DMZ cardholder segment, the perimeter router, and the internal cardholder network segment—and perform the following to determine that there is no direct access between the Internet and system components in the internal cardholder network segment:

A firewall's intent is to manage and control all connections between public systems and internal systems, especially those that store, process or transmit cardholder data. If direct access is allowed between public systems and the CDE, the protections offered by the firewall are bypassed, and system components storing cardholder data may be exposed to compromise.

1.3.1 Implement a DMZ to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

1.3.1 Examine firewall and router configurations to verify that a DMZ is implemented to limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

The DMZ is that part of the network that manages connections between the Internet (or other untrusted networks), and services that an organization needs to have available to the public (like a web server).

This functionality is intended to prevent malicious individuals from accessing the organization's internal network from the Internet, or from using services, protocols, or ports in an unauthorized manner.

1.3.2 Limit inbound Internet traffic to IP addresses within the DMZ.

1.3.2 Examine firewall and router configurations to verify that inbound Internet traffic is limited to IP addresses within the DMZ.

1.3.3 Do not allow any direct connections inbound or outbound for traffic between the Internet and the cardholder data environment.

1.3.3 Examine firewall and router configurations to verify direct connections inbound or outbound are not allowed for traffic between the Internet and the cardholder data environment.

Examination of all inbound and outbound connections allows for inspection and restriction of traffic based on the source and/or destination address, as well as inspection and blocking of unwanted content, thus preventing unfiltered access between untrusted and trusted environments. This helps prevent, for example, malicious individuals from sending data they've obtained from within your network out to an external untrusted server in an untrusted network.

“Say what you mean…”

•  The requirements seem simple, but the meaning is nuanced.

•  Sometimes interpreted differently by QSAs and ISAs.

•  PCI DSS 3.0 adds a guidance column with more detail to clarify intent of requirements.

•  Best defense is for everyone to thoroughly read the standard.

•  Ignorance is not an acceptable excuse.

What’s New in 3.0: Highlights •  Moved from 2 year to 3 year standards development

lifecycle. •  Requirements are the same, but with modifications

to sub-requirements. •  V2.0 active until Dec. 31, 2014, some new V3.0

requirements not mandatory until July 2015. •  Clarifies scoping and reporting •  Focus on consistency, proactivity and best practices •  Addition of security policy/procedure into each

requirement. •  Clarifies handling of sensitive authentication data

(SAD).

Specific Requirement Additions

1. Current diagram with cardholder data flows in addition to network diagrams. 2. Maintain inventory of in-scope system components and change default passwords on application/service accounts. 3. More options for secure storage of crypto keys. Clarification regarding dual control. 5. Evaluate evolving malware threats for systems not commonly affected by malware.

Requirement Additions Continued 6. Update list of common vulnerabilities, align with OWASP, NIST, SANS for secure coding practices. 8. Security considerations for authentication mechanisms such as tokens, smart cards and certs. Enhanced guidance on good password practices. More flexibility to accommodate variations in secure implementations. 9. Protect POS terminals and devices from tampering or substitution. 10. Clarifies intent and scope of daily log reviews by focusing on identifying suspicious activity. 11. Implement pentesting method to validate segmentation. 12. Maintain info about status of PCI DSS for 3rd party providers.

Scope According to PCI SSC, the CDE consists of “…people, processes and technology that store, process or transmit cardholder data or sensitive authentication data….” •  Firewalls •  Switches •  Access Points •  Network and Security Appliances •  Servers

Scoping •  Anything included or connected to CDE is “in

scope.” •  Isolating (segmenting), the CDE from the rest of the

network is not a requirement. •  Technique that shrinks the scope of the assessment,

reducing cost and difficulty. •  Reduces risk. •  Without scoping, entire network is in scope of the

assessment. •  To be “out of scope”, the component must be

properly segmented from the CDE, so that if compromised it could not impact CDE.

Compensating Controls “Compensating controls may be considered for most PCI DSS requirements when an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints, but has sufficiently mitigated the risk associated with the requirement through implementation of other, or compensating, controls.” From Appendix B, PCI DSS, v3.0

Compensating Controls Must

•  Meet intent of original requirement. •  Provide similar level of defense. •  Go “above and beyond”. •  Be commensurate with additional risk. •  Be more work to implement, not less. •  Pass an audit.

PCI DSS Myths

1. I only process a small number of credit card transactions, so it’s not a big deal.

•  You MUST be compliant with PCI DSS, regardless of transaction numbers.

•  If you outsource, you must verify their PCI DSS compliance status in accordance with requirement 12.

•  Outsourcing simplifies your requirements, but doesn’t eliminate the need to address it.

2. I only have to submit an SAQ, so all the requirements don’t apply

•  All requirements still apply. •  The questionnaire is misleading because there

are fewer questions. •  This is because the categories assume reduced

scope, based upon a decision tree in the “SAQ Instructions and Guidelines” document.

PCI DSS Self-Assessment Questionnaire Instructions and Guidelines, v2.0 October 2010 Copyright 2010 PCI Security Standards Council LLC Page 17

Which SAQ Best Applies to My Environment?

3. Wireless requirements only apply if card data transits the WLAN.

•  Wireless is perceived as a vulnerable medium. •  You must still validate that wireless is “out of

scope” to meet fewer requirements. •  See requirements 1.2.3, 9.1.3, 10.5.4, 11.1

4. To reduce scope, I need to have physically separate networks.

You have to implement controls which segment and restrict access to the CDE.

5. Mixed-mode virtualized environments aren’t permitted

From “PCI DSS Virtualization Guidelines” 2011 document: “…any VM or other virtual component that is hosted on the same hardware or hypervisor as an in-scope component would also be in scope for PCI DSS, as both the hypervisor and underlying host provide a connection (either physical, logical, or both) between the virtual components.... … In order for in-scope and out-of-scope VMs to co-exist on the same host or hypervisor, the VMs must be isolated from each other such that they can effectively be regarded as separate hardware on different network segments with no connectivity to each other.…Even if adequate segmentation between virtual components could be achieved, the resource effort and administrative overhead required to enforce the segmentation and maintain different security levels on each component would likely be more burdensome than applying PCI DSS controls to the system as a whole.

6. Supporting systems aren’t in scope

REMEMBER: “…included in or connected to the cardholder data environment.” It’s just like a game of cooties.

7. Compliance requirements are based upon merchant or service provider level.

•  No, VALIDATION requirements differ.

•  Everyone must comply with ALL of PCI DSS, regardless of level.

•  This is not optional.

8. I can just use a compensating control to meet a requirement that’s too difficult.

Compensating controls are stricter. The key phrase is “above and beyond.”

Getting It Right •  Data inventory and classification •  Data flow and inventory of CDE •  Reduce scope wherever possible. •  Identify data custodians and stakeholders outside of

IT. Embed ownership in entire organization. •  Avoid Compensating Controls, using as last resort. •  Remove CC data wherever possible. •  If you can’t remove, tokenize. •  Consider outsourcing. •  If > level 4 merchant or SP and you qualify for SAQ

D, consider using QSA or auditor for initial assessment or occasional follow-up.

References Chuvakin, Anton, Branden R. Williams, and Ward Spangenberg. PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance. Burlington, MA: Syngress, 2010. Print. "Documents Library." PCI Security Standards Documents: PCI DSS, PA-DSS, PED Standards, Compliance Guidelines and More. Payment Card Industry Security Standards Council, n.d. Web. 17 Mar. 2014. Van Oosten, Ciske. PCI Compliance Report. Rep. no. GL00648-17. Verizon, Feb. 2014. Web. <http://www.verizonenterprise.com/pcireport/2014/>.

Questions?

Where Can You Find Me?

• Spending quality time in kernel mode practicing and refining my particular form of snark. • www.healthyparanoia.net • Twitter @MrsYisWhy • Google+ MrsYisWhy • networksecurityprincess@gmail.com • chubirka@packetpushers.net • http://www.networkcomputing.com/blogs/author/Michele-Chubirka