So you want to take Credit Cards!

Transcription

1 So you want to take Credit Cards! Payment Card Industry - Data Security Standard: (PCI-DSS) Doug Cox GSEC, CPTE, PCI/ISA, MBA dcox@umich.edu Data Security Analyst University of Michigan

2 PCI in Higher Ed Expected to accept credit cards Organizational complexity Higher Ed is not a traditional business

3 What this talk is not covering!

4 What this talk is covering! Network Connected Solutions

5 Why are we talking about PCI compliance!

6 Some slides contain way too much text. This is by design so this slide deck can be used as a reference.

7 Agenda When does PCI DSS apply? Who is the PCI Security Standards Council? PCI DSS 3.1 in detail Challenges?

8 When does PCI DSS apply? Payment Accepting Card Industry Data Security Standard And you hold the Merchant ID (MID)!

9 PCI Security Standards Council Launched 2006 Founders of the Council American Express Discover Financial Services JCB International MasterCard Visa Inc.

10 Standards Ecosystem PIN Transaction Security (PTS) Requirements Payment Application Data Security Std (PA-DSS) Data Security Standard (DSS) Point-to-Point Encryption Standard (P2PE) PCI DSS Designated Entities Supplemental Validation s e un nder J of offe s a w peat e N re for

11 You are here!

12 Consequences Loss of Reputation Enforcer - The Card Brands Assess penalties $500K fine Forensic investigation fees $10-20K and up Reimbursement of fraudulent purchases Card Replacement $20-30/ea Blacklisted - no longer able to take credit cards

13 Who Owns PCI Compliance! Most institutions: Bursar s or Treasurer's Office How is it reported: Depends on the Merchant Bank The merchant: Unit or Department that accepts credit cards : Merchant ID (MID) : May rely on other departments (such as IT)

14 The Transaction

15 The Players Issuer QSA Cardholder PA-QSA Merchant ISA Payment Gateway ASV Payment Applications QIR Acquiring/Merchant Bank Service Provider Internal Security Assessor (ISA)

16 Internal Stakeholders Administration Unit Development Networking Data Center Web hosting & application development IT Security Compliance Office

17

18 Merchant Bank / Merchant Acquirer Merchant Compliance Validation Prioritized Volume of transactions Potential risk Exposure introduced into the payment system Determines Level (1-4) Each card brand has its own but similar requirements Unlike other regulations (FERPA, HIPAA, etc.) PCI is a contract with the acquirer Also, the arbiter of questions on PCI interpretation

19 Level 1 Merchants processing 1 million to 6 million Visa transactions annually (all channels) Annual Report on Compliance ( ROC ) by Qualified Security Assessor ( QSA ) or Internal Auditor if signed by officer of the company The internal auditor is highly recommended to obtain the PCI SSC Internal Security Assessor ( ISA ) certification Quarterly network scan by Approved Scan Vendor ( ASV ) Attestation of Compliance Form

20 Level 2/3 2) Merchants processing over 6 million Visa transactions annually (all channels) or Global merchants identified as Level 1 by any Visa region 3) Merchants processing 20,000 to 1 million Visa e-commerce transactions annually Annual Self-Assessment Questionnaire ( SAQ ) Quarterly network scan by ASV Attestation of Compliance Form

21 Level 4 Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants processing up to 1 million Visa transactions annually Annual SAQ recommended Quarterly network scan by ASV if applicable Compliance validation requirements set by merchant bank

22 PCI DSS v Requirements 115 pages & over 350 controls Scope of PCI DSS Requirements page 10 Network Segmentation page 11 Best Practices for Implementing Business As Usual page 13 (April 2015)

23

24 Build and Maintain a Secure Network 1) Install and maintain a firewall configuration to protect cardholder data Current network diagram that identifies all connections between the cardholder data environment and other networks, including any wireless networks Current diagram that shows all cardholder data flows across systems and networks 2) Do not use vendor-supplied defaults for system passwords and other security parameters. 2.1 Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network Implement additional security features for any required services, protocols, or daemons that are considered to be insecure for example, use secured technologies such as SSH, S-FTP, TLS, or IPSec VPN to protect insecure services such as NetBIOS, filesharing, Telnet, FTP, etc.

25 Protect Cardholder Data 3) Protect stored cardholder data 3.1 Keep cardholder data storage to a minimum by implementing data retention and disposal policies, procedures and processes that include at least the following for all cardholder data (CHD) storage: 3.2 Do not store sensitive authentication data after authorization (even if encrypted). If sensitive authentication data is received, render all data unrecoverable upon completion of the authorization process 4) Encrypt transmission of cardholder data across open public networks 4.1 Use strong cryptography and security protocols (for example, TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, 4.2 Never send unprotected PANs by end-user messaging technologies (for example, , instant messaging, SMS, chat, etc.).!!! e r u c e s d e r ger conside SSL a n o l o n e r a S nd early TL

26 Maintain a Vulnerability Management Program 5) Use and regularly update anti-virus software or programs 5.1 Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers) For systems considered to be not commonly affected by malicious software, perform periodic evaluations to identify and evaluate evolving malware threats in order to confirm whether such systems continue to not require anti-virus software. 6) Develop and maintain secure systems and applications 6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as high, medium, or low ) to newly discovered security vulnerabilities. 6.2 Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

27 Implement Strong Access Control Measures 7) Restrict access to cardholder data by business need-to-know 7.1 Limit access to system components and cardholder data to only those individuals whose job requires such access. 7.2 Establish an access control system for systems components that restricts access based on a user s need to know, and is set to deny all unless specifically allowed. 8) Assign a unique ID to each person with computer access 8.1 Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators on all system components Change user passwords/passphrases at least once every 90 days. 9) Restrict physical access to cardholder data 9.1 Use appropriate facility entry controls to limit and monitor physical access to systems in the cardholder data environment Restrict physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines.

28 Regularly Monitor and Test Networks 10) Track and monitor all access to network resources and cardholder data 10.1 Implement audit trails to link all access to system components to each individual user Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert). 11) Regularly test security systems and processes 11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades) Implement a methodology for penetration testing that includes the following:

29 Maintain an Information Security Policy 12) Maintain a policy that addresses information security for all personnel 12.1 Establish, publish, maintain, and disseminate a security policy Implement a risk-assessment process that: Require personnel to acknowledge at least annually that they have read and understood the security policy and procedures ent. en licies o p l era ies n Polic ific spec e b o eed t to CI e the P nvir nt, g e m n o likely t s o m n ffici ot su

30 But wait ---- There is more!!!

31 Self Assessment Questionnaire? The PCI DSS self-assessment questionnaires (SAQs) are validation tools intended to assist merchants and service providers report the results of their PCI DSS self-assessment. Fact: if a merchant is accepting a payment card, the entirety of the PCI DSS always applies to them.

32 Which SAQ to use? First Determine Scope n i d t data The PCI DSS security requirements apply to all system components included in or connected to the cardholder e n d e environment. The cardholder data environment (CDE) is comprised of people, processes that store, process, u and technologies l m c n n include inetwork or transmit cardholder data or sensitive authentication data. System components devices, servers, o i r s tinclude butearennotv limited to the following: computing devices, and applications. Examples of system components n e Systems that provide security services (for example, authentication ta facilitate segmentation (for example, on daservers), p internal firewalls), or may impact the security of (for example, name resolution or web redirection servers) the CDE. r om virtual eswitches/routers, Virtualization components such as virtual machines, virtual appliances, virtual c d l o applications/desktops, and hypervisors. m e h t d s Network components including but not limitedrto firewalls, switches, routers, wireless access points, network y s ca appliances, and other security appliances. l l e a h to web, application, database, authentication, mail, proxy, Network Time Protocol t Server types including but not limited o tsystem (DNS). (NTP), and Domain Name d e t all purchased and custom applications, including internal and external (for example, Internet) Applications including c e applications. n n o Any cother component or device located within or connected to the CDE. r o Payment Card Industry (PCI) Data Security Standard, v3.1 Page 10

33 Transaction Type: Card Present (Face to Face) ( ## ) approximate number of controls SAQ B (41) SAQ B-IP (83) SAQ C (139) SAQ C-VT (73) SAQ D (326) P2PE-HW (w/approved solution) (35)

34 Transaction Type: MO/TO ( ## ) approximate number of controls Mail Order SAQ A (14) SAQ B (41) SAQ B-IP (83) SAQ C (139) SAQ C-VT (73) SAQ D (326) P2PE-HW (w/approved solution) (35) / Telephone Order

35 Transaction Type: Card-not-present ( ## ) approximate number of controls SAQ A (14) SAQ A-EP (139) SAQ D (326) i.e. ecommerce

36 Meet the PCI 3.1 SAQ lineup: ecommerce Mail Order / Telephone Order Face to Face Yes (only ecommerce) Yes (or only MO/TO) No A-EP Yes No No B No Yes Yes B-IP No Yes Yes C No Yes Yes C-VT No Yes Yes D Yes Yes Yes P2PE-HW No Yes Yes SAQ A

37 Each SAQ has the following: Before You Begin - describes what type of merchant can use the SAQ Part 2g. Eligibility to Complete SAQ? - a signed attestation that requirements are met! Disclaimer - This shortened version of the SAQ includes questions that apply to a specific type of small merchant environment, as defined in the above eligibility criteria. If there are PCI DSS requirements applicable to your environment that are not covered in this SAQ, it may be an indication that this SAQ is not suitable for your environment. Additionally, you must still comply with all applicable PCI DSS requirements in order to be PCI DSS compliant.

38 MO/TO & ecommerce SAQ A

39 ecommerce SAQ A-EP

40 Swipe Terminal SAQ B-IP

41 POS SAQ C

42 VT Virtual Terminal POS SAQ C-

43 SAQ P2PE - HW

44 SAQ D

45 A Prioritized Approach

46 Shared Responsibilities But: Merchant - bottom line responsibility for compliance! Business as usual - not a check list Not a point in time - but a continual process No merchant has been found compliant after a breach! EMV (Chip & Signature) is a shift in liability! EMV is not part of compliance!

47 Reducing Scope Do not store credit card numbers Firewall & segment the network P2PE devices & solutions Prioritized approach Level 1 service provider PCI approved devices & applications

48 Challenges Lack of network maps and data flow diagrams Our vendor said they were PCI compliant so we are good - Right? Misinterpreting the requirements But doesn t xyz department / group do that for us? Reputational Risks Ever changing standards (minimally every 3 years)

49 PCI DSS is a good standard - make use of the fact you are compliant! Consider what parts of PCI make sense to use in other areas! Don t choose a SAQ and try to fit into it! SAQ D is not a bad thing! Remember to do the right thing!

50 Resources American Express: Discover Financial Services: JCB International: MasterCard: Visa Inc: Visa Europe:

51 Doug Cox GSEC, CPTE, PCI/ISA, MBA Data Security Analyst University of Michigan