Risk Management: Understanding the New Options in Data Protection for DB2 and Files Ulf Mattsson,...
-
Upload
cleopatra-nelson -
Category
Documents
-
view
215 -
download
0
Transcript of Risk Management: Understanding the New Options in Data Protection for DB2 and Files Ulf Mattsson,...
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
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
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:
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
Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team
Top 15 Threat Action Types
Protecting the Data Flow - Example
Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team
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
MonitoringAnd blocking
MonitoringAnd blocking
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
Application Databases
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
Application Databases
Example of Encrypted format:
111-22-1013Example of clear text user output:
990-23-1013
Example of clear text user output:
5549 9437 0789 4560
Application Databases
Data Protection Options – Newer Methods
Strong Encryption
Example of Encrypted format:
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
Application Databases
Application Databases
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
Customer Application
Customer Application
Token Server
Customer Application
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…
HardwareSecurity Module
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
HardwareSecurity Module
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
Formatted 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
Type of Application Strong Encryption
Formatted Encryption
Token
Can operate on the stored protected value
Need partial information in clear
Need full clear text information
Security
Type of Application Strong Encryption
Formatted Encryption
Token
Can operate on the stored protected value
Need partial information in clear
Need full clear text information
058
Application Impact with Different Protection Options
Performance and scalability
Type of Application Strong Encryption
Formatted Encryption
Token
Can operate on the stored protected value
Need partial information in clear
Need full clear text information
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
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
Sample data from test cases
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)
Sample data from test cases
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)
Sample data from test cases
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)
Sample data from test cases
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
Sample data from test cases
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
Sample data from test cases
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
Sample data from test cases
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
Sample data from test cases
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
Sample data from test cases
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