ISACA National Capital Area Chapter (NCAC) in Washington, DC - Ulf Mattsson

56
Myths and Realities of Data Security and Compliance: A Risk-based Approach to Compliance: A Risk-based Approach to Data Protection Ulf Mattsson, CTO, Protegrity
  • date post

    19-Oct-2014
  • Category

    Documents

  • view

    1.187
  • download

    0

description

ISACA National Capital Area Chapter (NCAC) in Washington, DC - Ulf Mattsson

Transcript of ISACA National Capital Area Chapter (NCAC) in Washington, DC - Ulf Mattsson

Page 1: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Myths and Realities of Data Security and Compliance: A Risk-based Approach to Compliance: A Risk-based Approach to

Data Protection

Ulf Mattsson, CTO, Protegrity

Page 2: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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)

2

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)

Page 3: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson
Page 4: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

ISACA Articles (NYM)

4

Page 5: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Review current/evolving data security risks

Review newer data protection methods

How to achieve the right balance between cost,

performance, usability, compliance demands,

and real-world security needs

Topics

5

and real-world security needs

Introduce a process for developing a risk-

adjusted data security plan

Page 6: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

The Gartner 2010 CyberThreat Landscape

6

Page 7: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Targeted Threat Growth

7

Page 8: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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:

8

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

Page 9: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Top 15 Threat Action Types

9

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

Page 10: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Dataset Comparison – Data Type

10

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

Page 11: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

“Everything should be made as simple as possible,

but not simpler”,

said Albert Einstein.

11

Page 12: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Data Entry

Database

Application

Data System

Choose Your Defenses

Where is data

Exposed111 - 77 - 1013

990 - 23 - 1013

12

File System

Storage

(Disk)

Backup

(Tape)

Exposed

to attacks?

111 - 77 - 1013

Protected sensitive information

Unprotected sensitive information:

Page 13: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Data Entry

Database

Application

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

13

File System

Storage

(Disk)

Backup

(Tape)

DATABASE ATTACK

FILE ATTACK

MEDIA ATTACK

5

111 - 77 - 1013

Protected sensitive information

Unprotected sensitive information:

Page 14: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

14

File System

Storage

(Disk)

Database

Admin

System Admin

HW Service People

Contractors

5

Backup

(Tape)

DATABASE ATTACK

FILE ATTACK

MEDIA ATTACK

5

111 - 77 - 1013

Protected sensitive information

Unprotected sensitive information:

Page 15: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Developing a Risk-adjusted Data Protection Plan

Know Your Data

Find Your Data

Understand Your Enemy

Understand the New Options in Data Protection

Deploy Defenses

15

Deploy Defenses

Crunch the Numbers

Page 16: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

16

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

Page 17: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Choose Your Defenses – Different Approaches

17

Page 18: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

18

Database Activity

Monitoring

Database Log Mining

Best Worst

Source: 2009 Protegrity Survey

Page 19: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

19

Column Level Replacement;

Tokens

Tablespace - Datafile

Protection

Best Worst

Source: 2009 Protegrity Survey

Page 20: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Choose Your Defenses – Cost Effective PCI

Encryption 74%

WAF 55%

DLP 43%

20

Source: 2009 PCI DSS Compliance Survey, Ponemon Institute

DLP 43%

DAM 18%

Page 21: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Beyond PCI DSS - Best Practices for Card Data – E2EE

21

Page 22: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Application Databases

Data Defenses – New Methods

Key Manager

Format Controlling Encryption

Example of Encrypted format:

111-22-1013

22

Token Server

Token

Data Tokenization

Example of Token format:

1234 1234 1234 4560

Application

Databases

Key Manager

Page 23: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

What Is Format Controlling Encryption (FCE)?

Where did it come from?

• Before 2000 – Different approaches, some are based on

block ciphers (AES, 3DES L)

• Before 2005 – Used to protect data in transit within

enterprises

What exactly is it?

23

• 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

Page 24: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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?

24

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)

Page 25: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Old Technology - A Centralized Token Solution

Token

Server

Customer

Application

25

Customer

Application

Customer

Application

Page 26: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

26

-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

Page 27: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

27

Security vulnerabilities of the tokens themselves –

randomness and possibility of collisions

Security vulnerabilities typical in in-house developed systems

– exposing patterns and attack surfaces

Page 28: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

28

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

Page 29: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

New Technology - Distributed Tokenization

Customer

Application

Token

Server

Customer

Application

29

Customer

Application

Token

Server

Customer

Application

Token

Server

Page 30: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

30

Best Worst

Pricing

Model Per Transaction

Data

Types

Identifiable - PII

Cardholder - PCI

Security

Separation

Compliance

Scope

Page 31: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Protecting the Data Flow - Choose Your Defenses

31

Page 32: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

32

Column Level Replacement;

Scalable Distributed Tokens

Column Level Replacement;

Central Tokens

Tablespace - Datafile

Protection

Best Worst

Page 33: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

33

•Data Transmission

Business Associates,

Covered Entities

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

Page 34: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Compliance – How to be Able to Produce Required Reports

Database

PatientHealth

Record

a xxx

b xxx

Application/Tool

34

OS File

DatabaseProcess 001

c xxx

Health DataFile PHI002

Page 35: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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)

35

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

Page 36: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

36

• Transparency

• Performance vs. security

Minimizing the cost implications

Maintaining compliance

Implementation Time

Page 37: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

37

Auditing &

Reporting

Secure

Collection

Data Security

Administrator

Application

Protector

Big Iron

Protector

Page 38: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

38

data security policy, key management, and audit reporting.

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

Page 39: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

39

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

Page 40: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

40

Please contact us for more information

Ulf Mattsson

[email protected]

Rose [email protected]

Page 41: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Format Controlling

Newer Data Protection Options

41

Format Controlling

Encryption (FCE)

Page 42: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

What Is FCE?

Where did it come from?

• Before 2000 – Different approaches, some are based on

block ciphers (AES, 3DES L)

• Before 2005 – Used to protect data in transit within

enterprises

What exactly is it?

42

• 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

Page 43: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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 storage

43

Storage space – does not require expanded storage

Test data – partial protection

Outsourced environments & virtual servers

Page 44: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

44

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

Page 45: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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 data

45

Key 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

Page 46: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Data Tokenization

Newer Data Protection Options

46

Data Tokenization

Page 47: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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?

47

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)

Page 48: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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 tasks

48

Greatly simplifies key management and key rotation tasks

Centrally managed, protected – reduced exposure

Enables strong separation of duties

Renders data out of scope for PCI

Page 49: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

49

Security vulnerabilities of the tokens themselves –

randomness and possibility of collisions

Security vulnerabilities typical in in-house developed systems

– exposing patterns and attack surfaces

Page 50: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

50

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

Page 51: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

A Central Token Solution vs. A Distributed Token Solution

Dynamic

Random

Token Table

-

-

-

-

-Distributed

Static

Static

Random

Token

Table

Static

Random

Token

TableDistributed

Static

Token Tables

Static

Random

Token

Table

Static

Random

Token

TableCustomer

Application

Customer

Application

Customer

Customer

Application

51

Central Dynamic

Token Table

Customer

Application

Customer

Application

-

.

.

.

.

.

.

.

.

.

Static

Token Tables

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

Page 52: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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

52

Best Worst

Pricing

Model Per Transaction

Data

Types

Identifiable - PII

Cardholder - PCI

Security

Separation

Compliance

Scope

Page 53: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Choose Your Defenses – Strengths & Weakness

*

*

53

Best Worst

* Compliant to PCI DSS 1.2 for making PAN unreadable

*

*

Source: 2009 Protegrity Survey

Page 54: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

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 size

54

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

Page 55: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Data Protection Implementation Layers

System Layer Performance Transparency Security

Application

Database

File System

55

Topology Performance Scalability Security

Local Service

Remote Service

Best Worst

Page 56: ISACA National Capital Area Chapter (NCAC) in Washington, DC -  Ulf Mattsson

Example of Secure Login – One Time Password

56