PCI DSS Conference in London UK 2011

40
Demystifying Tokenization’s Role in Payment Card Security Ulf Mattsson CTO Protegrity ulf . mattsson [at] protegrity . com

description

 

Transcript of PCI DSS Conference in London UK 2011

Page 1: PCI DSS Conference in London UK 2011

Demystifying Tokenization’s Role in Payment Card Security

Ulf MattssonCTO Protegrity

ulf . mattsson [at] protegrity . com

Page 2: PCI DSS Conference in London UK 2011

Ulf Mattsson

20 years with IBM Development & Global Services

Inventor of 22 patents – Encryption and Tokenization

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

• Cloud Security Alliance (CSA)

• Information Systems Security Association (ISSA)

• Information Systems Audit and Control Association (ISACA)

2

Page 3: PCI DSS Conference in London UK 2011
Page 4: PCI DSS Conference in London UK 2011

About Protegrity

Proven enterprise data security software and innovation leader • Sole focus on the protection of data

• Patented Technology, Continuing to Drive Innovation

Growth driven by compliance and risk management• PCI (Payment Card Industry)

• PII (Personally Identifiable Information)

• PHI (Protected Health Information) – HIPAA

• State and Foreign Privacy Laws, Breach Notification Laws

• High Cost of Information Breach ($4.8m average cost), immeasurable costs of brand damage , loss of customers

• Requirements to eliminate the threat of data breach and non-compliance

Cross-industry applicability• Retail, Hospitality, Travel and Transportation• Financial Services, Insurance, Banking• Healthcare• Telecommunications, Media and Entertainment• Manufacturing and Government

4

Page 5: PCI DSS Conference in London UK 2011

05

Beyond PCI

We are launching in London today, our website www. Icspa.org will be live by

1430 BST

Page 6: PCI DSS Conference in London UK 2011

AttackerPublicNetwork

OS File System

Database

Storage System

Application

SS

LPrivate Network

Encrypt Data

At Rest(PCI DSS)

Clear Text Data

EncryptData onPublic

Networks(PCI DSS)

Clear Text Data

PCI DSS is Evolving

Source: PCI Security Standards Council, 20116

Page 7: PCI DSS Conference in London UK 2011

Protecting the Data Flow – PCI/PII Example

Protected sensitive information

Unprotected sensitive information:

: Enforcement point

7

Page 8: PCI DSS Conference in London UK 2011

PCI DSS - Ways to Render the PAN* Unreadable

Two-way cryptography with associated key management processes

One-way cryptographic hash functions

Index tokens and pads

Truncation (or masking – xxxxxx xxxxxx 6781)

* PAN: Primary Account Number (Credit Card Number)

08

Page 9: PCI DSS Conference in London UK 2011

Use of Enabling Technologies

9

Page 10: PCI DSS Conference in London UK 2011

Current, Planned 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

10

Page 11: PCI DSS Conference in London UK 2011

What is the difference between Encryption and Tokenization?

11

Page 12: PCI DSS Conference in London UK 2011

What is Encryption and Tokenization?

Used Approach Cipher System Code System

Cryptographic algorithms

Cryptographic keys

Code books

Index tokens

Source: McGraw-HILL ENCYPLOPEDIA OF SCIENCE & TECHNOLOGY

TokenizationEncryption

12

Page 13: PCI DSS Conference in London UK 2011

What is Tokenization and what is the Benefit?

Tokenization• Tokenization is process that replaces sensitive data in

systems with inert data called tokens which have no value to the thief.

• Tokens resemble the original data in data type and length

Benefit• Greatly improved transparency to systems and

processes that need to be protected

Result• Reduced remediation

• Reduced need for key management

• Reduce the points of attacks

• Reduce the PCI DSS audit costs for retail scenarios

13

Page 14: PCI DSS Conference in London UK 2011

Applications & Databases

: Data Token

Data Tokenization – Reducing the Attack Surface

Protected sensitive information

Unprotected sensitive information:

123456 999999 1234 123456 999999 1234 123456 999999 1234

123456 123456 1234

123456 999999 1234

123456 123456 1234

123456 999999 1234 123456 999999 1234

14

Page 15: PCI DSS Conference in London UK 2011

015

PCI Use Cases

Page 16: PCI DSS Conference in London UK 2011

Some Tokenization Use Cases

Customer 1• Vendor lock-in: What if we want to switch payment processor?

• Performance challenge: What if we want to rotate the tokens?

• Performance challenge with initial tokenization

Customer 2• Reduced PCI compliance cost by 50%

• Performance challenge with initial tokenization

• End-to-end: looking to expand tokenization to all stores

Customer 3• Desired a single vendor

• Desired use of encryption and tokenization

• Looking to expand tokens beyond CCN to PII

Customer 4• Remove compensating controls on the mainframe

• Pushing tokens through to avoid compensating controls

16

Page 17: PCI DSS Conference in London UK 2011

Tokenization Use Case #2

A leading retail chain• 1500 locations in the U.S. market

Simplify PCI Compliance• 98% of Use Cases out of audit scope

• Ease of install (had 18 PCI initiatives at one time)

Tokenization solution was implemented in 2 weeks • Reduced PCI Audit from 7 months to 3 months

• No 3rd Party code modifications

• Proved to be the best performance option

• 700,000 transactions per days

• 50 million card holder data records

• Conversion took 90 minutes (plan was 30 days)

• Next step – tokenization servers at 1500 locations

17

Page 18: PCI DSS Conference in London UK 2011

Token Flexibility for Different Categories of Data

Type of Data Input Token Comment

Token Properties

Credit Card 3872 3789 1620 3675 8278 2789 2990 2789 Numeric

Medical ID 29M2009ID 497HF390D Alpha-Numeric

Date 10/30/1955 12/25/2034 Date

E-mail Address [email protected] [email protected] Alpha Numeric, delimiters in input preserved

SSN delimiters 075-67-2278 287-38-2567 Numeric, delimiters in input

Credit Card 3872 3789 1620 3675 8278 2789 2990 3675 Numeric, Last 4 digits exposed

Policy Masking

Credit Card 3872 3789 1620 3675 clear, encrypted, tokenized at rest3872 37## #### ####

Presentation Mask: Expose 1st 6 digits

18

Page 19: PCI DSS Conference in London UK 2011

Positioning of Different Protection Options

19

Page 20: PCI DSS Conference in London UK 2011

Positioning of Different Protection Options

Evaluation Criteria Strong Encryption

Formatted Encryption

Data Tokens

Security & Compliance

Total Cost of Ownership

Use of Encoded Data

Best Worst

20

Page 21: PCI DSS Conference in London UK 2011

123456 777777 1234

123456 123456 1234

aVdSaH 1F4hJ 1D3a

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

Strong Encryption -

Alpha Encoding -

Numeric Encoding -

Partial Encoding -

Clear Text Data -

Intrusiveness to Applications and Databases

I

Original

I

Longer

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

666666 777777 8888Tokenizing /FormattedEncryption

021

Data

Length

StandardEncryption

Comparing Field Encryption & Tokenization

Page 22: PCI DSS Conference in London UK 2011

Speed and Security Of Different

Data Protection Methods

22

Page 23: PCI DSS Conference in London UK 2011

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 Protection Methods

I

Data

Type

Preservation

I

Memory

Data

Tokenization

I

AES CBC

Encryption

Standard

I

Traditional

Data

Tokenization

Encryption

23 *: Speed will depend on the configuration

Page 24: PCI DSS Conference in London UK 2011

I

Format

Preserving

Encryption

Security of Different Protection Methods

I

Data

Type

Preservation

I

Memory

Data

Tokenization

I

AES CBC

Encryption

Standard

I

Traditional

Data

Tokenization

High -

Low -

Security Level

Encryption

24

Page 25: PCI DSS Conference in London UK 2011

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 of Different Protection Methods

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 configuration25

Page 26: PCI DSS Conference in London UK 2011

Different Approaches for Tokenization

Traditional Tokenization• Dynamic Model or Pre-Generated Model

• 5 tokens per second - 5000 tokenizations per second

Next Generation Tokenization• Memory-tokenization

• 200,000 - 9,000,000+ tokenizations per second

• “The tokenization scheme offers excellent security, since it is based on fully randomized tables.” *

• “This is a fully distributed tokenization approach with no need for synchronization and there is no risk for collisions.“ *

*: Prof. Dr. Ir. Bart Preneel, Katholieke University Leuven, Belgium

026

Page 27: PCI DSS Conference in London UK 2011

Evaluating Encryption &

Data Tokenization

27

Page 28: PCI DSS Conference in London UK 2011

Best Worst

Area ImpactDatabase

File Encryption

DatabaseColumn

Encryption

CentralizedTokenization

(old)

MemoryTokenization

(new)

Scalability

Availability

Latency

CPU Consumption

Security

Data Flow Protection

Compliance Scoping

Key Management

Randomness

Separation of Duties

Evaluating Encryption & Tokenization ApproachesEncryptionEvaluation Criteria Tokenization

028

Page 29: PCI DSS Conference in London UK 2011

Evaluation Criteria Strong Field Encryption

Formatted Encryption

Memory Tokenization

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” (EBCDIC)

Easy re-keying of data in a data flow

High risk data

Security - compliance to PCI, NIST

Best Worst

Evaluating Field Encryption & Distributed Tokenization

29

Page 30: PCI DSS Conference in London UK 2011

Tokenization SummaryTraditional Tokenization Memory Tokenization

Footprint Large, Expanding. The large and expanding footprint of Traditional Tokenization is it’s Achilles heal. It is the source of poor performance, scalability, and limitations on its expanded use.

Small, Static. The small static footprint is the enabling factor that delivers extreme performance, scalability, and expanded use.

High Availability, DR, and Distribution

Complex replication required. Deploying more than one token server for the purpose of high availability or scalability will require complex and expensive replication or synchronization between the servers.

No replication required. Any number of token servers can be deployed without the need for replication or synchronization between the servers. This delivers a simple, elegant, yet powerful solution.

Reliability Prone to collisions.The synchronization and replication required to support many deployed token servers is prone to collisions, a characteristic that severely limits the usability of traditional tokenization.

No collisions.Protegrity Tokenizations’ lack of need for replication or synchronization eliminates the potential for collisions .

Performance, Latency, and Scalability

Will adversely impact performance & scalability.The large footprint severely limits the ability to place the token server close to the data. The distance between the data and the token server creates latency that adversely effects performance and scalability to the extent that some use cases are not possible.

Little or no latency. Fastest industry tokenization.The small footprint enables the token server to be placed close to the data to reduce latency. When placed in-memory, it eliminates latency and delivers the fastest tokenization in the industry.

Extendibility Practically impossible. Based on all the issues inherent in Traditional Tokenization of a single data category, tokenizing more data categories may be impractical.

Unlimited Tokenization Capability.Protegrity Tokenization can be used to tokenize many data categories with minimal or no impact on footprint or performance.

30

Page 31: PCI DSS Conference in London UK 2011

Protegrity Tokenization: Scaling and High AvailabilityApplication

Application

Load Balance

Application

Scalability and High Availability typically requires redundancy

Protegrity Tokenization

• Small Footprint

• No replication required

• No chance of collisions

31

Token Tables

Token Server Token Server Token Server Token Server

Token Tables

Token Tables

Token Tables

Page 32: PCI DSS Conference in London UK 2011

Build vs. Buy Decision

032

Page 33: PCI DSS Conference in London UK 2011

Visa recommendations should be simply to use a random number

• If the output is not generated by a mathematical function applied to the input, it cannot be reversed to regenerate the original PAN data

• 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

Tokenization Best Practices

033

Page 34: PCI DSS Conference in London UK 2011

Build vs. Buy Decision - Business Considerations

Is the additional risk of developing a custom system acceptable?

Is there enough money to analyze, design, and develop a custom system?

Does the source code have to be owned or controlled?

Does the system have to be installed as quickly as possible?

Is there a qualified internal team available to• Analyze, design, and develop a custom system?

• Provide support and maintenance for a custom developed system?

• Provide training on a custom developed system?

• Produce documentation for a custom developed system?

Would it be acceptable to change current procedures and processes to fit with the packaged software?

034

Page 35: PCI DSS Conference in London UK 2011

Data Protection Challenges

35

Page 36: PCI DSS Conference in London UK 2011

The actual protection of the data is not the challenge

Centralized solutions are needed to managed complex security requirements

• Based on Security Policies with Transparent Key management

• Many methods to secure the data• Auditing, Monitoring and Reporting

Solutions that minimize the impact on business operations

• Highest level of performance and transparency

Rapid Deployment

Affordable with low TCO

Enable & Maintaining compliance

Data Protection Challenges

36

Page 37: PCI DSS Conference in London UK 2011

Protegrity Data Security Management

Database Protector

File System Protector

Policy

AuditLog

Secure Archive

Application Protector

Tokenization Server

EnterpriseData SecurityAdministrator

: Encryption service37

Page 38: PCI DSS Conference in London UK 2011

Enterprise Deployment Coverage

Enterprise Security Administrator (ESA)• Deployed as Soft Appliance

• Hardened, High Availability, Backup & Restore, Scalable

Data Protection System (DPS)• Data Protectors with Heterogeneous Coverage

• Operating System: AIX, HPUX, Linux, Solaris, Windows• Database: DB2, SQL Server, Oracle, Teradata, Informix• Platforms: iSeries, zSeries

38

Page 39: PCI DSS Conference in London UK 2011

Protegrity and PCIBuild and maintain a secure network.

1. Install and maintain a firewall configuration to protect data

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

Protect cardholder data. 3. Protect stored data4. Encrypt transmission of cardholder data and

sensitive information across public networks

Maintain a vulnerability management program.

5. Use and regularly update anti-virus software6. Develop and maintain secure systems and

applications

Implement strong access control measures.

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

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

9. Restrict physical access to cardholder data

Regularly monitor and test networks.

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

39

Page 40: PCI DSS Conference in London UK 2011

Contact information:

Ulf Mattsson, +1-203-570-6919, [email protected]

Protegrity EuropeDDI: +44 (0)1494 857762