Enterprise Data Protection -Understanding your Options

and Strategiesand Strategies

Ulf Mattsson, CTO, Protegrity

Ulf Mattsson

20 years with IBM Research, Development & Services

Inventor of 21 patents – Distributed Tokenization, Encryption Key

Management, Policy Driven Data Encryption, Internal Threat Protection,

Data Usage Control and Intrusion Prevention

Research member of the International Federation for Information

Processing (IFIP) WG 11.3 Data and Application Security

Received Industry's 2008 Most Valuable Performers (MVP) award

together with technology leaders from IBM, Google, Cisco, Ingres and

other leading companies

2

other leading companies

Received US Green Card ‘EB 11 – Individual of Extraordinary Ability’

endorsed by IBM Research

Created the Architecture of the Protegrity Database Security Technology

Member of

• American National Standards Institute (ANSI) X9

• Institute of Electrical and Electronics Engineers (IEEE)

• Information Systems Security Association (ISSA)

• Information Systems Audit and Control Association (ISACA)

This session will review

Current/evolving data security risks

Different options for data protection strategies for PCI DSS and

other regulations

• Solutions for protecting enterprise data against advanced attacks from

internal and external sources

• How to provide a balanced mix of different approaches to protect sensitive

information like credit cards across different systems in the enterprise,

including tokenization, encryption and hashing

4

including tokenization, encryption and hashing

Studies on data protection in an enterprise environment

• Recommendations for how to balance performance and security, in real-

world scenarios, and when to use encryption at the database level,

application level and file level

http://www.pciknowledgebase.com/

The Gartner 2010 CyberThreat Landscape

5

Understand Your Enemy & Data Attacks

Breaches attributed to insiders are much larger than those caused by

outsiders

The type of asset compromised most frequently is online data, not

laptops or backups:

6

Source: Verizon Business Data Breach Investigations Report (2008 and 2009)

Top 15 Threat Action Types

7

Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team

Targeted Threat Growth

8

9

Data Entry

Database

Application Authorized/

Un-authorized

Users

Database

ATTACKERS

Data System

Choose Your Defenses

MALWARE / TROJAN

SQL INJECTION

SNIFFER ATTACK

RECENT ATTACKS

Where is data exposed to attacks?

111 - 77 - 1013

990 - 23 - 1013

10

File System

Storage

(Disk)

Database

Admin

System Admin

HW Service People

Contractors

6

Backup

(Tape)

DATABASE ATTACK

FILE ATTACK

MEDIA ATTACK

6

111 - 77 - 1013

Protected sensitive information

Unprotected sensitive information:

Dataset Comparison – Data Type

11

Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team

Application Databases

Data Defenses – New Methods

Key Manager

Format Controlling Encryption

Example of Encrypted format:

111-22-1013

12

Token Server

Token

Data Tokenization

Example of Token format:

1234 1234 1234 4560

Application

Databases

Key Manager

What Is Format Controlling Encryption (FCE)?

Where did it come from?

• Before 2000 – Different approaches, some are based on

block ciphers (AES, 3DES H)

• Before 2005 – Used to protect data in transit within

enterprises

What exactly is it?

13

• Secret key encryption algorithm operating in a new mode

• Cipher text output can be restricted to same as input code

page – some only supports numeric data

• The new modes are not approved by NIST

FCE Considerations

Unproven level of security – makes significant alterations to

the standard AES algorithm

Encryption overhead – significant CPU consumption is

required to execute the cipher

Key management – is not able to attach a key ID, making key

rotation more complex - SSN

14

Some implementations only support certain data (based on

data size, type, etc.)

Support for “big iron” systems – is not portable across

encodings (ASCII, EBCDIC)

Transparency – some applications need full clear text

What Is Data Tokenization?

Where did it come from?

• Found in Vatican archives dating from the 1300s

• In 1988 IBM introduced the Application System/400 with

shadow files to preserve data length

• In 2005 vendors introduced tokenization of account numbers

What exactly is it?

15

What exactly is it?

• It IS NOT an encryption algorithm or logarithm.

• It generates a random replacement value which can be used to

retrieve the actual data later (via a lookup)

• Still requires strong encryption to protect the lookup table(s)

Old Technology - A Centralized Token Solution

Token

Server

Customer

Application

16

Customer

Application

Customer

Application

• ‘Information in the wild’- Short lifecycle / High risk

• Temporary information - Short lifecycle / High risk

• Operating information- Typically 1 or more year lifecycle

-Broad and diverse computing and

Point of Sale

E-Commerce

Branch Office

Choose Your Defenses – Data Flow Example

Encryption

Aggregation

Operations

Collection

17

-Broad and diverse computing and

database environment

• Decision making information- Typically multi-year lifecycle

- Homogeneous environment

- High volume database analysis

• Archive-Typically multi-year lifecycle

-Preserving the ability to retrieve the

data in the future is important

Central

Data Token

Operations

Analysis

Archive

Central Tokenization Considerations

Transparency – not transparent to downstream systems that

require the original data

Performance & availability – imposes significant overhead

from the initial tokenization operation and from subsequent

lookups

Performance & availability – imposes significant overhead if

token server is remote or outsourced

18

Security vulnerabilities of the tokens themselves –

randomness and possibility of collisions

Security vulnerabilities typical in in-house developed systems

– exposing patterns and attack surfaces

An Enterprise View of Different Protection Options

Evaluation Criteria Strong

Encryption

Formatted

Encryption

Old Central

Tokenization

Disconnected environments

Distributed environments

Performance impact when loading data

Transparent to applications

Expanded storage size

19

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

Token

Server

Customer

Application

Old Technology - A Centralized Token Solution

20

Customer

Application

Customer

Application

New Technology - Distributed Tokenization

Customer

Application

Token

Server

Customer

Application

21

Customer

Application

Token

Server

Customer

Application

Token

Server

A Central Token Solution vs. A Distributed Token Solution

Dynamic

Random

Token Table

-

-

-

-

-

.

Distributed

Static

Token Tables

Static

Random

Token

Table

Static

Random

Token

TableDistributed

Static

Token Tables

Static

Random

Token

Table

Static

Random

Token

TableCustomer

Application

Customer

Application

Customer

Application

Customer

Application

Central Dynamic

Token Table

Customer

Application

Customer

Application

.

.

.

.

.

.

.

.

.

Token TablesApplication

Distributed

Static

Token Tables

Static

Random

Token

Table

Static

Random

Token

TableDistributed

Static

Token Tables

Static

Random

Token

Table

Static

Random

Token

TableCustomer

Application

Customer

Application

Evaluating Different Tokenization Implementations

Evaluating Different Tokenization ImplementationsEvaluation Area Hosted/Outsourced On-site/On-premises

Area Criteria Central (old) Distributed Central (old) Distributed Integrated

Operati

onal

Needs

Availability

Scalability

Performance

Pricing

Per Server

23

Best Worst

Pricing

Model Per Transaction

Data

Types

Identifiable - PII

Cardholder - PCI

Security

Separation

Compliance

Scope

Protecting the Data Flow - Choose Your Defenses

24

Database Protection

Approach

Performance Storage Availability Transparency Security

Monitoring, Blocking,

Masking

Column Level Formatted

Encryption

Column Level Strong

Encryption

Column Level Replacement;

Choose Your Defenses - Operational Impact

25

Column Level Replacement;

Scalable Distributed Tokens

Column Level Replacement;

Central Tokens

Tablespace - Datafile

Protection

Best Worst

Database

Admin,

Users

Compliance to Legislation - Technical Safeguards

•Separation of Duties

•Access Control

•Data Integrity

•Audit & Reporting

•Data Transmission

PHI, PII, PAN

Data

Policy

HIPAA, HITECH,

State Laws, PCI DSS

26

•Data Transmission

Business Associates,

Covered Entities

Examples of PII/PHI breaches: Express Scripts extortion attempt, Certegy breach and the Countrywide breach

Not Compliant

User Access Patient Health Record

x Read a xxx

DBA Read b xxx

z Write c xxx

Compliant

Compliance – How to be Able to Produce Required Reports

Database

DatabaseUser Access Patient Health Record

PatientHealth

Record

a xxx

b xxx

c xxx

Performance?

3rd Party

Possible DBA

manipulation

Protected

Log

Application/ToolUser X (or DBA)

27

OS File

DatabaseProcess 001

User Access Patient Health Record

z Write c xxx

User Access PatientHealth Data

Record

Health

Data File

Database Process 0001

Read ? ? PHI002

Database Process 0001

Read ? ? PHI002

Database Process 0001

Write ? ? PHI002

Health DataFile PHI002

DB Native

3rd Party

Not Compliant

No Read

Log

No

Information

On User

or Record

Data Protection Challenges

Actual protection is not the challenge

Management of solutions• Key management

• Security policy

• Auditing and reporting

Minimizing impact on business operations• Transparency

28

• Transparency

• Performance vs. security

Minimizing the cost implications

Maintaining compliance

Implementation Time

Protegrity – A Centralized Data Security Approach

Database

Protector

File System

Protector PolicyPolicy & Key

Creation

Secure

Storage

Secure

Distribution

Secure

Usage

Audit

Log

PolicyPolicy

Secure

Archive

Enterprise

Data Security

29

Auditing &

Reporting

Secure

Collection

Data Security

Administrator

Application

Protector

Big Iron

Protector

Protegrity delivers, application, database, file protectors across all

major enterprise platforms.

Protegrity’s Risk Adjusted Data Security Platform continuously

secures data throughout its lifecycle.

Underlying foundation for the platform includes comprehensive

data security policy, key management, and audit reporting.

Protegrity Value Proposition

30

data security policy, key management, and audit reporting.

Enables customers to achieve data security compliance (PCI, HIPAA, PEPIDA, SOX and Federal & State Privacy Laws)

Protegrity and PCI DSS

Build 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 data

4. Encrypt transmission of cardholder data and

sensitive information across public networks

Maintain a vulnerability

management program.

5. Use and regularly update anti-virus software

6. Develop and maintain secure systems and

31

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

Please contact us for more information

32

Ulf Mattsson

ulf.mattsson@protegrity.com

Rose Riegerrose.rieger@protegrity.com

Iain Kerr,

President and CEO

203 326 7200