Top Banner
Myths and Realities of Data Security and Compliance: The Risk-based Data Protection Solution The Risk-based Data Protection Solution Ulf Mattsson, CTO, Protegrity
73

ISACA Los Angeles 2010 Compliance - Ulf Mattsson

Oct 19, 2014

Download

Documents

ISACA Los Angeles 2010 Compliance - Ulf Mattsson
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Myths and Realities of Data Security and Compliance:

The Risk-based Data Protection Solution The Risk-based Data Protection Solution

Ulf Mattsson, CTO, Protegrity

Page 2: ISACA Los Angeles  2010   Compliance - 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)

Received US Green Card of class ‘EB 11 – Individual of Extraordinary Ability’ after 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

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 Los Angeles  2010   Compliance - Ulf Mattsson

ISACA Articles (NYM)

Page 4: ISACA Los Angeles  2010   Compliance - Ulf Mattsson
Page 5: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Topics

Review current/evolving data security risks

Explore the methods that enable organizations to achieve the right balance between cost, performance, usability, compliance demands and real-world security needs

Develop a risk adjusted methodology for securing data and evaluating security solutions

Review real world examples: protecting PCI, PII and MNPI Review real world examples: protecting PCI, PII and MNPI (Material Non-Public Information) data throughout its entire lifecycle

Other topics?

Q&A

Review real world examples for IBM, Microsoft & Oracle

Page 6: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

PIISocial security number

Drivers license number

Private account numbers

Date of birth

PCI & Customer DataCredit & Loyalty cards

Banking/mortgage data

Customer profiles

Prospect information

Health RecordsCompany Data

Protect Sensitive Data

Health RecordsInsurance claims

Medical records

Prescriptions

Billing information

Company DataSalary / bonus

HR data

Corporate secrets

Financial results

Page 7: ISACA Los Angeles  2010   Compliance - 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 operationsMinimizing impact on business operations• Transparency

• Performance vs. security

Minimizing the cost implications

Maintaining compliance

Implementation Time

Page 8: ISACA Los Angeles  2010   Compliance - 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 DefensesDeploy Defenses

Crunch the Numbers

Page 9: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

The Gartner 2010 CyberThreat Landscape

Page 10: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Data Security Remains Important for Most

Source: Forrester, 2009

Page 11: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

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

Page 12: ISACA Los Angeles  2010   Compliance - 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:

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

Page 13: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Market Drivers for Deeper Data Security

Brand damage• Staying out of the headlines

• Damage to credibility

Regulatory mandates• PCI

• Country/Provincial/State Privacy Laws• Country/Provincial/State Privacy Laws

• Sarbanes-Oxley

• HIPAA

Cost of recovery and fixes - Forrester Research gives a cost range of $90-$305 per record

Increasing liability and insurance

Page 14: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Information Security Breaches

In the U.S., 2005 was the year of the security breach

• Followed by 2006, 2007, 2008 and 2009 . . .

Since 2005, over 1,000 information security breaches

• Choice Point - Card Systems

• Bank of America - Boston Globe

• Lexis Nexis - Veterans Administration

• Heartland Payment Systems - TJX• Heartland Payment Systems - TJX

Over 236 million potentially affected

Over 40 U.S. jurisdictions have security breach notification laws

• California SB 1386 started the trend

New federal breach notification law for health information

Numerous federal bills

Page 15: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

State Security Breach Notification Laws

Generally, the duty to notify arises when unencrypted computerized “personal

information” was acquired or accessed by an unauthorized person

“Personal information” is an individual’s name, combined with:

• SSN

• Driver’s license or state ID card number

• Account, credit or debit card number, along with password or access code

But state laws differ:But state laws differ:

• Computerized v. paper data

• Definition of PII

• Notification to state agencies

• Notification to CRAs

• Timing of individual notification

• Harm threshold

• Contents of notification letter

Page 16: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Federal Breach Notification Law

The HITECH Act has changed the federal breach notification landscape

• HHS and FTC have promulgated breach notification rules pursuant to HITECH Act requirements

The HITECH Act requires HIPAA covered entities to:

• notify individuals whose “unsecured protected health information” in any format has been, or is reasonably believed to have been “accessed, acquired or disclosed” as a result of a breach“accessed, acquired or disclosed” as a result of a breach

Business associates are responsible for notifying covered entities of a breach

Page 17: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Recent FTC Enforcement Actions

Federal Trade Commission (FTC) enforcement authority: Section 5 of the FTC Act

Most FTC privacy enforcement actions result from security breaches

• Card Systems, Petco, ChoicePoint, Tower Records, DSW, Barnes & Noble.com, BJ’s Wholesale Club, Guess.com Inc., CVS, Caremark, Genica Corporation O

Division of Privacy and Identity ProtectionDivision of Privacy and Identity Protection

Enforcement trends

Page 18: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Costs of Non-Compliance with PCI

Costs of non-compliance can be significant

Card brands fine merchant banks, and costs are “passed through” to merchants by contract

Possible fines of $5,000 to $25,000 per month for Level 1 and 2 merchants that have not validated compliancecompliance

In the event of a security breach, possible fines of up to $500,000 per incident plus associated costs

Page 19: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Avoiding Breach Notification

HHS issued guidance on April 17, 2009 setting forth an exhaustive list of what technologies and methodologies will render PHI secure.

HHS provided additional guidance on August 24, 2009.

Technologies and Methodologies that will render PHI secure:

• Encryption.

• Destruction.

Nothing else will render your PHI secure.

In most recent guidance, HHS:

• Rejected access controls, such as firewalls, as a method for securing PHI.

Page 20: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

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)

Page 21: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Dataset Comparison – Data Type

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

Page 22: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Targeted Threat Growth

Page 23: ISACA Los Angeles  2010   Compliance - 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

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:

Page 24: ISACA Los Angeles  2010   Compliance - 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

DatabaseProcess 001

User Access Patient Health Record

PatientHealth

Record

a xxx

b xxx

c xxx

Performance?

3rd Party

Possible DBA

manipulation

Protected

No Read

Log

Application/Too

l

User 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

Protected

Log

No

Information

On User

or Record

Protected sensitive informationUnprotected sensitive information:

Page 25: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

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

Page 26: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

2009 Data Breach Investigations

Top 15 Threat Action Types

2009 Data Breach Investigations Supplemental Report,

Verizon Business RISK team

Page 27: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Top 15 Threat Action Types

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

Page 28: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

NW

DMZ

TRUSTED

SEGMENT

Serve

r

Inte

rne

t

Load

Balancing

Enterprise

AppsSAN,

NAS,

Tape

Internal

UsersDB Server

TRANSACTIONSEnd-

point

DBA

ATTACK

MALWARE /

TROJAN

Data Level Attacks on the Enterprise Data Flow

NW

Web Apps

Inte

rne

t

Proxy

FW

Proxy

FWNetwork

DevicesServer

Tape

Proxy

FWIDS/

IPS

Wire-

less

OS ADMIN

FILE ATTACK

SQL

INJECTIONMEDIA

ATTACK

SNIFFER

ATTACK

Page 29: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Addressing Data Protection Challenges

Full mapping of sensitive data flow

• Where is the data

• Where does it need to be

Identify what data is needed for processing in which applications

• What are the performance SLAs

Understand the impact of changing/removing data

• Will it break legacy systems

Address PCI, strategize for the larger security issue

Page 30: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Protecting the Data Flow - Example

Page 31: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Top 6 threat action types - Mitigation

Known usernames

Abuse of resources

Specially crafted SQL statements

Infected systems

Collect usernames and passwords

Encryption ofdata in transit

Monitoring

And blocking

Web Application

Firewall

Token or

Point-to-point

encryption (E2EE)

Token,

Point-to-point

encryption (E2EE)

or File protection

Monitoring

And blocking

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

and passwords

Monitoring

And blocking

Page 32: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Example of Secure Login – One Time Password

Page 33: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Positioning Different Data Protection Approaches

Page 34: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Data Protection Challenges

Actual protection is not the challenge

Management of solutions

• Key management

• Reporting

• Policy

Minimizing impact on business operations

• Performance v. security

Minimizing impact (and costs)

• Changes to applications

• Impact on downstream systems

Time

Page 35: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

The Goal: Good, Cost Effective Security

The goal is to deliver a solution that is a balance between security, cost, and impact on the current business processes and user community

Security plan - short term, long term, ongoing

How much is ‘good enough’How much is ‘good enough’

Security versus compliance

• Good Security = Compliance

• Compliance ≠ Good Security

Page 36: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Choose Your Defenses – Different Approaches

Page 37: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Choose Your Defenses – Cost Effective PCI

Encryption 74%

WAF 55%

DLP 43%

Source: 2009 PCI DSS Compliance Survey, Ponemon Institute

DLP 43%

DAM 18%

Page 38: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Choose Your Defenses – Cost Effective PCI

Page 39: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

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

Page 40: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

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

Page 41: ISACA Los Angeles  2010   Compliance - 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

Database Activity

Monitoring

Database Log Mining

Best Worst

Source: 2009 Protegrity Survey

Page 42: ISACA Los Angeles  2010   Compliance - 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

Column Level Replacement;

Tokens

Tablespace - Datafile

Protection

Best Worst

Source: 2009 Protegrity Survey

Page 43: ISACA Los Angeles  2010   Compliance - 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 – 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

Page 44: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

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

Page 45: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Format Controlling Encryption (FCE)

Newer Data Protection Options

Page 46: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

What Is FCE?

Where did it come from?

• Before 2000 – Different approaches, some are based on block ciphers (AES, 3DES O)

• 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

Page 47: ISACA Los Angeles  2010   Compliance - 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 storageStorage space – does not require expanded storage

Test data – partial protection

Outsourced environments & virtual servers

Page 48: ISACA Los Angeles  2010   Compliance - 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

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 49: ISACA Los Angeles  2010   Compliance - 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 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

Page 50: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Applications are Sensitive to the Data Format

Binary (Hash) -

Binary (Encryption) -

Alphanum (FCE, Token) -

Data Type

Many Applications

Few Applications

No Applications

Increased

intrusiveness:

Bin

Data

Text

Data

Alphanum (FCE, Token) -

Numeric (FCE, Token) -

Numeric (Clear Text) -

Data

Field

Length

I

Original

I

Longer

All Applications

Most Applications

Many Applications

This is a generalized example

intrusiveness:- Application changes

- Limitations in functionality

- Limitations in data search

- Performance issues

Page 51: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Data Tokenization

Newer Data Protection Options

Data Tokenization

Page 52: ISACA Los Angeles  2010   Compliance - 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?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 53: ISACA Los Angeles  2010   Compliance - 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 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

Page 54: ISACA Los Angeles  2010   Compliance - 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

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 55: ISACA Los Angeles  2010   Compliance - 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

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 56: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Tokenization Users Show Significantly Better Results

Page 57: ISACA Los Angeles  2010   Compliance - Ulf Mattsson
Page 58: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

A Central Token Solution

Token

Server

Customer Application

Customer Application

Customer Application

Page 59: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

A Distributed Token Solution

Customer Application

Token

Server

Customer Application

Customer Application

Token

Server

Customer Application

Token

Server

Page 60: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

An Integrated Token Solution

Token Server

Customer Application

Customer Application

Token Server

Customer Application

Customer Application

Page 61: ISACA Los Angeles  2010   Compliance - 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

Operational

Needs

Availability

Scalability

Performance

PricingPer Server

Best Worst

PricingModel Per Transaction

DataTypes

Identifiable - PII

Cardholder - PCI

SecuritySeparation

Compliance Scope

Page 62: ISACA Los Angeles  2010   Compliance - 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

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 63: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

An Integrated Token Solution

Distributed

Static

StaticRandomTokenTable

StaticRandomTokenTable

Distributed

Static

Token Tables

StaticRandomTokenTable

StaticRandomTokenTable

Customer

Application

Customer

Application

A Distributed Token Solution

StaticRandomTokenTable

Static

Token Tables

Integrated with Pep-Server

StaticRandomTokenTable

StaticRandomTokenTable

Customer

Application

Customer

Application

Static

Token Tables

Token Tables

Distributed

Static

Token Tables

StaticRandomTokenTable

StaticRandomTokenTable

Distributed

Static

Token Tables

StaticRandomTokenTable

StaticRandomTokenTable

Customer

Application

Customer

Application

StaticRandomTokenTable

Static

Token Tables

Integrated with PepServer

StaticRandomTokenTable

StaticRandomTokenTable

Customer

Application

Customer

Application

Integrated with Pep-Server

Page 64: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Choose Your Defenses – Strengths & Weakness

*

*

Best Worst

* Compliant to PCI DSS 1.2 for making PAN unreadable

*

*

Source: 2009 Protegrity Survey

Page 65: ISACA Los Angeles  2010   Compliance - 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 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

Page 66: ISACA Los Angeles  2010   Compliance - 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

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 67: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Data Protection Implementation Layers

System Layer Performance Transparency Security

Application

Database

File System

Topology Performance Scalability Security

Local Service

Remote Service

Best Worst

Page 68: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Risk-adjusted data security plans are cost effective

Switching focus to a holistic view rather than security silo methodology

Understanding of where data resides usually results in a project to reduce the number of places where

Crunch the Numbers – Conclusion

a project to reduce the number of places where sensitive data is stored

Protect the remaining sensitive data with a comprehensive data protection solution

Page 69: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Managing encryption keys across different across different

platforms

Page 70: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Deployment

Hardware

Security

Module

RACFApplications

DB2

Files

ICSFEncryption

SolutionMainframe

z/OS

Central Key

Manager

DB2 UDB

Informix

System i

Oracle

<

Hardware

Security

Module

Page 71: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Example - Centralized Data Protection Approach

Database Protector

File System Protector PolicyPolicy & Key

Creation

Secure Storage

Secure Distribution

Secure Usage

AuditLog

PolicyPolicy

Secure Archive

EnterpriseData Security

Auditing &Reporting

Secure Collection

Data Security Administrator

Application

Protector

Big Iron

Protector

Page 72: ISACA Los Angeles  2010   Compliance - 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

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)

Page 73: ISACA Los Angeles  2010   Compliance - Ulf Mattsson

Please contact us for more information

Ulf Mattsson

Phone – 203 570 6919

Email - [email protected]