pci data security standards version 3 - … data security standards version 3.2 what's next?...

© 2016 RSM US LLP. All Rights Reserved.

Introduction

Alan Gutierrez-AranaDirector, National PCI Services Leader

Security & Privacy ServicesExperience

Alan Gutierrez-Arana has over 20 years of experience providing IT security and controls assessments, regulatory compliance consulting services for a broad range of insurance, banking, finance and high technology entities. He specializes in Payment Card Industry (PCI) controls assessment and compliance, federal and state IT regulatory compliance (PCI-DSS, SOX, HIPAA-HITECH, BASEL II, FFIEC), controls design and implementation, SSAE16 assessments, disaster recovery, IT outsourcing and off-shoring, IT governance, business continuity, change management, information security, computer operations and e-business. His client portfolio includes several Fortune 100 and Fortune 500 companies, with locations in Asia, Latin America, Europe and the U.S.

(D) 215-4946622

[email protected]


Introduction

Gus OrologasManager, Risk Advisory ServicesAtlanta Office

PCI/ IT Security / ERMExperienceGus Orologas has over eighteen years of experience in the area of information security and is currently certified as a QSA, CISSP and as a CISA. He has extensive knowledge and experience in the architecture, design and deployment of secure information technology infrastructures. Gus is knowledgeable in industry best practices related to security management policies, risk assessments, network security, intrusion detection, public key infrastructure and physical security. Prior to joining RSM, Gus had a management role with a Big Four accounting/consulting firm as well as a Director of Global IT Security role for a publicly held manufacturing company headquartered in Atlanta. He also has extensive experience in the design and implementation of secure IT infrastructures for Federal law enforcement clients.

(D) 404-751-9083

[email protected]


Topics to be covered during presentation

• PCI DSS version 3.2 updates to existing requirements• New requirements introduced in version 3.2• Scope reduction techniques and technologies• Activities and tasks to secure card data• PCI challenges for merchants and service providers at

all levels • Are there any additional benefits in PCI DSS

compliance?


Key terms

• PCI DSS – Payment Card Industry Data Security Standards• PA DSS – Payment Application Data Security Standards

• Payment Cards – Visa, MasterCard Worldwide, American Express, Discover Financial Services, JCB International

• Merchant – Entity that accepts payments cards for payment• Acquirer – (Merchant Bank or Acquiring Bank) typically a financial institution that

processes payment card transactions for merchants• Payment Processor

• Issuing Bank – Financial institution issuing credit card• Service Provider – Business entity not directly involved with processing of payments. (e.g.

Managed Firewall Service Provider)• Cardholder Data Environment (CDE) – Stores, processes, or transmits cardholder

information• Qualified Security Assessor (QSA) – Required for Level 1 Assessments • Report on Compliance (ROC) – Report generated by QSA for Level 1 Assessments• Self Assessment Questionnaire (SAQ) – Reporting for Level 2-4 Assessments


THE PCI DSS LANDSCAPE


Why PCI compliance?

• Hackers and large international organized crime targeting merchants and their payment channels.

• High fees for non-compliance with PCI-DSS.• The fallouts of a card data breach:

• The resulting costs can be significant, including fines/penalties, termination of your ability to accept payment cards, lost customer confidence, legal costs, settlements and judgments, fraud losses, etc.

• Breach could result in a cost of, on average, $200 per card number lost

• Long term reputational effects to your company


PCI DSS requirements


PCI Levels

LEVEL Transaction Amounts

1 6 to 20 Million transactions per year

2 1 to 6 Million transactions per year.

3 20K to 1 Million transactions per year

4 Any merchant with 20K transactions or less per year.


PCI requirements (merchant)

LEVEL VALIDATION ACTIONS VALIDATED BY

1Annual on-site security audit

** AND **Quarterly network scan

Independent assessor (QSA) or internal auditor if trained by PCI Association

•Scans conducted byApproved Scanning Vendor (ASV

2 & 3Annual self-assessment questionnaire

** AND **Quarterly network scan

Merchant (Self Assessment)•Scans conducted by

Approved Scanning Vendor (ASV)

4

Annual self-assessment questionnaire recommended

Network scan recommended

Merchant (Self Assessment)•Scans conducted by

Approved Scanning Vendor (ASV


PCI DSS 3.2 updates timeline

• The PCI DSS version 3.2 was published April 2016 - this version of the standard was effective immediately

• Version 3.1 of the PCI DSS retired on October 31, 2016

• After October 31st, all ROCs must follow version 3.2 of PCI DSS

• Visa will not accept 3.1 ROCs after December 31st.


PCI DSS 3.2 updates

• Verification that policies and procedures are in place and operating effectiveness of those policies are part of the duties of the QSA

• Removal of “strong” or “secure” language around protocol examples provided in a number of requirements, since these may change at anytime (Requirement 1.1.6)

• Selected business-as-usual and governance principles may be required for certain organizations as defined in the Designated Entities Supplemental Validation (DESV) (Appendix A3)


PCI DSS 3.2 updates cont’d

• While some requirements will be considered “best practice” until January 31 2018, such extension is not intended to delay migrations.

• For example to secure versions of SSL or multi-factor authentication implementations, merchants will still have to demonstrate how they are addressing the risks represented by weak implementations of SSL or authentication methods that could be part of their cardholder data environment.

• Clarified correct term is multi-factor authentication(rather than two-factor authentication) as two or more factors may be used


PCI DSS 3.2 updates cont’d

• Secure all individual non-console administrative access andall remote access to the CDE using multi-factor authentication (8.3) ( best practice until January 31, 2018 )

• PCI DSS will incorporate two new appendices in the standard that were previously separate supplemental documents:

• Appendix A2—Additional PCI DSS requirements for entities using SSL/ Early TLS.

• Appendix A3—Designated entities supplemental validation (DESV).


PCI 3.2 Changes Overview

15

Display of PAN numbers due to business processes and constrains

Multi-factor vs. dual-factor authentication

Penetration testing for service providers

Service provider requirement updates

Updates of early versions of SSL/TLS


PCI 3.2 Changes

• Display of PAN numbers due to business processes and constrains:

• Updated requirement to clarify that any displays of PAN greater than the first six/last four digits of the PAN requires a legitimate business need, added guidance on common masking scenarios.

• This is with the intent to address the fact that many merchants and financial institutions have established processes around surcharges and chargebacks that require the display of the PAN number.

16


PCI 3.2 Changes

• Multi-factor vs. dual factor authentication: • The concept of multi-factor is introduced instead of

dual-factor in version 3.2; this is to support deployments in which two or more factors are being used (e.g. biometrics)

• Concurrently, multi-factor authentication requirements are expanded to all administrative/super user access to devices that are part of the CDE or that could impact the security of the CDE. Two or more factors is still acceptable. This requirement will apply from the inside and the outside of the CDE network(s).

17


PCI 3.2 Changes

• Penetration testing for third party service providers: • The requirement of penetration testing for service

providers is now at least twice a year.• With this change in the penetration testing

requirement, the council continues to emphasize that third party service providers are a point of high risk and the materialization of this risk through the recent breaches points to weaknesses in the controls around processes outsourced to third party service providers.

18


PCI 3.2 Changes

Service provider requirement update: • Documentation of cryptographic architecture (3.5.1)• Detection and of report of failures of critical security

control systems• Penetration testing on network segmentation controls

every 6 months.• Establish a formal PCI DSS compliance program

(governance)• Quarterly confirmation that staff is following security

policies and procedures

19


PCI 3.2 Changes

Updates on early versions of SSL/TLS: • ASV vendors should report weak SSL implementations

detected through their scans and merchant(s) should document and demonstrate risk mitigation controls around weak implementations of SSL

• A “Risk Mitigation and Migration Plan” (RMMP) should be developed by entities using older version of SSL/TLS

20


Report on compliance ROC changes

• The PCI DSS ROC incorporates two new appendices in the standard that were previously separate supplemental documents:

• Appendix A2 – Additional PCI-DSS requirements for entities using SSL/ Early TLS

• Appendix A3 – Designated entities supplemental validation (DESV). The Designated Entities Supplemental Validation (DESV) includes specific requirements for entities around PCI-DSS compliance program governance processes, including but not limited to scoping validation, documentation and incident response methodologies.

• “Summary of findings” table added to the summary overview


THE FUTURE OF PCI: HOW TO REDUCE RISK


Tokenization

The process of replacing a credit card number with a unique set of numbers that have no bearing on the original data.


P2PE

P2PE - POS device direct to processor


EMV (Europay/Mastercard®/Visa®) chip card

• Commonly known as “Chip and Pin”• October 1, 2015 – EMV implementation date

• Fraud liability shifts to merchants that do not have certified chip card readers

• More secure for card present transactions• However, consider…

• Cards are not encrypted• Data transmission across network• Implementation costs for new EMV POS terminal

• Doesn't provide additional security for e-commerce, mail, phone and fax orders


PCI compliance and IT management decisions

Costly upgrades• Network segmentation• Hardware and software upgrades• Vulnerability scanning• Monitoring and alerting systems• Fraud detection systems

Assessments and attestations• Implementing controls to protect cardholder data• Complete a report on compliance by a Qualified Security Assessor (QSA) or,• Perform a Self Assessment Questionnaire (SAQ)• Attestation of Compliance (AOC)

Fines• Not being PCI DSS compliant


KEY INITIATIVES FOR PCI 3.2 COMPLIANCE


Key initiatives for PCI 3.2 compliance

• Implement multi-factor authentication for administrative and super-user ID’s in devices, servers and platforms that are part of the CDE

• At the same time, all administrative access from non-CDE network segments to the CDE must be brought under the multi-factor regime


Key cybersecurity tasks

• Full disk/file encryption for key systems including servers (when appropriate)

• Properly trained IT staff

• Inventory of authorized hardware and software on the network

• Testing and production networks are segregated

• Incident Response Plan (IRP) and table top exercises

• Quarterly auditing of user accounts for network and key applications

• Employee onboarding/termination program


Key cybersecurity tasks

• System patch management solution• Information security officer is not an IT employee• Security awareness training• Regularly performing network testing and program to remediate

identified issues• Security Incident and Event Management (SIEM) solution and daily

review• 24/7 incident response team and not Monday to Friday 9-5• Third party solutions

• FireEye• WebSense• Carbon Black/Bit 9• DLP Solutions


New technologies

RSM exclusive PAN sniffing dogs


This document contains general information, may be based on authorities that are subject to change, and is not a substitute for professional advice or services. This document does not constitute audit, tax, consulting, business, financial, investment, legal or other professional advice, and you should consult a qualified professional advisor before taking any action based on the information herein. RSM US LLP, its affiliates and related entities are not responsible for any loss resulting from or relating to reliance on this document by any person.

RSM US LLP is a limited liability partnership and the U.S. member firm of RSM International, a global network of independent audit, tax and consulting firms. The member firms of RSM International collaborate to provide services to global clients, but are separate and distinct legal entities that cannot obligate each other. Each member firm is responsible only for its own acts and omissions, and not those of any other party. Visit rsmus.com/about us for more information regarding RSM US LLP and RSM International.

RSM® and the RSM logo are registered trademarks of RSM International Association. The power of being understood® is a registeredtrademark of RSM US LLP.


RSM US LLP

pci data security standards version 3 - … data security standards version 3.2 what's next?...

Documents