Payment Card Industry
Payment Card Industry
Data Security Standard (PCI DSS) v1.2
Data Security Standard (PCI DSS) v1.2
Joint LA
Joint LA--ISACA and SFVISACA and SFV--IIA MeetingIIA Meeting February 19, 2009
©2009 2 All Rights Reserved
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
Agenda
Agenda
Introduction to PCI DSS
Introduction to PCI DSS
©2009 4 All Rights Reserved
//
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 2005.
PCI SSC
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, 2008. Version 1.1 is no longer effective as of December 31, 2008.
©2009 6 All Rights Reserved
PCI Security Standards
PCI Security Standards
PCI DSS 1.2 Requirements
PCI DSS 1.2 Requirements
Goals PCI DSS Requirements
1. Install and maintain a firewall configuration to protect cardholder data
Build and Maintain a Secure
Network 2. Do not use vendor-supplied defaults for system passwords and other security parameters
3. Protect stored cardholder data
Protect Cardholder Data
4. Encrypt transmission of cardholder data across open, public networks 5. Use and regularly update anti-virus software or programs
Maintain a Vulnerability Management Program
6. Develop and maintain secure systems and applications 7. Restrict access to cardholder data by business need-to-know 8. Assign a unique ID to each person with computer access
Implement Strong Access Control Measures
9. Restrict physical access to cardholder data
10. Track and monitor all access to network resources and cardholder data
Regularly Monitor and Test Networks
11. Regularly test security systems and processes
©2009 8 All Rights Reserved
Merchant Levels
Merchant Levels
Level VISA Criteria AMEX Criteria Required
Validation
1
• 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
• Over 2.5 million AMEX transactions per year • Any merchant
compromised in past year • AMEX discretion based on
risk
• Annual onsite assessment • Quarterly scans
required
2 • Between 1 million and 6 million transactions per year
• Between 50 thousand and 2.5 million AMEX
transactions per year
• Quarterly scans required
• Annual SAQ
3 • Between 20 thousand and 1 million e-commerce transactions per year
• Less than 50 thousand AMEX transactions per year • Annual SAQ • Quarterly scans VISA required • Quarterly scan AMEX “highly recommended” 4
• Less than 20 thousand e-commerce transactions per year and all others up to 1 million transactions per year
• N/A • Annual SQA
• Quarterly scan “may” be
Service Provider Levels
Service Provider Levels
Effective February 1, 2009, service providers that store, process or transmit Visa
©2009 10 All Rights Reserved
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.
Penalties for Non
Penalties for Non
-
-
Compliance
Compliance
http://www.internetretailer.com/internet/marketing-conference/80146-compliance-dilemma-html
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.
Qualified Security Assessors (QSA)
Qualified Security Assessors (QSA)
©2009 12 All Rights Reserved
Self
Self
-
-
Assessment Questionnaires (SAQ)
Assessment Questionnaires (SAQ)
Approved Scanning Vendor (ASV)
Approved Scanning Vendor (ASV)
©2009 14 All Rights Reserved
Lifecycle Process for Changes to PCI DSS
©2009 - 16 - All Rights Reserved
Types of Data on Payment Card
©2009 18 All Rights Reserved
Build and Maintain a Secure Network
Build and Maintain a Secure Network
©2009 20 All Rights Reserved
Protect Cardholder Data
©2009 All Rights Reserved
Protect Cardholder Data
Protect Cardholder Data
Maintain a Vulnerability Management Program
©2009 All Rights Reserved
Maintain a Vulnerability Management Program
Maintain a Vulnerability Management Program
-Implement Strong Access Control Measures
©2009 All Rights Reserved
Implement Strong Access Control Measures
Implement Strong Access Control Measures
-Implement Strong Access Control Measures
©2009 All Rights Reserved
Regularly Monitor and Test Networks
Regularly Monitor and Test Networks
-Regularly Monitor and Test Networks
©2009 All Rights Reserved
Maintain an Information Security Policy
Maintain an Information Security Policy
-Report on Compliance (ROC)
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
©2009 All Rights Reserved
Report on Compliance (ROC)
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
-Review of Marketing Collateral
©2009 34 All Rights Reserved Gartner Magic Quadrant 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, Q2 2008 Websense And Reconnex Top The Leaders Stack, Followed By Verdasys, RSA, And Vericept June 6, 2008 The Forrester Wave
POC Assessment
This is strictly a sample. There are many different ways to perform a
©2009 44 All Rights Reserved
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 2008.
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 2005‐2006 and the SF Fall Conference Co‐Chair from 2002–2007. 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.