WIth the version 3.0 of PCI DSS now available, it's time to review your compliance strategy and make a plan for adapting to the revised requirements.

1. PCI 3.0 – What You Need to Know
Carlos Alberto Villalba Franco
Director of Security Services
carlos.villalba@TerraVerdeServices.com
877-707-7997 (x 21)
Scottsdale, Arizona

2. Agenda
PCI - Overview
Part II - What’s new in PCI DSS 3.0
Part III – Q&A

3. A PRIMER ON PCI DSS

4. The Payment Card Industry (PCI)
American Express, Discover, JCB, MasterCard,
and Visa created the Security Standards
Council (SSC).
The PCI SSC has created a number of security
and certification standards for:
– Merchants
– Financial Institutions
– Hardware/Software vendors
– Service Professionals

5. Data Security Standard (DSS)
The PCI Data Security Standard (PCI DSS) is in its
second version.
– The third version was made available in November 2013
It applies to any entity that stores, use, processes, or
transmits cardholder data (CHD).
Those entities that process/stores many credit card
transactions each year, e.g. over 6 million, must
undergo an annual audit by a QSA.
Twelve requirements

6. The 12 domains of PCI DSS 2.0

7. WHAT’S NEW IN 3.0

8. Important dates
PCI DSS 3.0
released in
November 2013
Release
Ready
2014 Transition year, PCI
DSS 2.0 is valid in 2014
Transition
Retirement
Effective on January 1.
PCI DSS 3.0 to be
retired December
31, 2017

9. Version 3
Beginning with version 2, the PCI Council established a three-year cycle for
new versions

10. What did they want to fix
Divergent interpretations of the
standard
Weak or default passwords
Slow detection of compromise
Security problems introduced by
3rd parties and various areas
Inconsistency in Assessments

11. Highlights
The twelve domains remain
Some sub-requirements added
Descriptions of tests are more precise
More rigor in determining scope of assessment
More guidance on log reviews
More rigorous penetration testing

12. Eschew Ambiguity
Too much variance in
interpretation among
QSAs
Clients get different
interpretations.
PCI Counsel’s Quality
Control sees too
much
variance in the
Reports on
Compliance (ROC).

13. Eschew Ambiguity
Remove
ambiguities in
the specification
that result in
inconsistent
interpretations
of a
requirement.

14. Eschew Ambiguity
The challenge is to
improve the clarity
of the requirement
and the specificity
of the tests without
being so
prescriptive that it
excludes methods
and technology
that also meet the
goal of the
requirement.

15. Eschew Ambiguity
There is a natural tension
between stating a
requirement precisely
enough to prevent
divergent interpretations
and having the language
loose enough to allow
that requirement to be
satisfied by a variety of
methods and technology.

16. Guidance for each requirement

17. A Penetration Test Methodology
Based on industry-accepted approaches,
e.g. NIST SP800-115
A new clause 11.3
– Test entire perimeter of CDE & all critical systems
– Validate all scope-reduction controls—segmentation
– Test from inside and from outside of the network
– Test network-function components and OSs
– As a minimum, perform application tests for the
vulnerabilities listed in Requirement 6.5

18. Updated Vulnerabilities
Programmers of internally-developed and bespoke
applications must be trained to avoid known
vulnerabilities
List expanded to include new requirements for
– coding practices to protect against broken authentication
and session management
– coding practices to document how PAN and SAD are
handled in memory
• Combating memory scraping is a good idea for PA-DSS
• This was a bit contentious for PCI-DSS

19. Authentication
Requirement text recognizes methods other
than password/passphrases, e.g. certificates
– Authentication credentials
Minimum password length is still 7 characters
– “Alternatively, the passwords/phrases must have
complexity and strength at least equivalent to the
parameters specified above.”
A service provider must use a different
password for each of its clients.
Educate users

20. Default Passwords
Default passwords
– Change those being used
– Change and disable those not being used
Change all the default passwords including
– systems
– applications
– security software
– terminals

21. Quicker detection of compromise
Deploy a change-detection
mechanism to alert personnel
to unauthorized modification of
critical system files,
configuration files, or content
files
• configure the software to perform
critical file comparisons at least weekly.
New requirement, 11.5.1,
mandates the implementation
of a process to respond to any
alerts generated by that
mechanism.

22. Manage Service Providers
New requirement, 12.8.5, mandates the
documentation of which DSS
requirements are managed by the 3rd
party.
New requirement, 12.9, mandates that 3rd
parties must acknowledge in writing that
they will comply with the DSS to protect
CHD entrusted to them or, if managing
some aspect of the CDE, state they will
comply with the DSS in performing that
management.

23. Et cetera
Must have a data flow diagram.
Maintain inventory of all systems in scope.
Monitor new threats to systems not normally
susceptible to malware.
Control onsite staff’s access to sensitive areas.
Establish incident response procedures to handle
detection of unauthorized wireless.
Separate security functions from operations.

24. More acronyms
BTW VCD END
By the way “Vayan con Dios” the end.