PCI Compliance PCI DSS v3.1 Dan Lobb CRISC Lisa Gable CISM
Dan Lobb, CRISC o Introduction Dan has an MIS degree from the University of Central Florida. He began his career at Accenture and for the past 9 years his career has focused on information security compliance with leading Fortune 500 companies. He currently manages a compliance program at Macy s. Lisa Gable, CISM o Lisa has an MIS degree from the University of Georgia. She began her career at Macy s and for the past 7 years has focused on information security risk and PCI compliance. She currently manages risk and the PCI program at Macy s.
Agenda Introduction to PCI DSS PCI DSS Version 3 overview Welcome to version 3.1! Managing on-going compliance Finding a QSA Leverage the ROC format Resources
Introduction to PCI DSS PCI Data Security Standard (DSS) o o o Framework created by card companies Technical requirements for data security Fines and penalties for compliance failures Quick History o 2004 PCI Council formed, v1 released o 2010 Version 2 released o 2014 Move to version 3 New requirements Updated testing approaches Improved clarity and guidance o 2015 update to version 3.1
PCI DSS version 3 100 changes Move to guidance, provides clarity Additional testing defined Additional requirements for June 2015 Physical device security Data flow diagrams, scope CDE
PCI DSS version 3 Requirement Impact Consider 1 Network/Data flow diagrams New addition to network diagrams, flows CDE scope considerations 2 Default passwords ALL systems clarified and unneeded removed Applications, tools, terminals, etc. 3 Crypto key storage Secure form and fewest locations possible Strength guidance provided
PCI DSS version 3 Requirement Impact Consider 4 Encrypt cardholder data across open networks 5 Protect systems against malware Added clarity, examples of networks ALL systems clarified to be in-scope for antivirus. Testing procedures aligned so you can better prepare Anti-virus must be active and less common systems now scoped 6 Develop and maintain secure systems and applications Identify and risk rank vulnerabilities. Coding practices evolving for authentication/session management Secure coding program updates; common vulns, sep dev and prod environs, memory usage
PCI DSS version 3 Requirement Impact Consider 7 Restrict access Refocused on privileged access and least privilege Testing procedures aligned so you can better prepare 8 Identify and authenticate 9 Restrict physical access Refocus to apply more holistic approach to authentication, new service provider req, indiv accounts Control access to sensitive areas for onsite personnel. Direct physical interaction with capture devices needed. Methods beyond passwords. Third party vendors. Include public access jacks, terminate access, check capture devices.
PCI DSS version 3 Requirement Impact Consider 10 Track and monitor access 11 Regularly test security 12 Maintain an Information Security Policy Audit trails should link access to individuals. Track log stops. Root/admin access changes. Inventory authorized wireless access points, scan for unauthorized. Implement method for pen testing. Annual risk assessment process. New testing procedure for remote access inactive disconnects. Service provider security. Log reviews to identify anomalies in access changes. Scan after changes, combine scan reports to document passing result. Policies and procedures for service providers. Data protection for remote sessions, agreements.
PCI DSS version 3.1 Weaknesses within the protocol Upgrade to a secure version Note updates to 2.2.3, 2.3 and 4.1 No SSL (and early TLS) after June 30, 2016 Risk mitigation plans New implementations must not use SSL
SSL Removal Why does SSL need to be removed as an example of strong cryptography from the PCI DSS and PA-DSS? The National Institute of Standards and Technology (NIST) has identified the Secure Socket Layers (SSL) v3.0 protocol (a cryptographic protocol designed to provide secure communications over a computer network) as not being acceptable for the protection of data due to inherent weaknesses within the protocol. Because of these weaknesses, no version of the SSL protocol meets the PCI Security Standards Council (PCI SSC) definition of strong cryptography, The successor protocol to SSL is TLS (Transport Layer Security) and its most current version as of this publication is TLS 1.2. TLS 1.2 currently meets the PCI SSC definition of strong cryptography. How does it pose a risk to payment card data? The SSL protocol vulnerability primarily affects web servers and browsers, so if exploited it can jeopardize the security of any payment card data being accepted or processed. Upgrading to a current, secure version of TLS, the successor protocol to SSL, is the only known way to remediate th
SSL Strategies Can no longer be used after June 30, 2016 PCI-DSS has developed an information supplement - Migrating from SSL and Early TLS Identify all system components and data flows relying on and/or supporting the vulnerable protocols For each system component or data flow, identify the business and/or technical need for using the vulnerable protocol Immediately remove or disable all instances of vulnerable protocols that do not have a supporting business or technical need Identify technologies to replace the vulnerable protocols and document secure configurations to be implemented
SSL Strategies Document a migration project plan outlining steps and timeframes for updates Implement risk reduction controls to help reduce susceptibility to known exploits until the vulnerable protocols are removed from the environment Perform migrations and follow change control procedures to ensure system updates are tested and authorized Update system configuration standards as migrations to new protocols are completed
On-going Compliance Assess Remediate Report Map data flows Assess gaps Identify risks Create remediation plan Implement remediation Onsite assessment Selfassessment questionnaire
Finding a good QSA The selection of a QSA may be the start of a long-term relationship. Companies should look for QSA firms that have experience with the same or similar technology to be audited. In preparation for hiring a QSA, organizations should be gathering business requirements, developing in-depth interviews and questions related to experience, and allocating time for planning and onsite audit. Ensure that the individual QSAs you speak and work with remotely for data gathering and assessment planning are the same ones who actually come onsite for controls evaluation.
Finding a good QSA 1. For what types of organizations have you performed PCI DSS assessments? 2. How many assessments have you performed and when? 3. What is your background? 4. Who will be performing the work? 5. How do you validate and assess compensating controls? 6. Are there examples of your assessments being used to improve security for clients?
Leverage the ROC format 1. The ROC includes the following sections and appendices: Section 1: Contact Information and Report Date Section 2: Summary Overview Section 3: Description of Scope of Work and Approach Taken Section 4: Details about Reviewed Environment Section 5: Quarterly Scan Results Section 6: Findings and Observations Appendix A: Additional PCI DSS Requirements for Shared Hosting Providers Appendices B and C: Compensating Controls and Compensating Controls Worksheet (as applicable) Appendix D: Segmentation and Sampling of Business Facilities/System Components (diagram)
Leverage the ROC format
Resources Content Versions of active standards Supporting documents Summary of 3.1 Changes DSS 3.1 Overview Webinar Migrating from SSL How to Choose a Qualified Security Assessor Link https://www.pcisecuritystandards.org/se curity_standards/documents.php https://www.pcisecuritystandards.org/do cuments/pci_dss_v3-1_summary_of_changes.pdf https://event.webcasts.com/starthere.jsp?ei=1056627 https://www.pcisecuritystandards.org/do cuments/migrating_from_ssl_early_tls_in formation%20supplement_v1.pdf https://www.sans.org/readingroom/whitepapers/analyst/choosequalified-security-assessor-34920