Embed Size (px)
Citation preview
PCI 3.0 – What You Need to Know!
Carlos Alberto Villalba Franco Director of Security Services [email protected] 877-‐707-‐7997 (x 21) ScoFsdale, 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 cerZficaZon standards for: – Merchants – Financial InsZtuZons – Hardware/So_ware 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 enZty that stores, use, processes, or transmits cardholder data (CHD).
! Those enZZes that process/stores many credit card transacZons 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 dates PCI DSS 3.0 released in November 2013
Retirement Transition Ready Release
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 3 Beginning with version 2, the PCI Council established a three-‐year cycle for new versions
What did they want to fix ! Divergent interpretaZons of the standard
! Weak or default passwords ! Slow detecZon of compromise ! Security problems introduced by 3rd parZes 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 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.
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.
Guidance for each requirement
A PenetraZon Test Methodology
! Based on industry-‐accepted approaches, e.g. NIST SP800-‐115
! A new clause 11.3 – Test enZre perimeter of CDE & all criZcal systems – Validate all scope-‐reducZon controls—segmentaZon – Test from inside and from outside of the network – Test network-‐funcZon components and OSs – As a minimum, perform applicaZon tests for the vulnerabiliZes listed in Requirement 6.5
Updated VulnerabiliZes ! Programmers of internally-‐developed and bespoke applicaZons must be trained to avoid known vulnerabiliZes
! List expanded to include new requirements for – coding pracZces to protect against broken authenZcaZon and session management
– coding pracZces to document how PAN and SAD are handled in memory
• CombaZng memory scraping is a good idea for PA-‐DSS • This was a bit contenZous for PCI-‐DSS
AuthenZcaZon ! Requirement text recognizes methods other than password/passphrases, e.g. cerZficates – AuthenZcaZon credenZals
! Minimum password length is sZll 7 characters – “AlternaZvely, 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 – applicaZons – security so_ware – terminals
Quicker detecZon of compromise
Deploy a change-‐detecZon mechanism to alert personnel to unauthorized modificaZon of criZcal system files, configuraZon files, or content files • configure the so_ware to perform criZcal file comparisons at least weekly.
New requirement, 11.5.1, mandates the implementaZon of a process to respond to any
alerts generated by that mechanism.
Manage Service Providers ! New requirement, 12.8.5, mandates the
documentaZon of which DSS requirements are managed by the 3rd party.
! New requirement, 12.9, mandates that 3rd parZes must acknowledge in wriZng 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 suscepZble to malware.
! Control onsite staff’s access to sensiZve areas. ! Establish incident response procedures to handle detecZon of unauthorized wireless.
! Separate security funcZons from operaZons.
More acronyms
! BTW VCD END ! By the way “Vayan con Dios” the end.
?
