ISACA Houston Texas Chapter 2010

1. Myths & Realities of Data Security &
Compliance
Ulf Mattsson, CTO, Protegrity

2. 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 endorsement by IBM Research in 2004.
Research member of the International Federation for Information
Processing (IFIP) WG 11.3 Data and Application Security
Member of
• American National Standards Institute (ANSI) X9
• Information Systems Audit and Control Association (ISACA)
• Information Systems Security Association (ISSA)
• Institute of Electrical and Electronics Engineers (IEEE)

3. ISACA Articles (NYM)

5. The Gartner 2010 CyberThreat Landscape

6. Data Security Remains Important for Most
Source: Forrester, 2009

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

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

9. Targeted Threat Growth

10. Understand Your Enemy – Probability of Attacks
Higher
Probability What is the Probability of Different Attacks on Data?
Errors and Omissions
RECENT
Lost Backups, In Transit ATTACKS
Application User
(e.g. SQL Injection)
SQL Users
Network or Application/RAM Sniffer
Valid User for the Server
(e.g. Stack Overflow, data sets)
Application Developer,
Valid User for Data
Administrator
Higher Complexity
Source: IBM Silicon Valley Lab(2009)

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

13. Protecting the Data Flow - Example

14. Choose Your Defenses – Different Approaches

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

16. Choose Your 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

17. A Distributed and Scalable Tokenization Approach
Customer
Application
Token
Server Customer
Application
Customer
Application
Token
Token
Server Customer
Server Application

18. Deploy Defenses
Matching Data Protection Solutions with Risk Level
Risk Level Solution
Data Risk
Field Level Low Risk Monitor
Credit Card Number 25 (1-5)
Social Security Number 20
CVV 20 Monitor, mask,
At Risk
Customer Name 12 access control
(6-15)
Secret Formula 10 limits, format
Employee Name 9 control encryption
Employee Health Record 6
High Risk Replacement,
Zip Code 3
(16-25) strong
encryption

19. Choose Your Defenses – Find the Balance
Cost Expected Losses
Cost of Aversion –
Protection of Data from the Risk
Total Cost
Optimal
Risk
Risk
I I
Active Passive Level
Protection Protection

20. Practical Examples of using a Risk Based
Approach to Data Security
Ulf Mattsson, CTO, Protegrity

21. Developing a Risk-adjusted Data Protection Plan
Know Your Data
Find Your Data
Understand Your Enemy
Understand the New Options in Data Protection
Deploy Defenses
Crunch the Numbers

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

23. Choose Your Defenses – Different Approaches

24. Choose Your Defenses – Cost Effective PCI
Encryption 74%
WAF 55%
DLP 43%
DAM 18%
Source: 2009 PCI DSS Compliance Survey, Ponemon Institute

25. Evaluation Criteria
Performance
• Impact on operations - end users, data processing
windows
Storage
• Impact on data storage requirements
Security & 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

26. Choose Your Defenses - Operational Impact
Passive Database Protection Approaches
Database Protection Performance Storage Security Transparency Separation
Approach of Duties
Web Application Firewall
Data Loss Prevention
Database Activity
Monitoring
Database Log Mining
Best Worst
Source: 2009 Protegrity Survey

27. Choose Your Defenses - Operational Impact
Active Database Protection Approaches
Database Protection Performance Storage Security Transparency Separation
Approach of Duties
Application Protection - API
Column Level Encryption;
FCE, AES, 3DES
Column Level Replacement;
Tokens
Tablespace - Datafile
Protection
Best Worst
Source: 2009 Protegrity Survey

28. Choose Your 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

29. Newer Data Protection Options
Format Controlling
Encryption (FCE)

30. What Is 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

31. FCE Selling Points
Ease of deployment -- limits the database schema changes that
are required.
Reduces changes to downstream systems
Applicability to data in transit – provides a strict/known data
format that can be used for interchange
Storage space – does not require expanded storage
Test data – partial protection
Outsourced environments & virtual servers

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

33. FCE Use Cases
Suitable for lower risk data
Compliance to NIST standard not needed
Distributed environments
Protection of the data flow
Added performance overhead can be accepted
Key rollover not needed – transient data
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

34. Newer Data Protection Options
Data Tokenization

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

36. Tokenization Selling Points
Provides an alternative to masking – in production, test and
outsourced environments
Limits schema changes that are required. Reduces impact on
downstream systems
Can be optimized to preserve pieces of the actual data in-place –
smart tokens
Greatly simplifies key management and key rotation tasks
Centrally managed, protected – reduced exposure
Enables strong separation of duties
Renders data out of scope for PCI

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

38. Tokenization Use Cases
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.
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

39. A Centralized Tokenization Approach
Customer
Application
Token
Server
Customer
Application
Customer
Application

40. A Distributed and Scalable Tokenization Approach
Customer
Application
Token
Server Customer
Application
Customer
Application
Token
Token
Server Customer
Server Application

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

42. Choose Your Defenses – 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
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

43. Choose Your Defenses – Strengths & Weakness
*
*
*
Best Worst
* Compliant to PCI DSS 1.2 for making PAN unreadable
Source: 2009 Protegrity Survey

44. An Enterprise View of Different Protection Options
Evaluation Criteria Strong Formatted Token
Encryption Encryption
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

45. Deploy Defenses
Matching Data Protection Solutions with Risk Level
Risk Level Solution
Data Risk
Field Level Low Risk Monitor
Credit Card Number 25 (1-5)
Social Security Number 20
CVV 20 Monitor, mask,
At Risk
Customer Name 12 access control
(6-15)
Secret Formula 10 limits, format
Employee Name 9 control encryption
Employee Health Record 6
High Risk Replacement,
Zip Code 3
(16-25) strong
encryption

46. Data Protection Implementation Layers
System Layer Performance Transparency Security
Application
Database
File System
Topology Performance Scalability Security
Local Service
Remote Service
Best Worst

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

48. Compliance - How to Control ALL Access to PHI Data
DBA Box
Database
Administration
Database Encrypted Encrypted
Backup (Tape)
Compliant
File Encrypted Encrypted
Database
Administration
Database Clear Text Clear Text
Backup (Tape)
Not Compliant
File Encrypted Clear Text
Unprotected sensitive information: Protected sensitive information

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

50. Example - Centralized Data Protection 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

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

52. Please contact us for more information
Ulf Mattsson
Phone – 203 570 6919
Email - ulf.mattsson@protegrity.com