PCI DSS can be one of the most infuriating set of standards on the compliance landscape. While it seems simple--six domains and twelve requirements--the art of interpreting PCI can lead to full blown war in an organization--with the security team at the center. In this session we’ll demystify some of the more difficult and misunderstood aspects of PCI DSS. We’ll cover the important changes from recently announced PCI DSS 3.0. We’ll also discuss the best practices for starting (and maintaining) a PCI DSS initiative in an organization and how to avoid battles with the QSA.

1. Adventures In PCI
Wonderland:
An Engineer Goes
Through the Looking
Glass

2. “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.

3. 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

4. “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."

5. Please ask questions!

6. • 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

7. Why Does PCI DSS Matter?
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 ‘12
Data from The Nilson Report, August 2013Figure 2: The cost of card fraud; data from The Nilson Report, August 2013
VERIZON 2014 PCI COMPLIANCE REPORT

8. “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

9. Who’s Compliant?
d services
ies target
t card
tion.
Verizon Data
estigations Reports
11, 2012 and 2013
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 111
Number of requirements
%companies
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

10. 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

11. Does It Work?
Its effectiveness is determined by the
organization’s implementation, not the
auditor.

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

13. • 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

14. “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.

15. 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.

16. PCI DSS 101

17. 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

18. “Speak English! I don't know
the meaning of half those
words, and I don't believe
you do either!”

19. 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?

20. 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.

21. 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

22. 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.

23. 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

24. 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

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

26. 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.

27. That Doesn’t Seem So Bad

28. 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.

29. 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.

30. 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.

31. “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.

32. 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).

33. 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.

34. 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.

35. 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

36. 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.

37. 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

38. 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.

39. PCI DSS Myths

40. 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.

41. 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.

42. 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?

43. 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

44. 4. To reduce scope, I need to have
physically separate networks.
You have to implement
controls which segment
and restrict access to the
CDE.

45. 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.

46. 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.

47. 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.

48. 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.”

49. 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.

50. 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/>.

51. Questions?

52. 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