Risk Management Practices for PCI DSS 2.0

© 2011 ISACA. All rights reserved.

Risk Management Practices for PCI DSS 2.0

Ulf Mattsson

CTO Protegrity

ulf.mattsson [at] protegrity.com


Ulf Mattsson

• 20 years with IBM Development & Global Services • Inventor of 22 patents – Encryption and Intrusion

Prevention• Co-founder of Protegrity (Data Security)• Research member of the International Federation for

Information Processing (IFIP) WG 11.3 Data and Application Security

• Member of– PCI Security Standards Council (PCI SSC)– American National Standards Institute (ANSI) X9– Information Systems Audit and Control Association

(ISACA)– Institute of Internal Auditors (IIA)– Information Systems Security Association (ISSA)– Cloud Security Alliance (CSA)

02


ISACA Articles

03

Volume 6, November, 2011

Choosing the Most Appropriate Data Security Solution for an Organization

Ulf Mattsson, CTO, Protegrity


04


Agenda

1. Present trends in data breaches

2. Review data security methods available today

3. Discuss emerging technologies for protecting data

4. Present what tokenization is and how it differs from other data security methods

5. Review case studies on how new technologies can minimize costs and complexities

6. Summary and conclusion

05


Data Breaches

06


The Attacks on Sony Corporation

• Majority of attacks were SQL Injection - not advanced• Data including passwords and personal details were not encrypted• Data stolen

– 77 million names, addresses, passwords – 102 million email addresses, birth dates– 25 million phone numbers and payment cards– 54 Mbyte Sony software code

• 21 uncoordinated attacks during Apr 4 to Jul 6, 2011• 55 class action suits in the US (8/16/2011)• Sony’s stock dropped 30 percent after attacks were disclosed

Source: http://defensesystems.com/articles/2011/07/18/digital-conflict-cyberattacks-economy-security.aspx

07


The Attack on RSA Security

• Attackers stole information relating to the SecurID two-factor authentication technology

• APT malware tied to a network in Shanghai• 60 different types of customized malware to

launch their attacks• Based on a commonly used tool written by a

Chinese hacker 10 years ago

08


The AT&T Breach

• Security vulnerability in a Web site used by iPad customers• Programming tricked the site into divulging e-mail addresses • 100,000 e-mail addresses and iPad identification numbers were exposed • Some examples

• New York Mayor Michael Bloomberg, • FBI, • US Departments of Defense and Justice, • NASA, • Executives from Google, Microsoft, • Amazon, Goldman Sachs, and JP Morgan

9

Source 2010: http://news.cnet.com/8301-27080_3-20007417-245.html#ixzz1Y9IW9a7o

http://news.cnet.com/8301-27080_3-20007417-245.html


“It is fascinating that the top threat events in both 2010 and 2011 are the same

and involve external agents hacking and installing malware to compromise the confidentiality and integrity of servers.”

Best Source of Incident Data*

Source: 2011 Data Breach Investigations Report, Verizon Business RISK team*: Securiosis

010


Who is Behind Data Breaches*?

Business partners (-10%)

Multiple parties (-18%)

Insiders (-31%)

External agents (+22%)

0 10 20 30 40 50 60 70 80 90100

*: Number of breachesSource: 2011 Data Breach Investigations Report, Verizon Business RISK team and USSS

%

011


Demographics

• Criminals may be making a classic risk vs. reward decision and opting to “play it safe” in light of recent arrests and prosecutions following large-scale intrusions into Financial Services firms.

• Numerous smaller strikes on hotels, restaurants, and retailers represent a lower-risk alternative– Cybercriminals may be taking greater advantage of

that option

012


Compromised Data Types*

Sensitive organizational data

System information

Classified information

Medical records

Bank account data

Intellectual property

Usernames, passwords

Personal information

Payment card data

0 20 40 60 80 100 120%

013

*: Number of recordsSource: 2011 Data Breach Investigations Report, Verizon Business RISK team and USSS



Industry Groups Represented*

Business Services

Healthcare

Media

Transportation

Manufacturing

Tech Services

Government

Financial Services

Retail

Hospitality

0 5 10 15 20 25 30 35 40 45%

014


Breach Discovery Methods*

%

Third party monitoring service

Brag or blackmail by perpetrator

Internal fraud detection

Internal security audit or scan

Reported by employee

Unusual system behavior

Reported by customer/partner effected

Notified by law enforcement

Third party fraud detection

0 5 10 15 20 25 30 35 40 45 50

015



Trend in Number of Breaches*

%

Social (-17%)

Misuse (-31%)

Physical (+14%)

Malware (+11%)

Hacking (+10%)

0 10 20 30 40 50 60


016


How are Records Breached*

%

Social

Misuse

Error

Physical

Malware

Hacking

0 10 20 30 40 50 60 70 80 90 100

017

*: Number of recordsSource: 2011 Data Breach Investigations Report, Verizon Business RISK team and USSS


Most Important Trends in DBIR

018

Source: Securosis comments on 2011 Data Breach Investigations Report, Verizon Business RISK team

• The industrialization of attacks: – There is an industry encompassing many actors, from coders to attackers to

money launderers– They use automated tools and manage themselves and their operations as

businesses – including use of independent contractors

• All forms of attack are up by all threat actors: – APT and IP loss serious issues

• Law enforcement really does catch some of the bad guys: – 1,200 arrests over the past several years by the Secret Service alone.– Many of these bad guys/gals attack small business


Data Security - Catch-22

• We need to protect both data and the business processes that rely on that data

• Enterprises are currently on their own in deciding how to apply emerging technologies for PCI data protection– Data Tokenization - an evolving technology– How to reduce PCI audit scope and exposure to data

019


Protecting the

Data Flow

020


Protecting the Data Flow - Example

Protected sensitive information

Unprotected sensitive information:

: Enforcement point

021


PCI DSS

022


AttackerPublic

Network

OS File System

Database

Storage System

Application

SS

LPrivate Network

Data At Rest

(PCI DSS)

Clear Text Data

EncryptedData

(PCI DSS)

EncryptedData

(PCI DSS)

Clear Text Data

PCI Encryption Rules

023

http://images.google.com/imgres?imgurl=http://www.mpe07.co.uk/images/RG500%201ST&2ND&6TH%20001.jpg&imgrefurl=http://www.mpe07.co.uk/prod04.htm&usg=__Pa6UYFze3K8kG2MoTMQIXlYGvXo=&h=480&w=640&sz=53&hl=en&start=41&sig2=VBaCW478RZ4NL4EA33P_hg&um=1&tbnid=M1ycfOYMbrwmkM:&tbnh=103&tbnw=137&prev=/images?q=gear+pair&ndsp=20&hl=en&rlz=1T4SKPB_enUS294US294&sa=N&start=40&um=1&ei=0_L_SoWqIYXSnAef86m4Cw


PCI DSS

Payment Card Industry Data Security Standard (PCI DSS)

The PCI Security Standards Council is an open global forum

American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc

The PCI standard consists of a set of 12 rules

Four ways to render the PAN (credit card number) unreadable Two-way cryptography with associated key management processes Truncation One-way cryptographic hash functions Index tokens and pads

Source: https://www.pcisecuritystandards.org/organization_info/index.php

024


PCI DSS #3 & 4

Protect Cardholder Data • 3.4 Render PAN, at minimum, unreadable anywhere it is

stored by using any of the following approaches:• One-way hashes based on strong cryptography• Truncation• Index tokens and pads (pads must be securely stored)• Strong cryptography with associated key-management processes and procedures

• 4.1 Use strong cryptography to safeguard sensitive cardholder data during transmission over open, public networks.

• Comments – Cost effective compliance• Encrypted PAN is always “in PCI scope”• Tokens can be “out of PCI scope”

025


PCI DSS - Appendix B:

• Compensating controls must satisfy the following criteria:– Meet the intent and rigor of the original PCI DSS requirement.– Provide a similar level of defense as the original PCI DSS requirement, such that the

compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against.

– Be “above and beyond” other PCI DSS requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.)

026


PCI Tokenization Guidelines

027


PCI DSS - Network Segmentation

• Network segmentation of, or isolating (segmenting), the cardholder data environment from the remainder of an entity’s network is not a PCI DSS requirement.

• However, it is strongly recommended as a method that may reduce:– The scope of the PCI DSS assessment– The cost of the PCI DSS assessment– The cost and difficulty of implementing and maintaining PCI DSS

controls– The risk to an organization (reduced by consolidating cardholder

data into fewer, more controlled locations)

028


PCI Mandates Risk Assessment

Source: https://www.pcisecuritystandards.org/organization_info/index.php

029

• PCI 2.0 Requirement 12.1.2 mandates the use of formal risk assessment based on established methodologies

• 12.1.2 Includes an annual process that identifies threats, and

vulnerabilities, and results in a formal risk assessment

– 12.1.2.a Verify that an annual risk assessment process is documented that identifies threats, vulnerabilities, and results in a formal risk assessment

– 12.1.2.b Review risk assessment documentation to verify that the risk assessment process is performed at least annually

• Examples of risk assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30


Data Security Methods

030


Advancements in Cryptography

Year Event2010 In-memory Data Tokenization introduced as a fully distributed model

2005

Centralized Data Tokenization introduced with hosted payment service

DTP (Data Type Preserving encryption) used in commercial databases

Attack on SHA-1 announced DES was withdrawn

2001 AES (Advance Encryption Standard) accepted as a FIPS-approved algorithm

1991 PGP (Pretty Good Privacy) was written 1988 IBM AS/400 used tokenization in shadow files1978 RSA algorithm was published 1975 DES (Data Encryption Standard) draft submitted by IBM

1900 BC Cryptography used in Egypt

031


123456 777777 1234

123456 123456 1234

aVdSaH 1F4hJ 1D3a

!@#$%a^///&*B()..,,,gft_+!@4#$2%p^&*Hashing -

Strong Encryption -

Alpha -

Numeric -

Partial -

Clear Text Data -

Intrusiveness (to Applications and Databases)

I

Original

!@#$%a^.,mhu7/////&*B()_+!@

666666 777777 8888Tokenizing or

FormattedEncryption

Data

Length

Sta

ndar

dE

ncry

ptio

n

Intrusiveness of Data FormatsE

ncod

ing

032


Encryption vs. Tokenization

Used Approach Cipher System Code System

Cryptographic algorithms

Cryptographic keys

Code books

Index tokens

Source: McGraw-HILL ENCYPLOPEDIA OF SCIENCE & TECHNOLOGY

TokenizationEncryption

033


Use of Enabling Technologies

47%

35%

39%

28%

29%

23%

16%

10%

7%

7%

13%22%

7%

28%

21%

30%

18%

1% 91% 5%

4%

Access controls

Database activity monitoring

Database encryption

Backup / Archive encryption

Data masking

Application-level encryption

Tokenization

Evaluating Current Use Planned Use <12 Months

034


Use of Enabling Technologies, by Maturity

035


Application Database

Hiding Data in Plain Sight

400000 123456 7899

400000 222222 7899

Y&SFD%))S( Tokenization Server

Data Token

Data Entry

036


Applications & Databases

: Data Token

Reducing the Attack Surface

Protected sensitive information

Unprotected sensitive information:

123456 999999 1234 123456 999999 1234 123456 999999 1234

123456 123456 1234123456 999999 1234123456 123456 1234 123456 999999 1234 123456 999999 1234

037


Fully Distributed Tokenization

Customer Application

TokenServer



Token Server


TokenServer

• How do you deliver tokenization to many locations without the impact of latency?

038


• Multi-Use Tokens• Random Static Lookup Tables

– Remains the same size no matter the number of unique tokens

• Example: 50 million = 2 million tokens

• Performance: 200,000 tokens per second on a commodity standard dual core machine

Application

Application

Application

288910288910288910288910288910

1,000,000 max entries

288910288910288910288910288910

1,000,000 max entries

Application

Random Static Lookup Tables

A Fully Distributed Approach

039


Best Worst

Area ImpactDatabase

File Encryption

DatabaseColumn

Encryption

OldToken

Approach

MemoryToken

Approach

Scalability

Availability

Latency

CPU Consumption

Security

Data Flow Protection

Compliance Scoping

Key Management

Separation of Duties

Evaluating Encryption & Tokenization

040


Evaluation Criteria Strong Field Encryption

Formatted Encryption

Memory TokenApproach

Disconnected environments

Distributed environments

Performance impact when loading data

Transparent to applications

Expanded storage size

Transparent to databases schema

Long life-cycle data

Unix or Windows mixed with “big iron”

Easy re-keying of data in a data flow

High risk data

Security - compliance to PCI, NIST

Best Worst

Evaluating Encryption & Tokenization

041


Best Practices for Tokenization

Token Generation Token Types

Single Use Token

Multi Use Token

Algorithm and Key Reversible

Known strong algorithm

One way Irreversible Function

Unique Sequence Number

Hash

Randomly generated value

-

Secret per transaction

Secret per merchant

Published July 14, 2010.

042


• Visa recommendations should be simply to use a random number

• The only way to discover PAN data from a real token is a (reverse) lookup in the token server database

• The odds are that if you are saddled with PCI-DSS responsibilities, you will not write your own 'home-grown' token servers

Comments on Best Practices

043


What Makes a “Secure Tokenization” Algorithm?

• Ask vendors what their token-generating algorithms are

• Be sure to analyze anything other than strong random number generators for security.

Secure Tokenization

044


Aggregating Hub for Store

Channel

Loss Prevention

Settlement

Analysis - EDWSettlement ERP

StoresStoresAuthorization

Token Servers

A Retail Scenario

Token Servers

: Integration point

045


Case Study – Simplify Compliance

Case Study - Large Chain Store Uses Tokenization to Simplify PCI Compliance

• By segmenting cardholder data with tokenization, a regional chain of 1,500 local convenience stores is reducing its PCI audit from seven to three months

• “ We planned on 30 days to tokenize our 30 million card numbers. With Protegrity Tokenization, the whole process took about 90 minutes”

046


• Qualified Security Assessors had no issues with the effective segmentation provided by Tokenization

• “With encryption, implementations can spawn dozens of questions”

• “There were no such challenges with tokenization”

047



• Faster PCI audit – half that time• Lower maintenance cost – don’t have to apply all 12

requirements of PCI DSS to every system• Better security – able to eliminate several business

processes such as generating daily reports for data requests and access

• Strong performance – rapid processing rate for initial tokenization, sub-second transaction SLA

048



Why Tokenization?

Why Tokenization – A Triple Play1. No Masking2. No Encryption3. No Key Management

Why In-memory Tokenization1. Better 2. Faster 3. Lower Cost / TCO

$

049


Risk Management

050


AccessLevel

Risk

Data Tokens

TraditionalAccessControl

IHigh

ILow

High –

Low -

Old and flawed:Minimal access levels so people can only carry out their jobs

New:CreativityHappens

At the edge

Source: InformationWeek Aug 15, 2011

Data Security - Catch-22

051


SystemType

Risk

Data Tokens

Data display Masking

IProduction

ITest / dev

Data Masking vs. Tokenization - Risk

High –

Low -

Data at rest Masking

IIntegration

testing

ITroubletesting

Exposure:Data in clear

before masking

Exposure:Data is only obfuscated

052


RiskLevel

Cost

OptimalRisk

Expected Losses from the Risk

Cost of Aversion – Protection of Data

Total Cost

IPassive

Protection

IActive

Protection

Choose Your Defenses

053


Source: 2009 PCI DSS Compliance Survey, Ponemon Institute

Cost Effective PCI DSS

ID & credentialing system

Database scanning and monitoring (DAM)

Intrusion detection or prevention systems

Data loss prevention systems (DLP)

Endpoint encryption solution

Web application firewalls (WAF)

Correlation or event management systems

Identity & access management systems

Access governance systems

Encryption for data in motion

Anti-virus & anti-malware solution

Encryption/Tokenization for data at rest

Firewalls

0 10 20 30 40 50 60 70 80 90

WAF

DLP

DAM

%Encryption/Tokenization

054


Matching Data Protection with Risk Level

Risk Level Solution

Monitor

Monitor, mask, access control limits, format control encryption

Replacement, strong encryption

Low Risk (1-5)

At Risk (6-15)

High Risk (16-25)

Data Field

Risk Level

Credit Card Number 25Social Security Number 20

CVV 20Customer Name 12Secret Formula 10

Employee Name 9Employee Health Record 6

Zip Code 3

055


10 000 000 -

1 000 000 -

100 000 -

10 000 -

1 000 -

100 -

Transactions per second (16 digits)

I

Format

Preserving

Encryption

Speed of Different Methods

I

Data

Type

Preservation

I

Memory

Data

Tokenization

I

AES CBC

Encryption

Standard

I

Traditional

Data

Tokenization

Encryption

*: Speed will depend on the configuration056


I

Format

Preserving

Encryption

Security Level of Different Methods

I

Data

Type

Preservation

I

Memory

Data

Tokenization

I

AES CBC

Encryption

Standard

I

Traditional

Data

Tokenization

High -

Low -

Security Level

Encryption

057


10 000 000 -

1 000 000 -

100 000 -

10 000 -

1 000 -

100 -

Transactions per second (16 digits)

I

Format

Preserving

Encryption

Speed and Security

I

Data

Type

Preservation

I

Memory

Data

Tokenization

I

AES CBC

Encryption

Standard

I

Traditional

Data

Tokenization

Speed*

Security

- High

- Low

Security

Level

Encryption

*: Speed will depend on the configuration058


Quality of Information (Granularity)

Applications and Data - PCI vs. PII

I

Many

I

Few

PCI

PII

High -

Low - # of

Apps

059

Performanceneed

400000 123456 7899

111111 222222 7899

123- 12-1234

777-77-8888

400000 222222 7899

777-77-1234


Data Security Method

System Layer

Hashing Formatted Encryption

Strong Encryption

DataTokenization

Application

Database Column

Database File

Storage Device

Best Worst

Risk Management Aspects

060

• Different data security methods and algorithms• Enforcement implemented at different system layers


Data Security Method

System Layer

Hashing Formatted Encryption

Strong Encryption

DataTokenization

Application

Database Column

Database File

Storage Device

Best Worst: N/A

061

Risk Management Aspects

• Different methods integrated at different system layers


Cloud Security

062


Risks with Cloud Computing

Dource: The evolving role of IT managers and CIOs Findings from the 2010 IBM Global IT Risk Study

Inability to customize applications

Financial strength of the cloud computing provider

Uptime/business continuity

Weakening of corporate network security

Threat of data breach or loss

Handing over sensitive data to a third party

0 10 20 30 40 50 60 70 %

063


What Amazon’s PCI Compliance Means

• PCI-DSS 2.0 doesn't address multi-tenancy concerns

• You can store PAN data on S3, but it still needs to be encrypted in accordance with PCI-DSS requirements

• Amazon doesn't do this for you -- it's something you need to implement yourself; including key management, rotation, logging, etc.

• If you deploy a server instance in EC2 it still needs to be assessed by your QSA

• What this certification really does is eliminate any doubts that you are allowed to deploy an in-scope PCI system on AWS

• This is a big deal, but your organization's assessment scope isn't necessarily reduced

• It might be when you move to something like a tokenization service where you reduce your handling of PAN data

Source: securosis.com064


Summary

065


Data Protection Challenges

Actual protection is not the challenge Management of solutions

Key management Security policy Auditing, Monitoring and reporting

Minimizing impact on business operations Transparency Performance vs. security

Minimizing the cost implications

Maintaining compliance

Implementation Time

066


Best Practices - Data Security

Database Protector

File System Protector

Policy

AuditLog

Secure Archive

Application Protector

Tokenization Server

EnterpriseData SecurityAdministrator

: Enforcement point

067


Risk Management Practices for PCI DSS 2.0

Ulf Mattsson

CTO Protegrity

ulf.mattsson [at] protegrity.com

Technology

Risk Management Practices for PCI DSS 2.0