The PCI Security Standards Council

Bob Russo April 6, 2010

AGENDA
What is the PCI SSC? Why does payment security matter?

What is the SSC doing to help?

What to expect in 2010

What is the PCI SSC ?

About the Council

Open, global forum Founded 2006 Responsible for PCI Security Standards
Development Management Education Awareness

PCI Standards

Founders

Organization

Board of Advisors

Financial Institutions
Bank of America Banrisul S.A Barclaycard National Australia Bank Royal Bank of Scotland JPMorgan Chase & Co

Merchants
Exxon Mobil Corporation McDonalds Corporation Lufthansa Systems Passenger Services Tesco Stores Ltd Wal-Mart Stores, Inc.

Processors
Chase Paymentech Solutions First Data Corporation Global Payments Inc TSYS Acquiring Solutions

Associations & Vendors

European Payments Council PayPal Cisco Citrix Systems, Inc. MICROS Systems, Inc. VeriFone

Standards Development Drivers

Advisory Board

Industry Best Practices

Community Meeting

Proactive feedback from POs and Assessor Community

PCI Data Security Standard

Approved Scanning Vendors (ASVs) and Qualified Security Assessors (QSAs)

ADC Forensics Results

Security Scans

On-Site Audits

SelfAssessment Questionnaire

PCI Standards Lifecycle

Ground Rules

PCI SSC.
Is an Independent Industry Standard Manages the technical and business requirements for how payment data should be stored and protected Maintains List of Qualified PCI Assessor Community
QSAs, ASVs, PA-QSA and PED Labs

PCI SSC Does Not

Manage or Drive Compliance
Each brand continues to maintain its own compliance programs
Identifies stakeholders that need to validate compliance Definitions of Validation Levels Fines and Fees

Council Resources Security standards and supporting documents Quick Reference Guide Searchable Frequently Asked Questions List of approved QSAs, ASVs, PA-QSAs, PED Labs Education and outreach - e.g., fact sheets, case studies Participating membership, meetings, collaboration A global voice for the industry

Why does payment security matter ?

Changing a mindset

Threat Landscape Implementing the Standard is a Journey Not a Destination

Risky Behavior
81% store payment card numbers 73% store payment card expiration dates 53% store customer data from magnetic stripe on card 16% store other personal data
Source: Forrester Consulting, September 2007

Value of Compliance
Cost of Complying
Upgrading payment systems and security Verifying compliance via assessment

Cost of a Breach
Crisis upgrades Repeat assessments Notification Brand reputation loss

Sustaining compliance
May cost millions for complex or older systems

Shareholder and consumer lawsuits

May cost 20 times the price of compliance

PCI Compliance Cost Analysis: A Justified Expense. A joint analysis conducted by Solidcore Systems, Emagined Security and Fortrex. January 2008 [This study utilized data from several sources including level 1 and level 2 merchants with 2,000 2,500 retail locations.]

Top Violations Common Audit / Forensic Results Bad or no firewall Unprotected stored data Insecure systems and applications

No unique user IDs

No tracking or monitoring of access No regular tests of security No security policy

Forensics Statistics
> 80% Payment Cards vs. Others
Consumer data:
Incident Detection 70% via third party detection or notification 13% employee detection 11 % unusual system behavior 6% log monitoring 2% routine internal audit Payment card information -Credit / Debit -Card-present / CNP Personal Check information

Inside Jobs vs. Intrusions 20% Inside ~74% were external sources

Attack vector (by records) 79% Web Application (SQL injection) 27% Remote Access 26% End User Systems 11% Network Devices

Identity-related data:
Name, address, email Social security, Social insurance IRS / tax return information

2008 saw only a single instance in which a wireless network was exploited

Time span of Breach Compromise to Discovery 8% - hours 16% - days 25% - weeks 49% - months

Company-proprietary:
Financial records HR / employee data Product strategy & roadmap Trade secrets & technology

The typical breached organization had met less than a third of the requirements of the PCI DSS

Did You Know?

According to Verizons 2009 Data Breach Investigations Report (DBIR) 75% of compromises were discovered at least weeks after the compromise. Post-breach reviews resulted in the discovery that:
Breached organizations only had 11% compliance level for Req 3 (Protect card holder data). only 5% compliance level for Req 10 (track & monitor all access to network resources and cardholder data)

Data security is not all about prevention; it also requires detection and monitoring!

The Five Stages of Grief

Denial
Anger

20

It doesnt apply to me
PCI compliance is mandatory

It isnt fair
PCI applies to all parties in the payment process Compliance is pass / fail

Bargaining
Depression Acceptance

Ill do some of it

Ill never get there

Many merchants already have

PCI doesnt introduce any new, alien concepts

Itll be OK

What is the SSC doing to help ?

PCI Data Security Standard

The PCI Data Security Standard

Six Goals
Build and Maintain a Secure Network

Twelve 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

Protect Cardholder Data

3. Protect stored cardholder data 4. Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program Implement Strong Access Control Measures

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 8. Assign a unique ID to each person with computer access 9. Restrict physical access to cardholder data 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

Regularly Monitor and Test Networks Maintain an Information Security Policy

Self-Assessment Questionnaire

Self-Assessment Questionnaire
SAQ Validation Type Description SAQ

Card-Not-Present (e-commerce or MO/TO) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants Imprint-only merchants with no cardholder data storage Stand alone dial-up terminal merchants, no cardholder data storage Merchants with payment application systems connected to the Internet, no cardholder data storage

A
<11 Questions

2 3

B
21 Questions

B
21 Questions

C
38 Questions

5
3/31/2010

All other merchants (not included in descriptions for SAQs A, B or C above) and all service providers defined by a payment brand as eligible to complete an SAQ

D
Full DSS

PCI DSS Applicability Information

Data Element Primary Account Number (PAN) Cardholder Data Cardholder Name [1] Service Code 1 Expiration Date 1 Sensitive Authentication Data [2] Full Magnetic Stripe Data [3] CAV2/CVC2/CVV2/CID PIN/PIN Block
[1]These

Storage Permitted Yes Yes Yes Yes No No No

Protection Required Yes Yes 1 Yes 1 Yes 1 N/A N/A N/A

Rendered Unreadable Yes No No No N/A N/A N/A

data elements must be protected if stored in conjunction with the PAN. This protection should be per PCI DSS requirements for general protection of the cardholder data environment. Additionally, other legislation (e.g., related to consumer personal data protection, privacy, identity theft, or data security) may require specific protection of this data, or proper disclosure of a company's practices if consumer-related personal data is being collected during the course of business. PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted. [2]Sensitive authentication data must not be stored after authorization (even if encrypted). [3]Full track data from the magnetic stripe, magnetic stripe image on the chip, or elsewhere.

Payment Application DSS

Payment Application DSS

14 RequirementsProtecting Payment Application Transactions
Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2) or PIN block data Provide secure password features

Protect stored cardholder data

Log Application Activity Develop Secure Applications Protect wireless transmissions Test Applications to address vulnerabilities Facilitate secure network implementation Cardholder data must never be stored on a server connected to the Internet Facilitate secure remote software updates Facilitate secure remote access to application Encrypt sensitive traffic over public networks Encrypt all non-console administrative access Maintain instructional documentation and training programs for customers, resellers, and integrators

Payment Application-DSS
Payment Application Data Security Standard

453 applications across 250 vendors

303 Visa PABP applications transitioned

150 new PA-DSS applications in 2009

Visa PABP list decommissioned during Q1 2010 PA-DSS Program Guide updated

PIN Transaction Security (PTS)

PIN Transaction Security (PTS)

PTS Requirements
Device Characteristics Device Management

Physical security
Logical security

During manufacturing
Between manufacturing and initial key loading Addresses lifecycle of how PED is produced, controlled, transported, stored and used

PIN Transaction Security (PTS)

Spring 2009 New areas for PTS program beyond attended POS for secure PIN entry Unattended payment terminals (UPTs such as fuel pumps, kiosks) Hardware / host security modules (HSMs as noncardholder interfaces or embedded devices) Summer 2009

New name for program PTS PIN Transaction Security Program

Reflects expansion of device and non device types coming under the program

Spring 2010
PTS standard currently out with Participating Organizations for final review Due to release to market on April 30 2010

The PIN Transaction Security Umbrella

Point of Interaction

Hardware Security Module (HSM)

(tbd)

The Point of Interaction

POS PED Vending Ticketing

ATM Car Park

Fuel

Other?

2010- One Modular Evaluation process

POI Device

PIN Pad

Display

Card Reader

Cabinet

O/S

Secure controller

IP/Wireless (MC PTS)

Additional Displays

Additional keypads

Crypto Module

Applies to all approval classes: PED, EPP, UPT, ATM

Resources

Council Resources Security standards and supporting documents Quick Reference Guide Searchable Frequently Asked Questions List of approved QSAs, ASVs, PA-QSAs, PED Labs Education and outreach - e.g., fact sheets, webinars Participating membership, meetings, collaboration A global voice for the industry

PCI Quick Reference Guide

PCI DSS Prioritized Approach

Prioritized Approach Tools

PCI DSS Prioritized Approach How was it created?

Payment brands examination of account data compromise events Feedback from PCI SSC Board of Advisors, Council leadership and the Technical Working Group Feedback from several QSAs and forensics investigators Asked to identify the top 15 PCI DSS requirements for protecting cardholder data

PCI DSS Prioritized Approach Six Security Milestones

Milestone One - If you dont need it, dont store it. The intent of Milestone One is to remove sensitive authentication data and limit data retention. This milestone targets a key area of risk for entities that have been compromised if sensitive authentication data and other cardholder data had not been stored, the effects of the compromise would have been greatly reduced. Milestone Two - Secure the perimeter. The intent of Milestone Two is to protect the perimeter, internal, and wireless networks. This milestone targets a key area that represents the point of access for most compromises: vulnerabilities in networks or at wireless access points. Milestone Three - Secure applications. The intent of Milestone Three is to secure applications. This milestone focuses on applications, as well as application processes and application servers, since application weaknesses are a key access point used to compromise systems and obtain access to cardholder data.

PCI DSS Prioritized Approach

Milestone Four - Control access to your systems. The intent of Milestone Four is to protect the cardholder data environment through monitoring and access control since this is the key method to detect the who, what, when and how about who is accessing your network. Milestone Five - Protect stored cardholder data. For those organizations that have analyzed their business processes and determined that they must store Primary Account Numbers, Milestone Five targets key protection mechanisms for that stored data. Milestone Six - Finalize remaining compliance efforts, and ensure all controls are in place. The intent of Milestone Six is to complete PCI DSS requirements and finalize all remaining related policies, procedures, and processes needed to protect the cardholder data environment.

Standards Training First PCI SSC Standards Training Merchant training endorsed by PCI SSC
Objective: Arm merchants with everything they need to know to best prepare for an onsite PCI DSS inspection or to perform the assessment internally

Focus: Four key modules

PCI Program defining the payment card industry Scoping a PCI DSS Assessment PCI DSS v1.2 Requirements Compensating Controls

Where: 5 locations in 2009, stay tuned for 2010 schedule

Education Fact sheets and Information Supplements - Wireless

Education Fact sheets and Information Supplements - Skimming

QSA Quality Assurance Program

Quality Assurance Lifecycle for Assessors
Application & Renewal Validate that business criteria of the Assessor Company and expected level of experience for Assessor Employee are met Training Validate that training is fair, comprehensive and available Testing Validate that testing is fair to all applicants, relevant to the training and requirements and integrity of test taker is upheld Performance Monitoring Review all feedback form submissions including proactive review by QA Team, evaluate performance of assessor while in probation
Performance Monitoring Testing

Application & Renewal Process

Training

Expanded Communications

More opportunity for interaction with PCI SSC - 3347 webinar registrants in 2009 - 359 open mic questions - PST, ET, GMT, CET timed opportunities - Replays and questions posted online

Global Focus Multilingual Website

Whats ahead in 2010 ?

Whats Next?

2010 Deliverables Roadmap

Nov. 2009 April 2010 DSS and PA-DSS Feedback Review Process Feedback Highlights to Board of Advisors, market in spring April 2010 New PIN Transaction Security (PTS) standard released Early Summer 2010 Summary of DSS changes provided to Participating Organizations

Oct. 18 - 20, 2010 European Community Meeting, Barcelona, Spain

April 2010

May 2010

June 2010

July 2010

Aug. 2010

Sept. 2010

Oct. 2010

Spring 2010 Emerging technologies framework

May 2010 Draft DSS provided to Board of Advisors for review and feedback

Sept. 21- 23, 2010 US Community Meeting, Orlando, Florida

October 2010 Next iteration of DSS and PA-DSS released to public

Standards Lifecycle

Feedback Hundreds of pieces of feedback through: Online FAQ submissions Regular inquiries Lifecycle feedback form Speaking engagements Open Mics SIGs Initial Feedback Considerations: Clarifications within the Standard More Detailed Guidance Evolving Requirements

Feedback Demographics
Australia Canada Finland France Germany Global Great Britain India Ireland Italy Latvia Mexico New Zealand South Africa Spain Sweden Switzerland The Netherlands United States

Feedback Demographics

ASV
Financial Institution Merchant

Other
POS Vendor Processor QSA

Feedback Examples

Should cardholder data discovery tools/methods be used to find "unknown" cardholder data? What is acceptable "strong cryptography? What about attack trends targeting cardholder data in volatile memory?

Feedback Examples

How do I implement network segmentation to reduce PCI DSS scope?

Which SAQ is applicable to me? What constitutes a payment application and when is PADSS applicable? Access controls for cashiers

Sounds simple? Feedback can be conflicting

I think the password requirement should be more than 7 characters Passwords are too long, a maximum of 6 characters is sufficient The SSC should maintain current requirements around password length

There are a variety of competing interests among stakeholders vendors, merchants, acquirers, assessors

Sounds simple? Some people like things just the way they are
The 90 day rule for password changes works

Others have a different take on the same topic

We need tighter guidelines around password change frequency The password change requirement is too strict--every 180 days should be enough

The volume of feedback is significant. This process takes time!

Sounds simple? Many considerations before introducing changes:

What is best for data security? Global applicability, local market concerns Sunset dates for other requirements Cost/benefit of changes to infrastructure Cumulative impact of changes

Final word on feedback

The Council has received feedback and input from all stakeholders and market verticals since the last revision

Feedback falls into 3 main categories and the SSC is considering numerous points for the next iteration of the standard Guidance, clarification, and evolution Feedback analysis period closes April 30, 2010

Next steps are to provide executive summary of feedback to the market

2010 Deliverables Roadmap

Nov. 2009 April 2010 DSS and PA-DSS Feedback Review Process Feedback Highlights to Board of Advisors, market in spring April 2010 New PIN Transaction Security (PTS) standard released Early Summer 2010 Summary of DSS changes provided to Participating Organizations

Oct. 18 - 20, 2010 European Community Meeting, Barcelona, Spain

April 2010

May 2010

June 2010

July 2010

Aug. 2010

Sept. 2010

Oct. 2010

Spring 2010 Emerging technologies framework

May 2010 Draft DSS provided to Board of Advisors for review and feedback

Sept. 21- 23, 2010 US Community Meeting, Orlando, Florida

October 2010 Next iteration of DSS and PA-DSS released to public

Special Interest Groups What do Special Interest Groups do?

Opportunity to leverage Participating Organizations expertise SIGs analyze and address specific industry challenges SIGs determine own deliverables Recommend changes, clarifications, improvements, best practices, etc. Work with Board of Advisor Leader to channel info into the SSC SIGs dissolve after deliverable is achieved New SIGs can be proposed at any time

How to form or join a SIG sigs@pcisecuritystandards.org

Special Interest Groups

Current SIGs - Wireless - Virtualization - Scoping - Pre-Authorization

Wireless SIG Wireless Guidelines

Community Meetings

Merchants

Acquirers

Approved Scanning Vendors

Qualified Security Assessors

Community Meeting

Service Providers

Brands

Community Meetings Two Meetings in 2010

Orlando, Florida
September 21 23, 2010

Barcelona, Spain October 18 20, 2010

Join us as a Participating Organization to get involved in setting global PCI standards!

Summary Focus on security, not compliance Understand the process of PCI standards development Join us as a Participating Organization Play an active role in shaping standards through a Special Interest Group Share the PCI SSC roadmap with internal stakeholders

Security is Only as Good as the Weakest Link

Thank You!