Atlanta ISSA 2010 Enterprise Data Protection Ulf Mattsson

1. Enterprise Data Protection -
Understanding your Options
and Strategies
Ulf Mattsson, CTO, Protegrity

2. Ulf Mattsson
20 years with IBM Research, Development & Services
Inventor of 21 patents – Distributed Tokenization, Encryption Key
Management, Policy Driven Data Encryption, Internal Threat Protection,
Data Usage Control and Intrusion Prevention
Research member of the International Federation for Information
Processing (IFIP) WG 11.3 Data and Application Security
Received Industry's 2008 Most Valuable Performers (MVP) award
together with technology leaders from IBM, Google, Cisco, Ingres and
other leading companies
Received US Green Card ‘EB 11 – Individual of Extraordinary Ability’
endorsed by IBM Research
Created the Architecture of the Protegrity Database Security Technology
Member of
• American National Standards Institute (ANSI) X9
• Institute of Electrical and Electronics Engineers (IEEE)
• Information Systems Security Association (ISSA)
• Information Systems Audit and Control Association (ISACA)
2

4. This session will review
Current/evolving data security risks
Different options for data protection strategies for PCI DSS and
other regulations
• Solutions for protecting enterprise data against advanced attacks from
internal and external sources
• How to provide a balanced mix of different approaches to protect sensitive
information like credit cards across different systems in the enterprise,
including tokenization, encryption and hashing
Studies on data protection in an enterprise environment
• Recommendations for how to balance performance and security, in real-
world scenarios, and when to use encryption at the database level,
application level and file level
http://www.pciknowledgebase.com/
4

5. The Gartner 2010 CyberThreat Landscape
5

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

7. Top 15 Threat Action Types
Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team
7

8. Targeted Threat Growth
8

9. 9

10. Choose Your Defenses
Where is data exposed to attacks?
Data Entry ATTACKERS
990 - 23 - 1013 RECENT ATTACKS
Data System
SNIFFER ATTACK
Authorized/
Application SQL INJECTION
Un-authorized
MALWARE / TROJAN Users
Database
111 - 77 - 1013 DATABASE ATTACK Database
Admin
File System FILE ATTACK
System Admin
MEDIA ATTACK
Storage HW Service People
(Disk)
Contractors
Backup
(Tape)
Unprotected sensitive information:
Protected sensitive information
10

11. Dataset Comparison – Data Type
Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team
11

12. Data Defenses – New Methods
Format Controlling Encryption
Example of Encrypted format: Key Manager
111-22-1013
Application Databases
Data Tokenization
Token Server
Example of Token format:
1234 1234 1234 4560 Key Manager
Application Token
Databases
12

13. What Is Format Controlling Encryption (FCE)?
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
13

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

15. 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)
15

16. Old Technology - A Centralized Token Solution
Customer
Application
Token
Server
Customer
Application
Customer
Application
16

17. Choose Your Defenses – Data Flow Example
Point of Sale
• ‘Information in the wild’
Collection E-Commerce
- Short lifecycle / High risk
Branch Office
Encryption
• Temporary information
Aggregation - Short lifecycle / High risk
• Operating information
- Typically 1 or more year lifecycle
Operations -Broad and diverse computing and
database environment
Central
Data Token • Decision making information
Analysis - Typically multi-year lifecycle
- Homogeneous environment
- High volume database analysis
• Archive
Archive -Typically multi-year lifecycle
-Preserving the ability to retrieve the
data in the future is important
17

18. 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
Security vulnerabilities of the tokens themselves –
randomness and possibility of collisions
Security vulnerabilities typical in in-house developed systems
– exposing patterns and attack surfaces
18

19. An Enterprise View of Different Protection Options
Evaluation Criteria Strong Formatted Old Central
Encryption Encryption Tokenization
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
Best Worst
19

20. Old Technology - A Centralized Token Solution
Customer
Application
Token
Server
Customer
Application
Customer
Application
20

21. New Technology - Distributed Tokenization
Customer
Application
Token
Server Customer
Application
Customer
Application
Token
Token
Server Customer
Server Application
21

22. A Central Token Solution vs. A Distributed Token Solution
Static
Random Customer
Dynamic Static Static
Token Application
Random Random Random
Static
Table
Token Table Token Token
Random
- Table Table
Customer Token Customer
- Application Table Application
- Distributed
- Static
Customer Distributed
- Token Tables
Application Static
.
Token Tables
.
.
Customer
.
Application
. Static
. Random Customer
Static Static
. Customer Token Application
Random Random
. Application Static
Table
Token Token
. Random
Table Table
Token Customer
Table Application
Distributed
Static
Distributed
Central Dynamic Token Tables
Static
Token Table Token Tables

23. Evaluating Different Tokenization Implementations
Evaluating Different Tokenization Implementations
Evaluation Area Hosted/Outsourced On-site/On-premises
Area Criteria Central (old) Distributed Central (old) Distributed Integrated
Availability
Operati
onal Scalability
Needs
Performance
Per Server
Pricing
Model Per Transaction
Identifiable - PII
Data
Types Cardholder - PCI
Separation
Security
Compliance
Scope
Best Worst
23

24. Protecting the Data Flow - Choose Your Defenses
24

25. Choose Your Defenses - Operational Impact
Database Protection Performance Storage Availability Transparency Security
Approach
Monitoring, Blocking,
Masking
Column Level Formatted
Encryption
Column Level Strong
Encryption
Column Level Replacement;
Scalable Distributed Tokens
Column Level Replacement;
Central Tokens
Tablespace - Datafile
Protection
Best Worst
25

26. Compliance to Legislation - Technical Safeguards
HIPAA, HITECH,
State Laws, PCI DSS
Policy
Data
•Separation of Duties
•Access Control PHI, PII, PAN Database
•Data Integrity Admin,
•Audit & Reporting Users
•Data Transmission
Business Associates,
Covered Entities
Examples of PII/PHI breaches: Express Scripts extortion attempt, Certegy breach and the Countrywide breach
26

27. Compliance – How to be Able to Produce Required Reports
User X (or DBA)
Application/Tool
Compliant
Database
User Access Patient Health Record
3rd Party Protected
x Read a xxx
Patient
Health Log
Record DBA Read b xxx
a xxx z Write c xxx
b xxx
Possible DBA
c xxx Not Compliant manipulation
Performance?
Database User Access Patient Health Record
Process 001 No Read
DB Native z Write c xxx
Log
Not Compliant
Health Data Health
User Access Patient
Record Data File
OS File No
3rd Party Database
Read ? ? PHI002
Process 0001 Information
Health Data Database
On User
File PHI002 Read ? ? PHI002
Process 0001 or Record
Database
Write ? ? PHI002
Process 0001
27

28. 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
• Performance vs. security
Minimizing the cost implications
Maintaining compliance
Implementation Time
28

29. Protegrity – A Centralized Data Security Approach
Secure
Secure Database
Archive
Storage Protector
Secure
Distribution
File System Secure
Protector Policy & Key Policy Usage
Creation
Audit
Log
Enterprise
Data Security
Administrator Secure
Collection
Application
Auditing &
Protector Reporting
Big Iron
Protector
29

30. Protegrity Value Proposition
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.
Enables customers to achieve data security compliance (PCI,
HIPAA, PEPIDA, SOX and Federal & State Privacy Laws)
30

31. Protegrity and PCI DSS
Build and maintain a secure 1. Install and maintain a firewall configuration to
network. 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 5. Use and regularly update anti-virus software
management program. 6. Develop and maintain secure systems and
applications
Implement strong access control 7. Restrict access to data by business need-to-know
measures. 8. Assign a unique ID to each person with computer
access
9. Restrict physical access to cardholder data
Regularly monitor and test 10. Track and monitor all access to network
networks. resources and cardholder data
11. Regularly test security systems and processes
Maintain an information security 12. Maintain a policy that addresses information
policy. security
31

32. Please contact us for more information
Ulf Mattsson
ulf.mattsson@protegrity.com
Rose Rieger
rose.rieger@protegrity.com
Iain Kerr,
President and CEO
203 326 7200
32