ISACA National Capital Area Chapter (NCAC) in Washington, DC - Ulf Mattsson

1. Myths and Realities of Data Security and
Compliance: A Risk-based Approach to
Data Protection
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)
2

4. ISACA Articles (NYM)
4

5. Topics
Review current/evolving data security risks
Review newer data protection methods
How to achieve the right balance between cost,
performance, usability, compliance demands,
and real-world security needs
Introduce a process for developing a risk-
adjusted data security plan
5

6. The Gartner 2010 CyberThreat Landscape
6

7. Targeted Threat Growth
7

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

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

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

11. “Everything should be made as simple as possible,
but not simpler”,
said Albert Einstein.
11

12. Choose Your Defenses
Data Entry
990 - 23 - 1013
Data System
Application
Database Where is data
111 - 77 - 1013 Exposed
to attacks?
File System
Storage
(Disk)
Backup
(Tape)
Unprotected sensitive information:
Protected sensitive information
12

13. Choose Your Defenses
Where is data exposed to attacks?
Data Entry
990 - 23 - 1013 RECENT ATTACKS
Data System
SNIFFER ATTACK
Application SQL INJECTION
MALWARE / TROJAN
Database
111 - 77 - 1013 DATABASE ATTACK
File System FILE ATTACK
MEDIA ATTACK
Storage
(Disk)
Backup
(Tape)
Unprotected sensitive information:
Protected sensitive information
13

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

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

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

17. Choose Your Defenses – Different Approaches
17

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

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

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

21. Beyond PCI DSS - Best Practices for Card Data – E2EE
21

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

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

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

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

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

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

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

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

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

31. Protecting the Data Flow - Choose Your Defenses
31

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

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

34. Compliance – How to be Able to Produce Required Reports
Application/Tool
Database
Health
Patient
Record
a xxx
b xxx
c xxx
Database
Process 001
OS File
Health Data
File PHI002
34

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

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

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

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

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

40. Please contact us for more information
Ulf Mattsson
ulf.mattsson@protegrity.com
Rose Rieger
rose.rieger@protegrity.com
40

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

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

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

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

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

46. Newer Data Protection Options
Data Tokenization
46

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

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

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

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

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

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

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

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

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

56. Example of Secure Login – One Time Password
56