ISACA Los Angeles 2010 Compliance - Ulf Mattsson

1. Myths and Realities of Data Security and
Compliance:
The Risk-based Data Protection Solution
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
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. Topics
Review current/evolving data security risks
Explore the methods that enable organizations to achieve the right
balance between cost, performance, usability, compliance
demands and real-world security needs
Develop a risk adjusted methodology for securing data and
evaluating security solutions
Review real world examples: protecting PCI, PII and MNPI
(Material Non-Public Information) data throughout its entire
lifecycle
Other topics?
Q&A
Review real world examples for IBM, Microsoft & Oracle

6. Protect Sensitive Data
PCI & Customer Data PII
Credit & Loyalty cards Social security number
Banking/mortgage data Drivers license number
Customer profiles Private account numbers
Prospect information Date of birth
Company Data Health Records
Salary / bonus Insurance claims
HR data Medical records
Corporate secrets Prescriptions
Financial results Billing information

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

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

9. The Gartner 2010 CyberThreat Landscape

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

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

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

13. Market Drivers for Deeper Data Security
Brand damage
• Staying out of the headlines
• Damage to credibility
Regulatory mandates
• PCI
• Country/Provincial/State Privacy Laws
• Sarbanes-Oxley
• HIPAA
Cost of recovery and fixes - Forrester Research
gives a cost range of $90-$305 per record
Increasing liability and insurance

14. Information Security Breaches
In the U.S., 2005 was the year of the security breach
• Followed by 2006, 2007, 2008 and 2009 . . .
Since 2005, over 1,000 information security breaches
• Choice Point - Card Systems
• Bank of America - Boston Globe
• Lexis Nexis - Veterans Administration
• Heartland Payment Systems - TJX
Over 236 million potentially affected
Over 40 U.S. jurisdictions have security breach notification laws
• California SB 1386 started the trend
New federal breach notification law for health information
Numerous federal bills

15. State Security Breach Notification Laws
Generally, the duty to notify arises when unencrypted computerized
“personal
information” was acquired or accessed by an unauthorized person
“Personal information” is an individual’s name, combined with:
• SSN
• Driver’s license or state ID card number
• Account, credit or debit card number, along with password or access code
But state laws differ:
• Computerized v. paper data
• Definition of PII
• Notification to state agencies
• Notification to CRAs
• Timing of individual notification
• Harm threshold
• Contents of notification letter

16. Federal Breach Notification Law
The HITECH Act has changed the federal breach notification
landscape
• HHS and FTC have promulgated breach notification rules pursuant to
HITECH Act requirements
The HITECH Act requires HIPAA covered entities to:
• notify individuals whose “unsecured protected health information” in
any format has been, or is reasonably believed to have been
“accessed, acquired or disclosed” as a result of a breach
Business associates are responsible for notifying covered
entities of a breach

17. Recent FTC Enforcement Actions
Federal Trade Commission (FTC) enforcement authority:
Section 5 of the FTC Act
Most FTC privacy enforcement actions result from security
breaches
• Card Systems, Petco, ChoicePoint, Tower Records, DSW, Barnes &
Noble.com, BJ’s Wholesale Club, Guess.com Inc., CVS, Caremark,
Genica Corporation
Division of Privacy and Identity Protection
Enforcement trends

18. Costs of Non-Compliance with PCI
Costs of non-compliance can be significant
Card brands fine merchant banks, and costs are
“passed through” to merchants by contract
Possible fines of $5,000 to $25,000 per month for
Level 1 and 2 merchants that have not validated
compliance
In the event of a security breach, possible fines of
up to $500,000 per incident plus associated costs

19. Avoiding Breach Notification
HHS issued guidance on April 17, 2009 setting forth an
exhaustive list of what technologies and methodologies will
render PHI secure.
HHS provided additional guidance on August 24, 2009.
Technologies and Methodologies that will render PHI secure:
• Encryption.
• Destruction.
Nothing else will render your PHI secure.
In most recent guidance, HHS:
• Rejected access controls, such as firewalls, as a method for securing
PHI.

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

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

22. Targeted Threat Growth

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

24. Compliance – How to be Able to Produce Required Reports
Application/Too User X (or DBA)
l
Compliant
Database
User Access Patient Health Record
3rd Party
x Read a xxx No Read
Health
Patient
Record DBA Read b xxx Log
a xxx z Write c xxx
b xxx
c xxx Possible DBA
Not Compliant manipulation
Performance?
Database User Access Patient Health Record
Process 001 Protected
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
Unprotected sensitive information: Protected sensitive information

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

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

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

28. Data Level Attacks on the Enterprise Data Flow
MALWARE / DBA
TROJAN ATTACK
TRUSTED
DMZ SEGMENT TRANSACTIONS
End-
Enterprise Internal
Internet
point Serve Load DB Server
SAN,
r Balancing Apps Users
NAS,
Tape NW
Wire- Proxy IDS/ Proxy Network Proxy
Server
less FW IPS Web Apps FW Devices FW
SQL SNIFFER MEDIA OS ADMIN
INJECTION ATTACK ATTACK FILE ATTACK

29. Addressing Data Protection Challenges
Full mapping of sensitive data flow
• Where is the data
• Where does it need to be
Identify what data is needed for processing in which
applications
• What are the performance SLAs
Understand the impact of changing/removing data
• Will it break legacy systems
Address PCI, strategize for the larger security issue

30. Protecting the Data Flow - Example

31. Top 6 threat action types - Mitigation Token,
Point-to-point Monitoring
encryption (E2EE) And blocking
Encryption of or File protection
data in transit Collect
Token or Infected usernames
Point-to-point systems and passwords
encryption (E2EE)
Monitoring
And blocking
Specially crafted
SQL statements
Abuse of Web Application
resources Firewall
Known usernames
and passwords
Monitoring
And blocking
Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team

32. Example of Secure Login – One Time Password

33. Positioning Different
Data Protection Approaches

34. Data Protection Challenges
Actual protection is not the challenge
Management of solutions
• Key management
• Reporting
• Policy
Minimizing impact on business operations
• Performance v. security
Minimizing impact (and costs)
• Changes to applications
• Impact on downstream systems
Time

35. The Goal: Good, Cost Effective Security
The goal is to deliver a solution that is a balance
between security, cost, and impact on the current
business processes and user community
Security plan - short term, long term, ongoing
How much is ‘good enough’
Security versus compliance
• Good Security = Compliance
• Compliance ≠ Good Security

36. Choose Your Defenses – Different Approaches

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

38. Choose Your Defenses – Cost Effective PCI

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

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

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

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

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

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

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

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

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

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

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

50. Applications are Sensitive to the Data Format
Data Type
Binary (Hash) - No Applications
Bin
Data
Binary (Encryption) - Few Applications
Increased
Alphanum (FCE, Token) - Many Applications intrusiveness:
- Application changes
- Limitations in functionality
Text Numeric (FCE, Token) - Most Applications - Limitations in data search
Data - Performance issues
Numeric (Clear Text) - All Applications
Data
I I Field
Original Longer Length
This is a generalized example

51. Newer Data Protection Options
Data Tokenization

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

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

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

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

56. Tokenization Users Show Significantly Better Results

58. A Central Token Solution
Customer
Application
Token
Server
Customer
Application
Customer
Application

59. A Distributed Token Solution
Customer
Application
Token
Server Customer
Application
Customer
Application
Token
Token
Server Customer
Server Application

60. An Integrated Token Solution
Customer Customer
Application Application
Token Server
Customer Customer
Application Application
Token Server

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

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

63. A Distributed Token An Integrated Token
Solution Solution
Static Customer
Static
Random Application
Static Token
Static Customer Random
Application Static
Token
Random Table
Random
Static Token Random
Table
Token Static Token
Random Table
Table Customer
Random Table
Token Customer Application
Token
Table Application Table
Distributed
Static
Static
Distributed Tables Token Tables
Token
Static Integrated with Pep-Server
Token Tables
Static
Random Static Customer
Static Token
Static Customer Random Application
Random Table
Random Application Static
Token
Static Token
Token Random
Table
Static Token
Random Table
Table
Random Table Customer
Token Customer
Token Application
Table Application
Table
Distributed
Static Static
Distributed Tables
Token Token Tables
Static Integrated with PepServer
Token Tables

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

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

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

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

68. Crunch the Numbers – Conclusion
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

69. Managing encryption keys
across different
platforms

70. Deployment
Applications RACF
ICSF
Encryption Mainframe
DB2 Solution z/OS
Hardware
Security
Module
Files
DB2 UDB
Central Key
Manager
Informix
System i Hardware
Security
Module
Oracle

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

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

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