PCI 3.0 What You Need to Know!

Transcription

1 PCI 3.0 What You Need to Know! Carlos Alberto Villalba Franco Director of Security Services (x 21) ScoFsdale, 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 cerzficazon standards for: Merchants Financial InsZtuZons Hardware/So_ware 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 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

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 Transition year, PCI DSS 2.0 is valid in 2014 Release Ready 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 interpretazons of the standard! Weak or default passwords! Slow deteczon of compromise! Security problems introduced by 3 rd parzes 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 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

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

14 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

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

16 Guidance for each requirement

17 A PenetraZon Test Methodology! Based on industry- accepted approaches, e.g. NIST SP ! 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

18 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

19 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

20 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

21 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, , mandates the implementazon of a process to respond to any alerts generated by that mechanism.

22 Manage Service Providers! New requirement, , mandates the documentazon of which DSS requirements are managed by the 3 rd party.! New requirement, 12.9, mandates that 3 rd 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.

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

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

25 ?