isaca houston texas chapter 2010

Myths & Realities of Data Security & ComplianceCompliance

Ulf Mattsson, CTO, Protegrity

Ulf Mattsson

20 years with IBM Development, Manufacturing & Services

Inventor of 21 patents - Encryption Key Management, Policy Driven Data

Encryption, Internal Threat Protection, Data Usage Control and Intrusion

Prevention.

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

together with technology leaders from IBM, Cisco Systems., Ingres,

Google and other leading companies.

Co-founder of Protegrity (Data Security Management)

Received US Green Card of class ‘EB 11 – Individual of Extraordinary

Ability’ after endorsement by IBM Research in 2004.

Research member of the International Federation for Information

Processing (IFIP) WG 11.3 Data and Application Security

Member of

• American National Standards Institute (ANSI) X9

• Information Systems Audit and Control Association (ISACA)

• Information Systems Security Association (ISSA)

• Institute of Electrical and Electronics Engineers (IEEE)

ISACA Articles (NYM)

The Gartner 2010 CyberThreat Landscape

Data Security Remains Important for Most

Source: Forrester, 2009

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:

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

Top 15 Threat Action Types

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

Targeted Threat Growth

Errors and Omissions

Higher

Probability

Lost Backups, In Transit

Application User

(e.g. SQL Injection)

SQL Users

RECENT

ATTACKS

Understand Your Enemy – Probability of Attacks

What is the Probability of Different Attacks on Data?

Application Developer,

Valid User for Data

Higher Complexity

Network or Application/RAM Sniffer

Valid User for the Server

(e.g. Stack Overflow, data sets)

Administrator

Source: IBM Silicon Valley Lab(2009)

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

File System

Storage

(Disk)

Database

Admin

System Admin

HW Service People

Contractors

<

Backup

(Tape)

DATABASE ATTACK

FILE ATTACK

MEDIA ATTACK

<

111 - 77 - 1013

Protected sensitive information

Unprotected sensitive information:

Protecting the Data Flow - Example

Choose Your Defenses – Different Approaches

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)

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

Application Databases

Choose Your Defenses – New Methods

Key Manager

Format Controlling Encryption

Example of Encrypted format:

111-22-1013

Token Server

Token

Data Tokenization

Example of Token format:

1234 1234 1234 4560

Application

Databases

Key Manager

A Distributed and Scalable Tokenization Approach

Customer

Application

Token

Server

Customer

Application

Customer

Application

Token

Server

Customer

Application

Token

Server

Matching Data Protection Solutions with Risk Level

Risk Level Solution

Monitor

Monitor, mask,

Low Risk

(1-5)

Data

Field

Risk

Level

Credit Card Number 25

Social Security Number 20

CVV 20

Deploy Defenses

Monitor, mask,

access control

limits, format

control encryption

Replacement,

strong

encryption

At Risk

(6-15)

High Risk

(16-25)

CVV 20

Customer Name 12

Secret Formula 10

Employee Name 9

Employee Health Record 6

Zip Code 3

Cost

Optimal

Expected Losses

from the RiskCost of Aversion –

Protection of Data

Total Cost

Choose Your Defenses – Find the Balance

Risk

Level

Optimal

Risk

I

Passive

Protection

I

Active

Protection

Practical Examples of using a Risk Based Approach to Data SecurityApproach to Data Security

Ulf Mattsson, CTO, Protegrity

Developing a Risk-adjusted Data Protection Plan

Know Your Data

Find Your Data

Understand Your Enemy

Understand the New Options in Data Protection

Deploy DefensesDeploy Defenses

Crunch the Numbers

Know Your Data – Identify High Risk Data

Begin by determining the risk profile of all relevant data

collected and stored

• Data that is resalable for a profit

• Value of the information to your organization

• Anticipated cost of its exposure

Data Field Risk Level

Credit Card Number 25

Social Security Number 20

CVV 20

Customer Name 12

Secret Formula 10

Employee Name 9

Employee Health Record 6

Zip Code 3

Choose Your Defenses – Different Approaches

Choose Your Defenses – Cost Effective PCI

Encryption 74%

WAF 55%

DLP 43%

Source: 2009 PCI DSS Compliance Survey, Ponemon Institute

DLP 43%

DAM 18%

Evaluation Criteria

Performance

• Impact on operations - end users, data processing

windows

Storage

• Impact on data storage requirements

Security & Separation of DutiesSecurity & Separation of Duties

• How secure Is the data at rest

• Impact on data access – separation of duties

Transparency

• Changes to application(s)

• Impact on supporting utilities and processes

Passive Database Protection Approaches

Database Protection

Approach

Performance Storage Security Transparency Separation

of Duties

Web Application Firewall

Data Loss Prevention

Database Activity

Choose Your Defenses - Operational Impact

Database Activity

Monitoring

Database Log Mining

Best Worst

Source: 2009 Protegrity Survey

Active Database Protection Approaches

Database Protection

Approach

Performance Storage Security Transparency Separation

of Duties

Application Protection - API

Column Level Encryption;

FCE, AES, 3DES

Column Level Replacement;

Choose Your Defenses - Operational Impact

Column Level Replacement;

Tokens

Tablespace - Datafile

Protection

Best Worst

Source: 2009 Protegrity Survey

Application Databases

Choose Your Defenses – New Methods

Key Manager

Format Controlling Encryption

Example of Encrypted format:

111-22-1013

Token Server

Token

Data Tokenization

Example of Token format:

1234 1234 1234 4560

Application

Databases

Key Manager

Format Controlling

Newer Data Protection Options

Format Controlling

Encryption (FCE)

What Is 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?

• 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 Selling Points

Ease of deployment -- limits the database schema changes that

are required.

Reduces changes to downstream systems

Applicability to data in transit – provides a strict/known data

format that can be used for interchange

Storage space – does not require expanded storageStorage space – does not require expanded storage

Test data – partial protection

Outsourced environments & virtual servers

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

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

FCE Use Cases

Suitable for lower risk data

Compliance to NIST standard not needed

Distributed environments

Protection of the data flow

Added performance overhead can be accepted

Key rollover not needed – transient dataKey rollover not needed – transient data

Support available for data size, type, etc.

Point to point protection if “big iron” mixed with Unix or

Windows

Possible to modify applications that need full clear text – or

database plug-in available

Data Tokenization

Newer Data Protection Options

Data Tokenization

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

Tokenization Selling Points

Provides an alternative to masking – in production, test and

outsourced environments

Limits schema changes that are required. Reduces impact on

downstream systems

Can be optimized to preserve pieces of the actual data in-place –

smart tokens

Greatly simplifies key management and key rotation tasksGreatly simplifies key management and key rotation tasks

Centrally managed, protected – reduced exposure

Enables strong separation of duties

Renders data out of scope for PCI

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

Security vulnerabilities of the tokens themselves –

randomness and possibility of collisions

Security vulnerabilities typical in in-house developed systems

– exposing patterns and attack surfaces

Suitable for high risk data – payment card data

When compliance to NIST standard needed

Long life-cycle data

Key rollover – easy to manage

Centralized environments

Suitable data size, type, etc.

Tokenization Use Cases

Suitable data size, type, etc.

Support for “big iron” mixed with Unix or Windows

Possible to modify the few applications that need full clear text

– or database plug-in available

A Centralized Tokenization Approach

Token

Server

Customer

Application

Customer

Application

Customer

Application

A Distributed and Scalable Tokenization Approach

Customer

Application

Token

Server

Customer

Application

Customer

Application

Token

Server

Customer

Application

Token

Server

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

Best Worst

Pricing

Model Per Transaction

Data

Types

Identifiable - PII

Cardholder - PCI

Security

Separation

Compliance

Scope

• ‘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 – Example

Encryption

Aggregation

Operations

Collection

-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

Data Token

Operations

Analysis

Archive

Choose Your Defenses – Strengths & Weakness

*

*

Best Worst

* Compliant to PCI DSS 1.2 for making PAN unreadable

*

*

Source: 2009 Protegrity Survey

An Enterprise View of Different Protection Options

Evaluation Criteria Strong

Encryption

Formatted

Encryption

Token

Disconnected environments

Distributed environments

Performance impact when loading data

Transparent to applications

Expanded storage sizeExpanded 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

Matching Data Protection Solutions with Risk Level

Risk Level Solution

Monitor

Monitor, mask,

Low Risk

(1-5)

Data

Field

Risk

Level

Credit Card Number 25

Social Security Number 20

CVV 20

Deploy Defenses

Monitor, mask,

access control

limits, format

control encryption

Replacement,

strong

encryption

At Risk

(6-15)

High Risk

(16-25)

CVV 20

Customer Name 12

Secret Formula 10

Employee Name 9

Employee Health Record 6

Zip Code 3

Data Protection Implementation Layers

System Layer Performance Transparency Security

Application

Database

File System

Topology Performance Scalability Security

Local Service

Remote Service

Best Worst

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)

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

Compliance - How to Control ALL Access to PHI Data

DBA Box

File

Backup (Tape)EncryptedDatabase

Compliant

Database

Administration

Encrypted

Encrypted

Encrypted

Protected sensitive informationUnprotected sensitive information:

Not Compliant

File

Backup (Tape)Clear TextDatabase

Database

Administration

Encrypted

Clear Text

Clear Text

Data Protection Challenges

Actual protection is not the challenge

Management of solutions• Key management

• Security policy

• Auditing and reporting

Minimizing impact on business operationsMinimizing impact on business operations• Transparency

• Performance vs. security

Minimizing the cost implications

Maintaining compliance

Implementation Time

Example - Centralized Data Protection Approach

Database

Protector

File System

Protector PolicyPolicy & Key

Creation

Secure

Storage

Secure

Distribution

Secure

Usage

Audit

Log

PolicyPolicy

Secure

Archive

Enterprise

Data Security

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

Protegrity Value Proposition

Underlying foundation for the platform includes

comprehensive data security policy, key

management, and audit reporting.

Enables customers to achieve data security

compliance (PCI, HIPAA, PEPIDA, SOX and Federal & State Privacy Laws)

Please contact us for more information

Ulf Mattsson

Phone – 203 570 6919

Email - ulf.mattsson@protegrity.com