PCI DATA SECURITY STANDARDS VERSION 3.2. What's Next?

Transcription

1 PCI DATA SECURITY STANDARDS VERSION 3.2 What's Next?

2 Presenters Alan Gutierrez Arana Director National PCI Leader RSM US LLP Gus Orologas, QSA Manager RSM US LLP Travis Wendling, QSA Supervisor RSM US LLP

3 Topics to be covered during webcast 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?

4 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

5 THE PCI DSS LANDSCAPE

6 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

7 PCI DSS requirements

8 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

9 PCI requirements (merchant) LEVEL VALIDATION ACTIONS VALIDATED BY 1 Annual on site security audit ** AND ** Quarterly network scan Independent assessor (QSA) or internal auditor if trained by PCI Association Scans conducted by Approved Scanning Vendor (ASV 2 & 3 4 Annual self assessment questionnaire ** AND ** Quarterly network scan Annual self assessment questionnaire recommended Network scan recommended Merchant (Self Assessment) Scans conducted by Approved Scanning Vendor (ASV) Merchant (Self Assessment) Scans conducted by Approved Scanning Vendor (ASV

10 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 31 st, all ROCs must follow version 3.2 of PCI DSS Visa will not accept 3.1 ROCs after December 31 st

11 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)

12 PCI DSS 3.2 updates cont d While some requirements will be considered best practice until January , 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

13 PCI DSS 3.2 updates cont d Secure all individual non console administrative access and all 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).

14 PCI 3.2 Changes Overview 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 14

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

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). 16

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

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 18

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 19

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

21 THE FUTURE OF PCI: HOW TO REDUCE RISK

22 Point-of-Sale (POS) architecture Cardholder data not encrypted and subject to compromise. Includes network and POS Server

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

24 P2PE P2PE POS device direct to processor

25 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

26 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

27 Data/Network isolation vs. segregation There is a difference! Isolation Segregation Information or network is completely standalone Information or network is connected to other data sets or sub networks but access is restricted by permissions

28 Data/Network isolation vs. segregation cont d Data classification and records management facilitates an effective IT security program Brain teaser What is a potential risk for a call centre of a retail company taking phone orders?

29 KEY INITIATIVES FOR PCI 3.2 COMPLIANCE

30 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

31 KEY CYBERSECURITY TASKS

32 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

33 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

34 For more information Contact Us: Alan Gutierrez, National PCI Leader PCI Regional Leads West Joe Benfatti Central Kerry Erickson Greatlakes Adam Keagle Northeast Keith Swiat Southeast Ray Soriano Additional Resources: Subscribe to the Risk Bulletin, a quarterly newsletter providing insights to help your organization manage evolving risks

35 RSM US LLP 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 registered trademark of RSM US LLP.