pci dss 3.0 – what you need to know
TRANSCRIPT
PCI 3.0
WHAT YOU NEED TO KNOW
Carlos Alberto Villalba FrancoDirector of Security [email protected] (x 21)Scottsdale, Arizona
Agenda
• PCI - Overview
• Part II - What’s new in PCI DSS 3.0
• Part III – Q&A
A PRIMER ON
PCI DSS
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
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
The 12 domains of PCI DSS 2.0
WHAT’S NEW
IN 3.0
Important datesPCI 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
Version 3Beginning with version 2, the PCI Council established a three-year
cycle for new versions
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
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
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).
Eschew Ambiguity
Remove
ambiguities in
the specification
that result in
inconsistent
interpretations
of a
requirement.
Eschew AmbiguityThe 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.
Eschew AmbiguityThere 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.
Guidance for each requirement
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
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
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
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
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.
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.
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.
More acronyms
• BTW VCD END
• By the way “Vayan con Dios” the end.
