Payment Card Industry (PCI)Data Security Standards and Program

Jonathan Care

Senior Consulting Manager

PCI QSA PA-QSA CFE CISSP

2

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

3

Compliance Level Definitions - Merchants

Compliance Validation LevelAnnual Onsite Assessment

Quarterly Perimeter Scan

Self-Assessment

Questionnaire

Merchant Level 1

(Any merchant - regardless of channel - >6M

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)

Required Required N/A

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 Required

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

N/A Recommended Recommended

4

Compliance Level Definitions – Service Providers

Compliance Validation Level

Annual Onsite

Assessment

Quarterly

Perimeter Scan

Self-

Assessment

Questionnaire

Service Provider Level 1

(VisaNet connection; All Payment

Gateways; TPP and DSE that handle data

for Level 1 & 2 Merchants)

Required Required 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

5

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.

6

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

+ Segment credit card networks and control access to them

Future Considerations+ More application security

+ Mobile payments on the rise

7

The Standards

PCI-PEDPCI-PED PCI PA-DSSPCI PA-DSS PCI DSSPCI DSS

PCI PED addresses device characteristics impacting security of PIN Entry Device (PED)

during financial transactions

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 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 AlonePED Device

PCI PED applies – PED device only

PEDs integrated with payment applications

(POS, Kiosk)

PA-DSS may applyPCI DSS applies –

Systems and networks

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

Payment Applications inMerchant/Service Provider

Environment

Merchant’s and Service Provider’sCardholder data

environment

8

Sensitive Information in PCI

Data ElementStorage

Permitted

Protection

Required

PCI DSS

Req. 3.4

Cardholder

Data

Primary Account

Number (PAN)YES YES YES

Cardholder Name YES YES NO

Service Code YES YES NO

Expiration Date YES YES NO

Sensitive

Authentication

Data

Full Magnetic Stripe NO N/A N/A

CVC2/CVV2/CID/

CAV2NO N/A N/A

PIN/PIN Block NO N/A N/A

9

Why are Companies Failing PCI Assessments?

PERCENTAGE OF

ASSESSMENTS FAILING PCI REQUIREMENT

79%Requirement 3: Protect stored data.

Source: VeriSign Whitepaper on Top Reasons for PCI Failure based on sample of over 100 assessmentshttps://www.verisign.com/cgi-bin/go.cgi?a=w63130157259894009

74%Requirement 11: Regularly test security systems and processes.

71%Requirement 8: Assign a unique ID to each person with computer access.

71%Requirement 10: Track and monitor all access to network resources and cardholder data.

66%Requirement 1: Install and maintain a firewall configuration to protect data.

62%Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters.

60%Requirement 12: Maintain a policy that addresses information security.

59%Requirement 9: Restrict physical access to cardholder data.

56%Requirement 6: Develop and maintain secure systems and applications.

45%Requirement 4: Encrypt transmission of cardholder data and sensitive information across public networks.

10Confidential and Proprietary 1

0

Data Breaches vs. Data Protection (Here’s Why)

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

11Confidential and Proprietary 1

1

Data Breach Concerns

Source - Verizon 2009 Data Breach Report

12

+ 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

Confidential and Proprietary 12

PCI Terminology

13

+ 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.

Confidential and Proprietary 13

PCI Terminology – Compensating Controls

14

+ 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

Confidential and Proprietary 14

PCI Terminology – Cardholder Data Environment

15Confidential and Proprietary 1

5

Defining the Cardholder Environment (Client Example)

16

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.

Confidential and Proprietary 16

Transaction Data Flow (Client Example)

17

+ 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?

+ Ask the hard questions!▪ Why do you need this?▪ What would you do without it?

Confidential and Proprietary 17

Scoping

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

18Confidential and Proprietary 1

8

PCI DSS Summary

PCI DSS Requirement Summary Objectives

Build and maintain a secure network

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 data3. Protect stored cardholder data

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

Maintain a vulnerability management program5. Use and regularly update anti-virus software

6. Develop and maintain secure systems and applications

Implement strong access control measures

7. Restrict access to cardholder data by business need-to-know

8. Assign a unique ID to each person with computer access

8. Restrict physical access to cardholder data

Regularly monitor and test networks10. Track and monitor all access to network resources and cardholder data

11. Regularly test security systems and processes

Maintain an information security policy 12. Maintain a policy that addresses information security

19Confidential and Proprietary 1

9

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

20Confidential and Proprietary 2

0

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.

21

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

22

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

23

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

24

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 client’s 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,

25

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/security-

consulting/resources/index.html

+ Solutions Links▪ Compliance Solutions - http://www.verisign.com/verisign-business-

solutions/compliance-solutions/index.html ▪ PCI Compliance -

http://www.verisign.com/verisign-business-solutions/compliance-solutions/business-partner-solutions/payment-card-industry/index.html

▪ PCI Compliance Solutions Data Sheet - http://www.verisign.com/static/036131.pdf

26

PCI References

+ Payment Card Industry Data Security Standards: ▪ Merchants:

http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp_merchants.html?it=l2|/business/accepting_visa/ops_risk_management/cisp_payment_applications%2Ehtml|Merchants

▪ Service Providers: http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp_service_providers.html?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_applications.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_Validated_Payment_Applications.pdf

+ Compromised Entity Program: http://usa.visa.com/business/accepting_visa/ops_risk_management/cisp_if_compromised.html?it=l2|/business/accepting_visa/ops_risk_management/cisp_service_providers%2Ehtml|If%20Compromised

Thank You

VeriSign Security Services