Payment Card Industry Data Security Standard (PCI DSS) v1.2

Transcription

1 Payment Card Industry Data Security Standard (PCI DSS) v1.2 Joint LA-ISACA and SFV-IIA Meeting February 19, 2009 Presented by Mike O. Villegas, CISA, CISSP

2 Agenda Introduction to PCI DSS Overview of PCI DSS 1.2 Requirements Merchant Levels Penalties for Non-Compliance Qualified Security Assessors Self-Assessment Questionnaire (SAQ) Approved Scanning Vendor (ASV) PCI DSS 1.2 Requirements Report on Compliance (ROC) PCI Vendor Selection The examples and approach described in this presentation are for purposes of instruction only and should not be construed as existing at Newegg, Inc. Participants are cautioned to perform their own due diligence before implementing ideas, processes or structures as presented

3 Introduction to PCI DSS

4 As of Jan 21, 2008, there have been recorded by the Privacy Rights Organization 251,175,706 records containing sensitive personal information in security breaches in the US since Jan //

5 PCI SSC PCI DSS originally began as five different programs: Visa Card Information Security Program, MasterCard Site Data Protection, American Express Data Security Operating Policy, Discover Information and Compliance, and the JCB Data Security Program. In June 2001, VISA developed CISP security audit program. The Payment Card Industry Security Standards Council (PCI SSC) was formed, and on December 15, 2004, these companies aligned their individual policies and released the Payment Card Industry Data Security Standard (PCI DSS). In September 2006, the PCI standard was updated to version 1.1 to provide clarification and minor revisions to version 1.0. The next version 1.2 was released on October 1, Version 1.1 is no longer effective as of December 31, v1.2 did not change requirements, only enhanced clarity, improved flexibility, and addressed evolving risks/threats

6 PCI Security Standards

7 PCI DSS 1.2 Requirements Goals Build and Maintain a Secure Network Protect Cardholder Data Maintain a Vulnerability Management Program PCI DSS Requirements 1. Install and maintain a firewall configuration to protect cardholder data 2. Do not use vendor-supplied defaults for system passwords and other security parameters 3. Protect stored cardholder data 4. Encrypt transmission of cardholder data across open, public networks 5. Use and regularly update anti-virus software or programs 6. Develop and maintain secure systems and applications 7. Restrict access to cardholder data by business need-to-know Implement Strong Access Control Measures 8. Assign a unique ID to each person with computer access 9. Restrict physical access to cardholder data Regularly Monitor and Test Networks Maintain an Information Security Policy 10. Track and monitor all access to network resources and cardholder data 11. Regularly test security systems and processes 12. Maintain a policy that addresses information security for employees and contractors

8 Merchant Levels Level VISA Criteria AMEX Criteria Over 6 million transactions per year Any merchant compromised in past year VISA discretion based on risk Identified by any other payment card brand as Level 1 Between 1 million and 6 million transactions per year Between 20 thousand and 1 million e- commerce transactions per year Less than 20 thousand e-commerce transactions per year and all others up to 1 million transactions per year Over 2.5 million AMEX transactions per year Any merchant compromised in past year AMEX discretion based on risk Between 50 thousand and 2.5 million AMEX transactions per year Less than 50 thousand AMEX transactions per year Required Validation Annual onsite assessment Quarterly scans required Quarterly scans required Annual SAQ Annual SAQ Quarterly scans VISA required Quarterly scan AMEX highly recommended N/A Annual SQA Quarterly scan may be required

9 Service Provider Levels Effective February 1, 2009, service providers that store, process or transmit Visa cardholder data on behalf of Visa acquirers, issuers, merchants or other service providers will fall into one of two service provider levels

10 Penalties for Non-Compliance Merchant banks whose retailers aren t PCI compliant could be fined up to $500,000. Typically, banks pass penalties along to the retailer involved. The merchant also faces loss of its card-acceptance privileges. For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC. Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers

11 Qualified Security Assessors (QSA) The PCI Security Standards Council maintains an in depth program for security companies seeking to be certified as Qualified Security Assessors (QSAs), as well as to be recertified as QSAs each year. Certification and re certification indicate only that the applicable QSA has successfully met all PCI Security Standards Council requirements to perform PCI data security assessments, and the PCI Security Standards Council does not endorse these security solution providers or their business processes or practices

12 Self-Assessment Questionnaires (SAQ) The SAQ is a self validation tool for merchants and service providers who are not required to do on site assessments for PCI DSS compliance. The SAQ are a series of yes or no questions for compliance. If an answer is no, the organization must state the future remediation date and associated actions

13 Approved Scanning Vendor (ASV) An Approved Scanning Vendor (ASV) is a data security firm using a scanning solution to determine whether or not the customer is compliant with the PCI DSS external vulnerability scanning requirement. ASVs are trained and qualified by the PCI SSC to perform network and systems scans as required by PCI DSS

14 Needs to be signed by an Executive Officer

15 Lifecycle Process for Changes to PCI DSS

16 Types of Data on Payment Card

17

18 Build and Maintain a Secure Network

19 Build and Maintain a Secure Network

20 Protect Cardholder Data

21

22 Protect Cardholder Data

23 Maintain a Vulnerability Management Program

24 Maintain a Vulnerability Management Program

25 Implement Strong Access Control Measures

26 Implement Strong Access Control Measures

27 Implement Strong Access Control Measures

28 Regularly Monitor and Test Networks

29 Regularly Monitor and Test Networks

30 Maintain an Information Security Policy

31 Report on Compliance (ROC) 1. Executive Summary 1. Description of the entity s payment card business 2. High-level diagram of entity s networking topography 2. Description of Scope of Work and Approach Taken 1. Environment on which assessment focused 2. Network segmentation used to reduce scope of PCI DSS review 3. Documentation and justified sampling 4. List of any wholly-owned entities 5. List of any International entities 6. List of any wireless LANS or APs 7. Version of PCI DSS requirements 8. Timeframe of Assessment 3. Details about Reviewed Environment 1. Diagram of each piece of communication link (LAN, WAN, or Internet) 2. Description of cardholder data environment 3. List of files/tables that store cardholder data 4. List of hardware and critical software used in cardholder data environment 5. List of service providers which company shares cardholder data

32 Report on Compliance (ROC) 6. List of third-party payment application products and version numbers 7. List of individuals interviewed and their titles 8. List of documentation reviewed 9. For Managed Service Provider (MSP) reviews, description of what applies to PCI DSS 4. Contact Information and Report Date 5. Quarterly Scan Results 1. Summarize the four most recent quarterly scan results in the Executive Summary 2. The most recent must have a passing scan 3. Scan must cover all externally accessible (Internet-facing) IP addresses 6. Findings and Observations 1. Summarize in the Executive Summary any findings that may not fit ROC format 2. Review and documentation of Compensating Controls Section of ROC

33 Review of Marketing Collateral

34 Research Firms Ratings Gartner Magic Quadrant Gartner offers the combined brainpower of 1,200 research analysts and consultants who advise executives in 80 countries every day. They publish tens of thousands of pages of original research annually and answer 200,000 client questions every year. Leaders in the subject area are typically in the upper right hand quadrant. June 6, 2008 The Forrester Wave : : Data Leak Prevention, Q Websense And Reconnex Top The Leaders Stack, Followed By Verdasys, RSA, And Vericept

35 Vendor Options for Applicable Requirement (sample) 2008/2009 PCI Expenditures

36 Proof of Concept 1. Select those vendors you wish to POC 2. Review marketing collateral for appropriateness 3. Perform company background assessment 4. Schedule vendor presentation and/or Webex inviting SMEs 5. POC will incur an internal cost but not to vendor 6. NDA and SOW for POC reviewed by Legal 7. Develop selection criteria 8. Schedule POC and engage SME time and resources 9. Determine what is required for POC: 1. Appliance 2. Dedicated Server 3. Protect Production Environments 4. Agents 5. Vendor Software 10. Test Functionality 11. Rate Based on POC Results 12. Ensure no confidential data is released when POC is completed

37 POC Assessment Score calculation This is strictly a sample. There are many different ways to perform a rating system

38 Impact on Environment There are times that a POC cannot be tested using live data or in production. This means that one has to assess the impact to your environment considering the following: Calculate the expected EPS (events per second) in POC tested environment and estimate what would otherwise be in production Consider the logging activity and how much storage would be required Consider whether logging activity would be in line or out of line and its respective affect on latency in production If the package requires agents on target devices, determine the latency, performance, or accessibility issues to production Determine if special training, skills, or SME resources will be required to hire or engage from vendor or other PS firms

39 All Vendors Must Provide References Reference Calls Pick those references that are similar to your environment Don t pick references with dissimilar platforms Request that only you and the reference caller is on the call not the vendor Make sure the reference caller does not have a conflict of interest with vendor (e.g., partner) What was the driver for looking for a vendor solution? How long have they had the product? What other products did they look at? POC? Why did they chose this one? Were they satisfied with the POC engineer? Knowledgeable? Responsive? Did they have to spend a lot of time making it run in their environment? Now that they have had time with product, what doesn t it do that you would have liked to see or know before you made the decision to buy? Do they believe the cost was fair and worthy of the product value? Did the product ultimately help them being PCI compliant?

40 Cost Cost should not be the, but one of the, primary factor for selecting a vendor Cost is relative but all prices are negotiable with the vendor Never pay list price; don t let it scare you to consider vendor See if the package can be bundled with other products from same vendor Hold off for month end, quarter end or year end to decide, if possible; vendors have sales goals that you can use to leverage on cost Don t waste the vendor s time if you have no intention of buying If the cost between vendors is not close, determine if the functionality (POC results) far outweighs the cost delta If the cost if greater than your budget, determine if the estimated ROI (POC results) far outweighs the cost delta Share the cost with Information Security, Network, IT, development groups, Audit, Risk Management, SOX group, and/or PCI group If software, consider downloading and save on taxes

41 Management Buy-In No one likes surprises and neither does management Don t inform management what the product will cost at the end of your negotiations with vendor Keep track of your budget and never let the vendor know what it is Keep management informed of your vendor negotiations Get Legal buy in on solution; this helps management feel comfortable to buy Get IT buy in on solution; this helps management comfortable on solution Always show management you performed good due diligence in selecting vendor Show the list versus actual cost of solution Make your management look good; ultimately you will look good as well Pretend this is your company (you own it) and you are making the decision to buy; would you?

42 Contract Negotiations Have someone in Legal (attorney) assigned to help you with contract negotiations Need Terms and Conditions (for POC and for purchase) Need License Agreement (for POC and for purchase) Sometimes, after all the time spent on POC, one or both Legal departments (yours and vendors) will not agree; so sale Most, if not all, of the time, contract negotiations are mutually agreeable Termination clauses (For Cause or For Non Cause) Limitation of Liability clauses (bilateral) Right to Audit clauses If code is involved or software, consider escrow clauses Non disclosure clauses

43

44 Biography Miguel (Mike) O. Villegas is the Director of Information Security at Newegg, Inc. and is responsible for Information Security, Business Continuity Management, and PCI DSS (Payment Card Industry Data Security Standard) compliance. Newegg, Inc. is one of the fastest growing E Commerce companies established in 2001 and exceeded revenues of over $2 Billion in Mike has over 25 years of Information Systems security and IT audit experience. Mike was previously Vice President & Technology Risk Manager for Wells Fargo Services responsible for IT Regulatory Compliance and was previously a partner at Ernst & Young and Arthur Andersen over their information systems security and IS audit groups over a span of nine years. Mike is a CISA and CISSP. He was the SF ISACA Chapter President during and the SF Fall Conference Co Chair from He also served for two years as Vice President on the Board of Directors for ISACA International. Currently, Mike is currently a Director in the LA ISACA Chapter, involved with the LA ISACA Spring Conference Committee, and is the CISA Review Course Coordinator

45 Questions & Answers