Risk Management: Understanding the New Options in Data Protection for DB2 and Files Ulf Mattsson, CTO Protegrity.

Risk Management: Understanding the New Options in

Data Protection for DB2 and Files

Ulf Mattsson, CTO Protegrity

Ulf T. Mattsson20 years with IBM Development, Manufacturing & Services

Inventor of 20+ Patents

Protegrity co-founder

Research member of the International Federation for Information Processing (IFIP) WG 11.3 Data and Application Security

American National Standards Institute (ANSI) X9

Institute of Electrical and Electronics Engineers (IEEE)

The World Scientific and Engineering Academy and Society for Computer Security (WSEAS)

Object Management Group (OMG) CORBA Security Service

Computer Security Institute (CSI)

Information Systems Security Association (ISSA)

Information Systems Audit and Control Association (ISACA)

02

03

September 23, 2009

http://www.knowpci.com

Source of Information about PCI Research

http://www.knowpci.com/

http://www.knowpci.com/

Agenda

Compliance aspects for PCI and PII data

New security threats

Advantages/disadvantages of different data protection options

Deploying encryption and tokenization for data security

Managing encryption keys across different platforms

PCI and real examples

Other topics

Q&A

Compliance & security aspects for

PCI and PII data

Link to webinar recording https://www2.gotomeeting.com/register/55333245806

https://www2.gotomeeting.com/register/553332458

Why care about database security?

In 2008, this [criminal activity] was accomplished by targeting points of data

concentration or aggregation and acquiring more valuable sets of consumer information.

The big money is now in stealing personal identification number (PIN) information together

with associated credit and debit accounts.

Source: 2009 Data Breach Investigations Report Verizon Business

Online Data Under Attack – Not Laptops or Backup

Slide source: Verizon Business 2008 Data Breach Investigations Report

Breaches attributed to insiders are much larger than those caused by outsiders

The type of asset compromised most frequently is online data:

87% of breaches could have been avoided through reasonable controls

Assets most commonly breached

Table 9. Detailed listing of compromised assets by percentage of breaches and records

Asset Asset Group % of Breaches % of Records

POS system Online Data 32% 6%

Database server Online Data 30% 75%

Application server Online Data 12% 19%

Web server Online Data 10% 0.004%

File server Online Data 8% 0.1%

Public kiosk system Online Data 2% 0.4%

Authentication / Directory server Online Data 2% 0.1%

Backup tapes Offline Data 1% 0.04%

Documents Offline Data 1% 0.000%

Workstation End-User System 8% 0.01%

Laptop End-User System 4% 0.000%

PIN Entry Device End-User System 2% 0.004%

Source: 2009 Data Breach Investigations Report

Verizon Business

How many records breached?

Median number of records breached: • External Attack: 37,847• Internal Attack: 100,000

Cost of a breach is approximately • $202 per record compromised

Source: 2009 Data Breach Investigations Report Verizon Business

Source: Fourth Annual US Cost of Data Breach StudyPonemon Institute

Laws

California data breach notification law Adopted in states beyond California

Massachusetts privacy laws Effective date is March 2010

Personally Identifiable Information (PII) Name Social Security Number Address Account Numbers

Laws (continued)

HIPAA § 164.312 Technical Safeguards (a)(2)(iv) Encryption and decryption (Addressable).

Implement a mechanism to encrypt and decrypt electronic protected health information

HITECH Act of 2009 Extends security requirements to ‘associate’ service

providers

A Simple Risk-adjusted Data Protection Plan

1. Know Your Data

2. Find Your Data

3. Understand Your Enemy

4. Choose Your Defenses

5. Deploy Defenses

6. Crunch the Numbers

6 Steps to Develop the Plan:

Step1: 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 LevelCredit Card Number 25

Social Security Number 20CVV 20

Customer Name 12Secret Formula 10

Employee Name 9Employee Health Record 6

Zip Code 3

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

• Decision making information- Typically multi-year lifecycle- Homogeneous computing environment- High volume database analysis

• Archive -Typically multi-year lifecycle -Preserving the ability to retrieve the data in the future is important

POS e-commerce Branch

Aggregation

Operations

Analysis

Archive

Collection

Step 2: Find Your Data – Understand the Data Flow

Where and When is Data Most at Risk?

Errors and Omissions

Higher Probability

Lost Backups, In Transit

Application Developer, Valid User for Data

Higher Complexity

Application User (e.g. SQL Injection)

SQL Users

Network or Application/RAM Sniffer

Valid User for the Server (e.g. Stack Overflow, data sets)

Administrator

RECENTATTACKS

Step 3: Understand Your Enemy – Probability of Attacks

Source: IBM Silicon Valley Lab(2009)

What is the Probability of Different Attacks on Data?

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

Dataset Comparison – Data Type

018

019

File System

Data Entry

Database

Storage (Disk)

Application

Authorized/ Un-authorized

Users

DatabaseAdmin

System Admin

HW Service People

Contractors…

ATTACKERS

Data System

Choose Your Defenses

Backup (Tape)

DATABASE ATTACK

MALWARE / TROJAN

FILE ATTACK

SQL INJECTION

MEDIA ATTACK…

SNIFFER ATTACK

RECENT ATTACKS

Where is data exposed to attacks?

111 - 77 - 1013

990 - 23 - 1013

Protected sensitive information

Unprotected sensitive information:

http://images.google.com/imgres?imgurl=http://www.mpe07.co.uk/images/RG500%201ST&2ND&6TH%20001.jpg&imgrefurl=http://www.mpe07.co.uk/prod04.htm&usg=__Pa6UYFze3K8kG2MoTMQIXlYGvXo=&h=480&w=640&sz=53&hl=en&start=41&sig2=VBaCW478RZ4NL4EA33P_hg&um=1&tbnid=M1ycfOYMbrwmkM:&tbnh=103&tbnw=137&prev=/images?q=gear+pair&ndsp=20&hl=en&rlz=1T4SKPB_enUS294US294&sa=N&start=40&um=1&ei=0_L_SoWqIYXSnAef86m4Cw

File System

Security Admin

Database

Application

Application / Database ServerNO Monitoring

of Column and User

XFile System

Database

Application

Monitoring of Column and User

Application / Database Server

Security Admin

Granular Reporting for Compliance & Better Security



2009 Data Breach Investigations Supplemental Report,

Verizon Business RISK team

Top 15 Threat Action Types


Top 15 Threat Action Types

Protecting the Data Flow - Example


Top 6 threat action types - Mitigation

Known usernames and passwords

Abuse of resources

Specially crafted SQL statements

Infected systems

Collect usernames and passwords

Encryption ofdata in transit

MonitoringAnd blocking

Web ApplicationFirewall

Token or Point-to-point encryption (E2EE)

Token, Point-to-point encryption (E2EE) or File protection



File System

Application

Network

Backup (Tape)

Storage (Disk)

Protected sensitive information

Unprotected sensitive information:

111 - 77 - 1013

DataEntry

File System

Database Database

Backup (Tape)

Storage (Disk)

Application Application Application

Step 4: Choose Your Defenses – Protect the Data Flow

Mitigation at the Right System Layer

990 - 23 - 1013

990 - 23 - 1013

Advantages/disadvantages of different

data protection options

028

Application Databases

Step 4: Choose Your Defenses - New Protection Models

Key Manager

Format Controlling Encryption

Token Server

Token

Data Tokenization

Example of Token format:

1234 1234 1234 4560


Key Manager

Example of Encrypted format:

111-22-1013

Format Controlling Encryption

Token Server

Token & CCN

Data TokenizationExample of Token format:

1234 1234 1234 4560



111-22-1013Example of clear text user output:

990-23-1013

Example of clear text user output:

5549 9437 0789 4560


Data Protection Options – Newer Methods

Strong Encryption


x%$#..=…….(*)& …

Hashing (key’d – HMAC – SHA-1)

Example of hashed format (SHA-1 = 20 bytes):

(#@...&&*..x.....%$#..=…….(*)& …)

Example of Hashed user output:

(#@...&&*..x.....%$#..=…….(*)& …)

Example of clear text user output:

5549 9437 0789 4560



Data Protection Options – Traditional Methods

What Is Formatted Encryption?

Where did it come from?• Before 2000 – Different approaches, some are based

on block ciphers (AES, 3DES …)

• 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

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

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

Point of Sale

E-Commerce

Branch Office

Data Token

Step 4: Choose Your Defenses – Example

Encryption

Aggregation

Operations

Analysis

Archive

Collection

Direction – Scalable Token Solutions

AdminSever

• Policy Management

• Key Management

• Reporting

Customer Application

TokenServer



Token Server


036

Text Data

Applications are Sensitive to the Data Format

Binary (Hash) -

Binary (Encryption) -

Alphanum (FCE, Token) -

Numeric (FCE, Token) -

Numeric (Clear Text) -

Data

Field

Length

Data Type

I

Original

I

Longer

All Applications

Most Applications

Many Applications

Few Applications

No Applications

This is a generalized example

Increased intrusiveness:

- Application changes

- Limitations in functionality

- Limitations in data search

- Performance issues

BinData

Database Server

Database Activity Monitoring /

Data Loss Prevention

Web Application Firewall

TablespaceDatafiles

Database Log Files

Applications

DatabaseColumns

Database Activity

Monitoring

Passive Approaches and Active Approaches = End-To-End Protection

Step 4: Choose Your Defenses – A Balanced Approach

Source: 2009 PCI DSS Compliance Survey, Ponemon Institute

Step 4: Choose Your Defenses – Cost Effective PCI

Encryption 74%WAF 55%

DLP 43%

DAM 18%

Best Worst

Step 4: Choose Your Defenses – Strengths/Weaknes

*: Compliant to PCI DSS 1.2 for making PAN unreadable

**

*

RiskLevel

Cost

OptimalRisk

Expected Losses from the Risk

Cost of Aversion – Protection of Data

Total Cost

IPassive Protection

IActive Protection

Step 4: Choose Your Defenses – Find the Balance

X

Matching Data Protection Solutions with Risk Level

Risk Level Solution

Monitor

Monitor, mask, access control limits, format control encryption

Replacement, strong encryption

Low Risk (1-5)

At Risk (6-15)

High Risk (16-25)

Data Field

Risk Level

Credit Card Number 25Social Security Number 20

CVV 20Customer Name 12Secret Formula 10

Employee Name 9Employee Health Record 6

Zip Code 3

Step 5: Deploy Defenses

042

Managing encryption keys across different

platforms

Central Key Manager

Step 5: Deployment

HardwareSecurity Module

RACFApplications

DB2

Files

ICSFEncryptionSolution

Mainframe z/OS

DB2 UDB

Informix

System i

Oracle…


Key Management Considerations

Keys should be cached or stored on the mainframe

In a mature solution, the DB2 subtask should not expose the key in a dump of the DB2 master task or User Task

• DB2 V8+ native column-level encryption has the encryption key in a dump of the DB2 master task

• The subtask should only have the key-label, which is not enough to encrypt the data and is meaningless since it’s only the name of the key

• The IBM Data Encryption Tool uses DB2 EDITPROC, and a key label is stored in the EDITPROC

Key files (ICSF CKDS and other sensitive data sets) should be RACF protected and encrypted

Define userids for the started tasks and prevent almost every other id from accessing the DB2 data sets

There are some exceptions for administrators who must manage the logs or work with the DSN1* utilities

• Having separate IDs for each subsystem is the standard recommendation

044

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 sensitive data is stored

Protect the remaining sensitive data with a comprehensive data protection solution

Step 6: Crunch the Numbers – Conclusion

46

Use Case – PCI and PII Data Protection

046

‘Information in the wild’• Short lifecycle / High risk• Databases often found at collection points

Temporary information • Short lifecycle / High risk• Use the transition as an opportunity to re-key the

locks

Operating information• Typically 1 or more year lifecycle• Broad and diverse computing and database

environment• Wide internal audience with privileges

Decision making information• Typically multi-year lifecycle• Homogeneous computing environment• High volume database analysis• Wide internal audience with privileges

Archive• Typically multi-year lifecycle• Preserving the ability to retrieve the data in the

future is important

POS e-commerce Branch

Aggregation

Operations

Analysis

Archive

Collection

Data Security Enforcement

Mainframe

RACF, ICSF

and hardware

data encryption support

047

Data Protection and Encryption on z/OS – PCI DSS


RACFApplications

DB2

Files

ICSF

EncryptionSolution

API

Fieldproc,Editproc,

UDF

Utility

Mainframe z/OS

Evaluation of Encryption Options for DB2 on z/OS

Encryption Interface

Performance PCI DSS Security Transparency

API

UDF DB2 V7 & V8

UDF DB2 V9

Fieldproc

Editproc

049

Best Worst

z10 EC CP Assist for Cryptographic Functions (CPACF)

050

051

Encryption of data in DB2 and files:

challenges and solutions

Central Key Manager

Application CryptoSolution

Mainframe z/OS DB2

File

CryptoSolutionApplication

File

File

Windows,Unix,Linux,iSeries

…

Field Encryption – Protecting the Data Flow

Encrypt

Decrypt

Application

Fields

Fields

Central Key Manager

Application

File

CryptoSolution

Mainframe z/OS

Utility

DB2

File

CryptoSolution

Application

Database

File

Windows,Unix,Linux,iSeries

…

Transparent Encryption – No Application ChangesEncrypt

Encrypt

Decrypt

Fields

Fields

Fields

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

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

054

Data Protection Options – 3 Use Cases

Application 3

Application 2

Application 1

Can use stored protected value:

1234 1234 1234 4560Or

Kjh3409)(*&@$%^&

Need partial Informationin clear:

1234 1234 1234 4560

Need full Informationin clear:

55 49 9437 0789 4560

055

Token Server

$%.>/$&#

Cipher TextToken

Key Manager

ApplicationDatabases

(CCN, SSN …)

Application 3

Application 2

Application 1

Strong EncryptionKjh3409)(*&@$%^&

Formatted Encryption1234 1234 1234 4560

Token1234 1234 1234 4560

Can use stored protected value:

1234 1234 1234 4560Or

Kjh3409)(*&@$%^&

Need partial Informationin clear:

1234 1234 1234 4560

Need full Informationin clear:

55 49 9437 0789 4560

Token Cipher 056

How will different Protection Options Impact Applications?

Type of Application Strong Encryption


Token

Can operate on the stored protected value

Need partial information in clear

Need full clear text information

057

Application Impact with Different Protection Options

Transparency



Token




Security



Token




058

Application Impact with Different Protection Options

Performance and scalability



Token




Availability

Performance and scalability

059

1. ‘Local SW’

2.‘Local

Hardware’

3. ‘Remote

Hardware or Software (NAE)’

3 Topologies:

Network Attached

Encryption

Key Server

Software Agent. (3rd party)VIEW

RemoteEncryption

(Hardware Chip or Software)

TCP/IP, PCI bus …

Local Software Encryption.

(nativeOr 3rd party)

VIEW

IBM CPACF,Sun T1/T2

…

VIEW

Database Server

Local Hardware Encryption Chip

1microsecond

1microsecond

1000microseconds

http://www.corpwatch.org/img/original/chip.gif


1. ‘UDF SW’

2. ‘UDF NAE’

3. ‘ICSF CCF’

4.‘ICSF CPACF’

5.‘PURE CPACF’

Encryption Solutions:

Network AttachedEncryption (NAE)

UDF

FILE(CKDS, …)

VIEW

IBMCCFEDITPROC

UDFVIEW

ICSF

IBMCPACFEDITPROC

ICSF

CPACF

EDITPROC

FIELDPROC





DB2

‘Solution #1 + #5’

VIEW

EDITPROC

FIELDPROC

EncryptionFunction Data

Space

UDF

SecurityPolicy

&Audit


Throughput for Encryption on IBM z9-109

Data Length(Bytes)

2 000 000 -

100 000 -

CPACF

1M 16

200 -

CPACF + ICSF

Test Sample with 3DES, 1 CPU

Throughput(Transactions Per Second)

Throughput(64 Bytes

Transactions Per Second)

# of CPU’s(PU’s)

2 000 000 -

2

10 000 -

4 8

7 000 000 -

CPACF Based Encryption

NAE/Channel Attached Encryption

Throughput: NAE vs. CPACF on IBM z9-109

Sample data from test cases

General Encryption time for SW vs. HW on z/OS

Microseconds

per decryption

Block length(Bytes)

30 -

3 -

8

1 -

SW

HW

Software encryption is very sensitive to the length of the encrypted block

400 -

256

Hardware encryption is NOT very sensitive to the length of the encrypted block

Test Sample with 3DES, 1 CPU

Throughput for Database Encryption - UNIX

TotalThroughput

Rows per Second

# of Database

Servers

2,000,000 -

1,000,000 -

5,000 -

200,000 - 2nd NetworkAttached

Encryption

1st NetworkAttached

Encryption

Software / Combination

1 10 20


Data Loading (Batch)

1 000 000 –

1 000 000 –

100 000 –

10 000 –

1 000 –Encryption

Topology

Rows Per Second

CPACF

Supported

Platforms

Other Platforms

Queries (Data Warehouse & OLTP)

Column Encryption Performance - Different Topologies

I

Network Attached

Encryption (SW/HW)

I

Local

Encryption (SW/HW)


Generalization: Data Protection Methods - DB2 on zOS

Clear

TextHigh

Low

Separation

of Duties

(Security Level)

Performance

Tokenizing

Column

Encryption

With

DB2

User Defined Functions

Hashing

Lookup Table

Encryption

With

DB2 Editproc

(IBM tool)

Column

Encryption

With

DB2 Fieldproc

(3rd party)


High –

Low –

Separation of Duties

Major Topologies for Database Encryption

LocalEncryption (SW/HW)

Network

Local Call

Database Server

DatabaseServer

EncryptionServer

KeyStore

Network AttachedEncryption (SW/HW)

Network Network

LocalEncryption (SW/HW)

Local Call

Database Server

KeyStore

Native

Database

Encryption

Network

Attached

Encryption

Local

Database

Encryption

Data Loading (Batch)

10 000 000 –

1 000 000 –

100 000 –

10 000 –

1 000 –Encryption

Topology

Rows Per Second

Data Warehouse

Platforms

Mainframe

Platforms

Unix Platforms

Windows Platforms

Queries (Data Warehouse & OLTP)

Column Encryption Performance - Different Topologies

I

Network Attached

Encryption (SW/HW)

I

Local

Encryption (SW/HW)


Mature Enterprise

Solutions

Less mature 3rd

Party

Solutions

ALL MAJOR –

Mainframe –

Teradata –

FEW –

ONE –

Performance

(rows/sec)

Platform Support (Databases & OS)

Mature Enterprise Solutions – Performance & Scalability

I I

1 000 10 000 000

Point Solutions


Case Study

Performance, Scalability

&

Software vs. Hardware

Case Study: Search on Encrypted Column

Database Server

Network

Attached

Encryption

Service

NAE

Database Server

Database Server

Database Server

Database Server

Database Server

Database Server

Database Server

Database Server

Database Server

Network

500 000 Rows

Name


Case Study: Network Attached Encryption

Database Server

Network

Attached

Encryption

Service

NAE

Database Server

Database Server

Database Server

Database Server

Database Server

Database Server

Database Server

Database Server

Network

Response TimeWith NetworkAttachedencryption: 500 Second


Case Study: Protegrity

Database Server

Database Server

Database Server

Database Server

Database Server

Database Server

Database Server

Database Server

Database Server

Encryption

Service

Response TimeWith integratedDatabaseencryption: <25 Second

Response TimeAfter TuningAnd Indexing: 1 Second

Network


Total Throughput for Database Encryption Solutions

TotalThroughput

TPS

# of DatabaseServers

2,000,000 -

1,000,000 -

1,000 -

200,000 - 2nd NetworkAttached

Encryption1st Network

AttachedEncryption

Local Database Encryption Solutions


Example - Implementation

077

A Security Suite

Enterprise Security AdministratorEnterprise Security Administrator Data Protection

System

Policy ManagementPolicy Management

Threat Management System

Key ManagementKey Management

Audit ManagementAudit Management

Database Protector

Application Protector

File Protector

Gateway

Monitor

Encryption

Web ApplicationFirewall

Database(Ora/SQL)

Tape (TD)

XC (API)

Mainframe

Teradata

AS/400

CashRegister

Polling Server

Financial Institutions

A Solution Walkthrough

DB2

Teradata

Archive

Oracle

Head Office

Sensitive DataCollection Points - Shops - Web

Shop Back Office

High Street Store

CCN in file

Shop Back Office

ApplicationsShopDB

CashRegister

Aggregating Platform

Windows – SQL

Loss Prevention

ERP

Data Warehouse

$%&#$%&#$%&# $%&#

$%&#

$%&#

Policy

Security Server$%^& *@K$

$%&#

9#42s7ks##@

PolicyPolicyPolicyPolicyPolicy

Policy

Log

Log Log

Log

Log

Log

Reports

ESA

`

zOS Data Protection

080

OPEN MVS

DB2

Defiance DPS for z/OS Cryptographic Services Manager

DEFIANCE PEP SERVER

EDITPROC FIELDPROCPOLICY DB

POLICY ENFORCE

POLICY SHARED MEMORY

CRYPTO SERVICES/SOFTWARE

CRYPTO HARDWARE

DB2 APPLICATION

CRYPTO FILE UTILITY

APPLICATION

DATA

INPUT DATA

OUTPUT

DATAAPI

DB

DEFIANCE SECURITY MANAGER

HUB CONTROLLER

LOG SERVERMEMBER SOURCE SERVER ADMIN SERVER

A Data Protector for z/OS

Support for Triple DES keys (and AES 128, 192 & 256 depending on which Z hardware is used)

• No Padding also supported

Supports multiple data elements

Supports multiple users

Can share data elements among tables and/or columns within table

Member source server supports flatfile so can use RACF query to build member file

• DPS for z/OS uses ACEE to find RACF userid for policy enforcement

Supports audit log to Protegrity Log Server

Single set of servers per LPAR, but supports multiple DB2 regions and/or multiple policies

Mainframe Deployment OptionsTable (Row) Level:

• Protects data at the table level using DB/2 exit ‘editproc’

• Pros – Transparency, performance • Cons – Audit not as granular, index in clear

text

Column Level:• Protects data at the column level using

‘fieldproc’• Pros – Column level, transparency,

performance • Cons – Applications using ‘range-search’ on

encrypted columns when used as an index, must be character data

Row-Level Encryption Capabilities and Limitations

Major limitation: Indicies are not encrypted

No ROWID column or LOB column in table is allowed

Encrypts/decrypts entire row every time• Can be costly for large row

Decryption happens for every row accessed during SELECT even if data fails WHERE except when WHERE only uses INDEX

Column-level Encryption Using Fieldproc

Can only be specified on short string COLUMNs• CHAR, VARCHAR

Invoked during CREATE TABLE or ALTER TABLE

Encryption invoked during INSERT/DB2 LOAD/UPDATE

Encryption invoked during comparison except LIKE

Invoked before any other exit

Decryption invoked during SELECT/FETCH/LIKE /unload phase of REORG

Not invoked when data is null

Not invoked for global DELETE with no WHERE

Column-level Encyption Capabilities and Limitations

Protects data in indices

If only one or few columns need protection then only those are encrypted

Mutually exclusive with DEFAULT – WITH DEFAULT clause NOT allowed

Cannot be specified on ROWID or LOB column

• Columns with those datatypes allowed in TABLE

Can be added by ALTER TABLE for new columns

• No need for unload, drop table, create table, reload as with EDITPROC

Column-level Encryption

Read FIELDPROC warning about blank comparison in IBM DB2 Admin Guide

For retrieval only invoked when column is needed: so SELECTs that do not use column do not decrypt data

Protegrity

087

Corporate Overview

• Enterprise Data Security Management

• Founded 2001

• 300+ customers

• Market leader in PCI DSS & PII data encryption

• 100% growth in each of last three years

• 11 patents granted, 18 pending

• Global reach

• 60% NA, 30% EMEA, 10% Asia

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 software

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

89

Protegrity and Data Security Management

An integral part of technical and business processSecurity Policy

• Centralized control• Consistent enforcement• Separation of duties• Robust key management

Reporting and Auditing• Organization wide security event reporting• Comprehensive compliance reports• Alerting• Integration with SIM/SEM

Risk-adjusted data protection

090

The Protegrity Suite

Data Protection System (DPS)• Encryption, monitoring, masking, tokenization

• Database, file and application level

Threat Management System (TMS)• Web application firewall

Enterprise Security Administrator (ESA)• Security policy

• Key management

• Alerting, reporting, and auditing

91

Risk Management: Understanding the New Options in Data Protection for DB2 and Files Ulf Mattsson, CTO Protegrity.

Documents

application server online

database server online

web server online data

file server online data

pii data link

documents offline data

points of data concentration

records pos system online