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
RetirementTransitionReadyRelease
2014 Transition year, PCI
DSS 2.0 is valid in 2014
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
Descriptions of tests are more precise
More rigor in determining scope of assessment
More guidance on log reviews
Some sub-requirements added
The twelve domains remain
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.

25. ?
Carlos A. Villalba
Director of Security Services
carlos.villalba@TerraVerdeServices.com
877-707-7997 (x 21)