How Secure is Your Payment Card Data?

Transcription

1 How Secure is Your Payment Card Data? Complying with PCI DSS SLIDE 1

2 PRESENTERS Francis Tam, CPA, CISA, CISM, CITP, CRISC, PCI QSA Managing Director, IT Security Practice PCI Practice Leader Francis has practiced public accounting and consulting. He has extensive experience providing information technology audit and internal control guidance to public and private companies. Francis expertise in technology consulting includes payment card industry security, IT governance, systems analysis, requirements analysis, systems selection and configuration, policy development, and more. He is the winner of 1992 AICPA Elijah Watt Sells Award with Highest Distinction in the Uniform CPA Examination. Kevin Villanueva, CISSP, CISA, CISM, PCI QSA Senior Manager, IT Security and Infrastructure Practice Leader Kevin has been in information technology field since 1998 and leads the firm s information security and infrastructure practice. He is considered expert-level staff in the areas of information security, disaster recovery planning, and strategic technology planning. He has experience in technology security assessments, systems auditing and assessments, network and system design, disaster recovery planning, information systems integration, and more. Kevin holds the Certified Information Systems Security Professional (CISSP) designation from ISC2 and ISACA s Certified Information Security Manager (CISM) designation. 2

3 The material appearing in this presentation is for informational purposes only and is not legal or accounting advice. Communication of this information is not intended to create, and receipt does not constitute, a legal relationship, including, but not limited to, an accountant-client relationship. Although these materials may have been prepared by professionals, they should not be used as a substitute for professional services. If legal, accounting, or other professional advice is required, the services of a professional should be sought. 3

4 OBJECTIVES You will leave this session with an understanding of: The background, history, compliance, and audit requirements of Payment Card Industry (PCI) Data Security Standards (DSS) Leveraging PCI DSS audit to achieve audit efficiencies with other compliance and/or regulatory audits Highlights of the changes from 2010 (v1.2) to (v2.0) Key compliance tips 4

5 POLLING QUESTION #1 How would you classify yourself? 1. A level 1 service provider or merchant 2. A non-level 1 service provider or merchant 3. Other 4. I do not know 5

6 Background & History Kevin Villanueva SLIDE 6

7 CARD BREACHES ARE ON THE RISE 2011 Security Breaches Food and Beverage 43.6% Retail 33.7% Hospitality 8% Financial 3.4% Entertainment 3.4% Energy 2.7% Misc. 5.2% Source: Trustwave s Global Security Report 2011

8 NOTABLE CARD BREACHES TJX Companies 2007 Hackers compromised wireless network to steal information on approximately 94 million card transactions. Heartland Payment Systems 2008 Hackers attacked system used to process card transactions. Inserted malware. Up to 100+ million transactions compromised. Global Payments 2012 Hackers attacked GP network. 1.5 million card account numbers accessed. Resulted in Visa dropping the card processor until they receive a new report on compliance. Sony PS Network 2011 Hackers accessed an old database containing consumer info and credit card info. Millions of customers information stolen. 8

9 PCI OVERVIEW Not a Federal regulation, but an industry regulation. Nevada, Minnesota and Washington have State PCI compliance laws. Purpose is to help prevent credit card fraud and maintain public confidence in payment cards. Applies to all entities that process, store, or transmit payment card information need to comply (Primary Account Number PAN is the deciding factor.) Card transaction players: card brands, merchants, service providers, acquirers, and issuers. Effective compliance dates varies depending on merchant level or service provider level and card brand. All deadline enforcement will come from the acquiring bank. Card brands have their own compliance programs and are responsible for compliance tracking, enforcement, penalties, and fees. 9

10 PCI OVERVIEW PCI Security Standards Council (PCI SSC or the Council) founded in 2006 is responsible for the development, management, education, and awareness of the PCI Security Standards. PCI Data Security Standard (PCI DSS) is a comprehensive set of international security requirements for protecting cardholder data. Payment Application Data Security Standard (PA-DSS) is a set of requirements for software vendors to develop secure payment applications. PCI PIN Transaction Security (PCI PTS) is a set of requirements for device vendors and manufacturers for all personal identification number (PIN) terminals, including POS devices, encrypting PIN pads, and unattended payment terminals. 10

11 THE PAYMENT CARD TRANSACTION Payment Brand Network Issuer (Consumer Bank) Service Provider Acquirer (Merchant Bank) Cardholder Merchant 11

12 MOBILE COMMERCE DEVELOPMENTS Retail purchases made through mobile have gone from 6% to 15% of purchases in only one year 25% of consumers engage in online shopping only via mobile Worldwide mobile payment transactions will surpass $171.5 billion in 2012, up 62% from $106 million last year Merchant Customer Exchange new mobile commerce platform developed for retailers 12

13 MOBILE COMMERCE & APPS How does payment card security compliance apply to: Purchases made by consumers through your mobile app or mobile site? Differences among payment card security at the store, on a computer, or on a phone? PCI-SSC has developed Mobile Payment Acceptance Application Categories Category 1 - Payment application operates only on a PTS-approved mobile device. Category 2 - Payment application meets 3 criteria: (1) bundled with a mobile device, (2) mobile device is purpose built for payment acceptance only, and (3) provides an environment that allows the merchant to meet and maintain PCI-DSS compliance. Category 3 - Payment application operates on any consumer electronic handheld device that is not solely dedicated to payment acceptance. 13

14 THE ACQUIRER S ROLE Acquirers (Merchant Bank) are responsible for: Ensuring their merchants are PCI DSS compliant Managing merchant communications Working with their Level 1 merchants until full compliance has been validated. Merchants are NOT COMPLIANT UNTIL ALL REQUIREMENTS have been met and validated. Acquirer is responsible for providing Visa their merchants compliance status. Any liability that may occur as a result of noncompliance 14

15 ROLES OF THE QSA & ASV QSA Qualified Security Assessor Certified to validate compliance with PCI-DSS Qualified Security Assessor companies have been qualified to have their employees assess compliance to the PCI-DSS standard Qualified Security Assessors are employees of these organizations who have been certified to validate an entity s adherence to the PCI-DSS ASV Approved Scanning Vendor Approved Scanning Vendors are organizations that validate adherence to certain DSS requirements by performing vulnerability scans of Internet-facing environments of merchants and service providers. 15

16 PCI DSS REQUIREMENTS 16

17 MERCHANT LEVELS Merchant Level Description 1 Merchants processing over 6 million Visa transactions annually (all channels) or global merchants identified as Level 1 by any Visa 2 region. Merchants processing 1 million to 6 million Visa transactions annually (all channels) 3 Merchants processing 20,000 to 1 million Visa e-commerce transactions annually. 4 Merchants processing less than 20,000 Visa e-commerce transactions annually and all other merchants processing up to 1 million Visa transactions annually. Transaction volume is based on the aggregate number of Visa transactions (inclusive of credit, debit, and prepaid) from a merchant Doing Business As (DBA). 17

18 SERVICE PROVIDERS Service Provider Level Description 1 VisaNet processors or any service provider that stores, processes, and/or transmits over 300,000 Visa transactions annually. 2* Any service provider that stores, processes, and/or transmits less than 300,000 Visa transactions annually. Posted on Visa s Global List of Validated Service Providers Yes No* * Level 2 service providers may choose to validate as a Level 1 service provider in order to be listed on Visa s Global List of Validated Service Providers. 18

19 VALIDATION REQUIREMENTS Compliance Actions On-Site Group Level Comply with PCI-DSS Security Assessment Merchant 1 Required Required Annually Service Provider Self- Assessment Questionnaire 2 & 3 Required Required Annually *Network scanning is applicable to any internet facing system. ** Validation requirements are determined by the merchant s acquirer. Network Scan* Required Quarterly Required Quarterly 4** Required Recommended Recommended Quarterly 1 Required Required Annually Validation Actions 2 Required Required Annually Required Quarterly Required Quarterly 19

20 SELF-ASSESSMENT QUESTIONNAIRES (SAQS) SAQ A B C-VT C D Description Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants. Imprint-only merchants with no electronic cardholder data storage, or standalone, dial-out terminal merchants with no electronic cardholder data storage. Merchants using only web-based virtual terminals, no electronic cardholder data storage. Merchants with payment application systems connected to the Internet, no electronic cardholder data storage. All other merchants not included in descriptions for SAQ types A through C above, and all service providers defined by a payment card brand as eligible to complete an SAQ.

21 POLLING QUESTION #2 The Payment Card Industry (PCI) Security Standards Council (SSC) is responsible for enforcing PCI-DSS compliance. 1. True 2. False 21

22 Highlights of Changes: v1.2-v2.0 Francis Tam SLIDE 22

23 HIGHLIGHTS OF CHANGES: V1.2 TO V2.0 v1.2.1, which had been in effect since July of 2009, was superseded by v2.0 on October 28, 2010 Aligned PCI-DSS better with PA DSS and other industry best practices No new requirements; only added guidance or clarifications Clarifications on intent and wording of requirements or test procedures with example(s) 23

24 HIGHLIGHTS OF CHANGES: V1.2 TO V2.0 Added guidance on test procedures and new technologies, such as virtualization and private cloud adoption Recognition of small merchant environments be more flexible Eliminate redundant sub-requirements 24

25 HIGHLIGHTS OF CHANGES: V1.2 TO V2.0 EXAMPLES Virtualization req In-scope and out-of-scope virtual machines can co-exist as long as there is only one primary function per virtual system component. Storage of Sensitive Authentication Data (SAD) - req 3.2 V2.0 allows the storage of SAD if there is sufficient business justification and the data is stored securely. This is only for card issuers and companies that support issuing processing. 25

26 HIGHLIGHTS OF CHANGES: V1.2 TO V2.0 EXAMPLES Risk based approach for addressing vulnerabilities - req 6.2 & Assign risk ranking to vulnerabilities Also impact reg and 11.2 Implementation date July 1,

27 HIGHLIGHTS OF CHANGES: V1.2 TO V2.0 EXAMPLES Expansion of definition of personnel req 9.2 This requirement now applies to on-site personnel and not just employees Support centralized auditing req 10.5 Audit data must be able to be moved to a centralized log server, such as syslog-ng, Windows Event Logs. External-facing technologies (for example, wireless, firewalls, DNS, mail) are offloaded or copied onto a secure centralized internal log server or media. 27

28 POLLING QUESTION #3 In PCI DSS v2.0, for req 9 Restrict Physical Access to Cardholder Data, it was changed such that it applies to: 1. Only card database administrators 2. Only employees 3. All on-site personnel 4. All personnel 28

29 Key Compliance Tips Kevin Villanueva SLIDE 29

30 KEY COMPLIANCE TIPS If cardholder data is not needed, don t keep it! Know what is on your network (run discovery tools: Cornell Spider, PANbuster, Vericept) Maintain a central repository for security-related activities throughout the year (vulnerability scan results, system/device reviews, diagrams, etc.) Develop security configuration standards for all your server types and devices. (e.g., DCs, web, database, firewall, etc.) Maintain a data retention policy and stick to it! 30

31 KEY COMPLIANCE TIPS Encrypt databases/files prior to committing them to backup tape/removable media Install A/V on your database servers that store cardholder data (or document compensating controls) Segment ( cocoon ) your CDE and use two-factor authentication for remote access (internal pen testing is not necessary) Institute a verification step for non-face-to-face password resets (e.g., employee ID) 31

32 KEY COMPLIANCE TIPS In virtualized environments, limit the number of mixed mode servers (use separate partitions for each virtual host) Implement POS systems with point-to-point encryption (P2PE) functionality (reduces scope) Conduct quarterly vulnerability scans and address vulnerabilities immediately Look to information security best practice frameworks for guidance (ISO 27002, NIST 800, COBIT) 32

33 PREPARING FOR A PCI-DSS ASSESSMENT Gather Documentation: Security policies, change control records, operational procedures, network diagrams, PCI DSS letters, and notifications Schedule Resources: Obtain dedicated participation of a project manager and key people from IT, business operations, human resources, and legal Describe the Environment: Organize information about the cardholder data environment, including cardholder data flows and locations of cardholder data repositories 33

34 POLLING QUESTION #4 Which of the following are ways I can reduce the scope of a PCI-DSS compliance audit? 1. Use POS systems with point-to-point encryption functionality 2. Segment the cardholder data environment 3. Delete primary account numbers from systems 4. 1 and 2 only 5. All of the above 34

35 Leveraging PCI DSS Audit Francis Tam SLIDE 35

36 LEVERAGING PCI DSS AUDIT Documentation collected for PCI-DSS requirements can be repurposed for other audits: Test results completed for PCI requirements can be used or relied upon by SAS 70/SSAE16 auditors Policies and templates developed for PCI compliance such as information security policies and user request forms can be used for systems without cardholder data Security awareness training and acceptable use policies can fill possible gaps in existing Human Resources polices 36

37 LEVERAGING PCI DSS AUDIT Description of Good Practices PCI-DSS v2 ISO HIPAA Install and maintain a firewall configuration to protect data COBIT (SOX) (e) (1) DS5.11 Use and regularly update anti-virus software or programs (a) (5) DS5.9 Assign a unique ID to each person with computer access (a) (1) DS5.4 Regularly test security systems and processes (b) AI2.3 37

38 LEVERAGING PCI DSS AUDIT PCI requirements can be used to drive existing internal projects: In some areas, PCI requirements may be more stringent than existing practices and used to enforce stronger security. For example, two factor authentication required for remote access and prohibited weak wireless encryption such as WEP. Communication of scheduled QSA assessment dates can force deadlines and uniform practices for unresponsive or isolated departments. 38

39 LEVERAGING PCI DSS AUDIT Conversely, existing internal projects may be used to satisfy some PCI requirements: Adopting Cloud Computing ( eliminate some of the requirements, such as Req. 10, 11.2 and 11.4). Safeguarding of private information initiatives, such as Personally Identifiable Information (PII) or Gramm-Leach-Bliley Act, may require Point-To-Point Encryption (P2PE), tokenization or twofactor authentication. Risk assessment can be leveraged to satisfy Req , especially if the existing risk assessment is based on ISO or NIST SP

40 REFERENCE MATERIALS PCI Website: Guidelines for Managing and Securing Mobile Devices in the Enterprise Recommendations of the National Institute of Standards and Technology Special Publication PCI DSS v2.0: 40