Payment Card Industry (PCI) Data Security Standards and Program

Jonathan Care
Senior Consulting Manager
PCI QSA PA-QSA CFE CISSP

PCI Overview
+ Started in 2001 as then separate programs

Cardholder Information Security Program (VISA) Site Data Protection (SDP) Program (MasterCard)

+ Standards consolidated in 2004 under the naming of the Payment Card

Industry (PCI) Data Security Standard (DSS)

+ Standards include the Digital Dozen 12 core requirements

+ Quarterly Scanning Requirements mandated in 2004 for public facing

sites and systems

+ Payment Application Best Practices Program launched in 2005 to

target security around payment applications + What Compliance Means for Merchants and Service Providers Everyone must comply with the standards Based on what category you fall into determines what level of validation
you must provide (i.e. audits/scans)

Annual penetration tests are required, although not required to be

submitted

Compliance Level Definitions - Merchants

Compliance Validation Level Merchant Level 1
(Any merchant - regardless of channel - >6M

Annual Onsite Assessment Required

Quarterly Perimeter Scan Required

SelfAssessment Questionnaire N/A

transactions)
Any merchant that has suffered a hack. Any merchant that any CC Association, determines should meet the Level 1 merchant. Any merchant identified by any payment card

brand as Level 1)

Merchant Level 2
(*1M to 6M Visa regardless of channel)

Required

Required

Required

Merchant Level 3
(*20K-1M Visa e-commerce transxs)

N/A

Required
Recommended

Required
Recommended

Merchant Level 4
( <20K Visa e-commerce &/or <6M all other transxs)

N/A

Compliance Level Definitions Service Providers

Compliance Validation Level Service Provider Level 1
(VisaNet connection; All Payment Gateways; TPP and DSE that handle data for Level 1 & 2 Merchants)

Annual Onsite Assessment Required

Quarterly Perimeter Scan Required

SelfAssessment Questionnaire N/A

Service Provider Level 2

(Not Level 1 w/ >1M transactions; DSE that handle data for Level 3 Merchants)

Required

Required

N/A

Service Provider Level 3

(<1M transactions; all other DSEs)

N/A
+ +

Required

Required

TPP = Third Party Processors DSE = Data Storage Entity

Key issues leading to PCI breaches

+ Unsecured physical assets (e.g. laptops, USB devices) + Point of sale (POS) application vulnerabilities + Unencrypted spreadsheet data + Poor identity management + Network architecture flaws; flat networks and card numbers in

the DMZ
+ Lack of log monitoring and intrusion detection system (IDS) data; poor logging tools.

Implications of Trends
What Can You Do?
+ Store less data + Understand the flow of data + Encrypt data + Address application and network vulnerabilities + Improve security awareness and training + Monitor systems for intrusions and anomalies

Future Considerations
+ More application security + Mobile payments on the rise

+ Segment credit card networks and control access to them

The Standards
PCI-PED
PCI PED addresses device characteristics impacting security of PIN Entry Device (PED) during financial transactions

PCI PA-DSS
PA-DSS applies to software vendors and others who develop payment applications that store, process or transmit cardholder data as part of authorisation or settlement, where those applications are sold, distributed or licensed to third parties.

PCI DSS
PCI DSS applies to any entity that stores, processes and/or transmits cardholder data, and specifically to those system components included in or connected to the cardholder data environment

Stand Alone PED Device

Payment Applications (e.g. Web Cart, POS)

Merchants and Service Providers Cardholder data environment

PEDs integrated with payment applications (POS, Kiosk)

Payment Applications in Merchant/Service Provider Environment

PCI PED applies PED device only

PA-DSS may apply

PCI DSS applies Systems and networks

Sensitive Information in PCI

Data Element Primary Account Number (PAN) Storage Permitted YES YES YES YES NO Protection Required YES YES YES YES N/A PCI DSS Req. 3.4 YES NO NO NO N/A

Cardholder
Data

Cardholder Name Service Code Expiration Date Full Magnetic Stripe

Sensitive Authentication Data

CVC2/CVV2/CID/ CAV2
PIN/PIN Block

NO
NO

N/A
N/A

N/A
N/A

Why are Companies Failing PCI Assessments?

PCI REQUIREMENT
Requirement 3: Protect stored data. Requirement 11: Regularly test security systems and processes. Requirement 8: Assign a unique ID to each person with computer access. Requirement 10: Track and monitor all access to network resources and cardholder data. Requirement 1: Install and maintain a firewall configuration to protect data.

PERCENTAGE OF ASSESSMENTS FAILING

79% 74% 71% 71% 66%

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.
Requirement 12: Maintain a policy that addresses information security. Requirement 9: Restrict physical access to cardholder data. Requirement 6: Develop and maintain secure systems and applications. Requirement 4: Encrypt transmission of cardholder data and sensitive information across public networks.
Source: VeriSign Whitepaper on Top Reasons for PCI Failure based on sample of over 100 assessments https://www.verisign.com/cgi-bin/go.cgi?a=w63130157259894009

62%
60% 59% 56% 45%

Data Breaches vs. Data Protection (Heres Why)

**Gartner Toolkit Presentation: PCI Compliance Is Hard to Achieve but Worthwhile - 4 May 2007

10
Confidential and Proprietary

10

Data Breach Concerns

Source - Verizon 2009 Data Breach Report

11
Confidential and Proprietary

11

PCI Terminology
+ + + + + PCI Payment Card Industry PAN Primary Account Number is the payment card number (credit or debit) that identifies the issuer and the particular cardholder account Acquirer - Bankcard association member that initiates and maintains relationships with merchants that accept payment cards Cardholder Data - Full magnetic stripe or the PAN plus any of the following: Cardholder name, Expiration date, Service Code Track Data - Data encoded in the magnetic stripe used for authorization during transactions when the card is presented. Entities must not retain full magnetic stripe data subsequent to transaction authorization. Specifically, subsequent to authorization, service codes, discretionary data, Card Validation Value / Code, and proprietary reserved values must be purged; however, account number, expiration date, name, and service code may be extracted and retained, if needed for business

12
Confidential and Proprietary

12

PCI Terminology Compensating Controls

+ Compensating controls may be considered when an entity cannot meet a requirement explicitly as stated, due to legitimate technical or documented business constraints but has sufficiently mitigated the risk associated with the requirement through implementation of other controls.

Compensating controls must:

meet the intent and rigor of the original stated PCI DSS requirement; repel a compromise attempt with similar force; be above and beyond other PCI DSS requirements (not simply in compliance with other PCI DSS requirements); and be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement

Compensating Controls can be used for any requirement except for 3.2

If you are using a compensating control for 3.4, you must use the spreadsheet located in Appendix C.

13
Confidential and Proprietary

13

PCI Terminology Cardholder Data Environment

+ Area of computer system network that possesses cardholder data or sensitive authentication data and those systems and segments that directly attach or support cardholder processing, storage, or transmission. Adequate network segmentation, which isolates systems that store, process, or transmit cardholder data from those that do not, may reduce the scope of the cardholder data environment and thus the scope of the PCI assessment

The PCI DSS security requirements apply to all system components A system component is any network component, server or application that is included in or connected to the cardholder data environment The cardholder environment is that part of the network that stores, processes, or transmits cardholder data or sensitive authentication data

14
Confidential and Proprietary

14

Defining the Cardholder Environment (Client Example)

15
Confidential and Proprietary

15

Transaction Data Flow (Client Example)

1. Customer swipes card, POS terminal builds authorization package. 2. Authorization package goes to POS controller, and on to corporate for processing. 3. Corporate sends to bank for approval. 4. Authorization is received from the bank, and corporate systems then check to see if they have seen this card before.
1. If the card has been used before, retrieve token. 2. If this is a new card, generate a new token.

5. Return the token to the POS controller and complete the transaction.

16
Confidential and Proprietary

16

Scoping

+ What do you NEED to store?

What data is available to you? What are the business and legal needs? Where do you need to store this? What is the risk associated? Why do you need this? What would you do without it?

+ Ask the hard questions!

**Payment Card Industry Data Security Standards SAP v1.2 Appendix F

17
Confidential and Proprietary

17

PCI DSS Summary

PCI DSS Requirement 1. Build and maintain a secure network 2. Summary Objectives Install and maintain a firewall configuration to protect cardholder data Do not use vendor-supplied defaults for system passwords and other security parameters Protect stored cardholder data Encrypt transmission of cardholder data across open, public networks Use and regularly update anti-virus software Develop and maintain secure systems and applications Restrict access to cardholder data by business need-to-know Assign a unique ID to each person with computer access Restrict physical access to cardholder data Track and monitor all access to network resources and cardholder data Regularly test security systems and processes

3. Protect cardholder data 4. 5.

Maintain a vulnerability management program

6. 7. Implement strong access control measures 8. 8. 10. Regularly monitor and test networks 11. Maintain an information security policy

12.

Maintain a policy that addresses information security

18
Confidential and Proprietary

18

Goals for v1.2 Release

+ Provide greater clarity on PCI DSS requirements + Offer improved flexibility + Manage any evolving risks and threats + Incorporate best practices + Clarify scoping and reporting + Eliminate redundant sub-requirements + Consolidate documentation

19
Confidential and Proprietary

19

Impact from 1.1 to 1.2

+ Language Changes Many clarifications were made to simplify or harmonize naming conventions and intent throughout the standard. REMOVED from Merchant Validation - Any data repositories outside of the authorization and settlement environment where more than 500 thousand account numbers are stored. Wireless New WEP implementations not allowed after March 31, 2009 and removal by June 30, 2010. Definition change to include wireless technologies AV - applies to all operating systems types commonly affected by malicious software, if applicable anti-virus technology exists. (removed exclusions of UNIX and Mainframe) Service Providers - clarified that organizations must have policies and processes implemented to manage and monitor service providers.

20
Confidential and Proprietary

20

Timeframes for a PCI incident investigation

+ Timeframes (e.g., flexibility on critical events)

Standard event timeframes

Visa client must identify forensic company within 5 days Visa client must ensure contract is signed within 10 days Forensic investigator must be onsite within 5 days from signed contract Preliminary forensic report be provided to Visa within 5 days from onsite work Final forensic report be provided to Visa within 10 business days from the completion of the review

Critical event timeframes can be even more immediate!

+ Visa will levy fines to clients in the event of delays

21

PCI Forensic Investigation Requirements

VISA appointed forensic reports must include:

All external connectivity points and network topology including firewalls, routing schema, VLANs, etc. between compromised systems and surrounding networks A review of the entire debit and or credit processing network to identify all compromised or affected systems

External Investigators will perform incident validation and assessment:

Establish how compromise occurred Identify the type of data stored, sniffed, and transferred out of the network (Visa/Plus/Interlink/Pre-Paid accounts) Recover data deleted by intruder Number of accounts at risk (stored, sniffed, and transferred) Determine the timeframe of compromise Determine transaction dates of compromised cardholder data

22

VeriSign Consulting Solutions for PCI

+ PCI Onsite Assessments + Annual Penetration Testing + Payment Application Best Practice (PABP) Certification + Other Application Security Assessments including:

Application Penetration Testing Code Review

+ Compromised Entity Investigations (Incident Response and Forensics) + Rapid Compliance Remediation

Assistance with failed PCI assessments GSC has team with several large merchants and service providers to help them overcome audit deficiencies and become PCI compliant

23

Additional Services
+ Vulnerability Management Services

PCI Scanning Services (Basic) Network vulnerability scanning as well as

application scanning for Cross Site Scripting and SQL Injection as required PCI Scanning Services (Enhanced) - Includes Basic Service and also includes additional application checks and testing for a more thorough evaluation

+ Firewall Management Service - Monitoring and maintenance of firewall

rule sets and logs, meeting Requirement 1 Maintain a Working Firewall.

+ Intrusion Detection Management - Network and host-based

monitoring for attacks against the clients infrastructure, meeting Requirement 11.4 and 12.3.9 Implement Intrusion Detection System.
+ Log Monitoring Service Meets requirement 10.2 requires the implementation of automated audit trails.

+ Unified Authentication For requirement 8.3 which requires companies

to implement 2-factor authentication for remote access to the network by employees, administrators, and third parties,

24

VeriSign References
+ White Papers
Top Reasons for PCI Audit Failure Eliminating Card Numbers to Minimize PCI Exposure http://www.verisign.com/products-services/security-services/securityconsulting/resources/index.html

+ Solutions Links

Compliance Solutions - http://www.verisign.com/verisign-businesssolutions/compliance-solutions/index.html PCI Compliance - http://www.verisign.com/verisign-businesssolutions/compliance-solutions/business-partner-solutions/paymentcard-industry/index.html PCI Compliance Solutions Data Sheet http://www.verisign.com/static/036131.pdf

25

PCI References
+ Payment Card Industry Data Security Standards:

Merchants: http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp_merchants.html?it=l 2|/business/accepting_visa/ops_risk_management/cisp_payment_applications%2Ehtml|Merc hants Service Providers: http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp_service_providers.h tml?it=l2|/business/accepting_visa/ops_risk_management/cisp_merchants%2Ehtml|Service %20Providers

Payment Application Best Practice Standards: http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp_payment_a pplications.html?it=l2|/business/accepting_visa/ops_risk_management/cisp_payment _applications%2Ehtml|Payment%20Applications PCI Approved Applications: http://usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_V alidated_Payment_Applications.pdf Compromised Entity Program: http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp_if_compromi sed.html?it=l2|/business/accepting_visa/ops_risk_management/cisp_service_provider s%2Ehtml|If%20Compromised

26

Thank You
VeriSign Security Services