Myths and Realities of Data Security and
Compliance:
The Risk-based Data Protection Solution
The Risk-based Data Protection Solution
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 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)
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 Review real world examples: protecting PCI, PII and MNPI (Material Non-Public Information) data throughout its entire lifecycle
Other topics? Q&A
PII
Social security number Drivers license number Private account numbers Date of birth
PCI & Customer Data
Credit & Loyalty cards Banking/mortgage data Customer profiles
Prospect information
Health Records
Company Data
Protect Sensitive Data
Health Records
Insurance claims Medical records Prescriptions Billing informationCompany Data
Salary / bonus HR data Corporate secrets Financial resultsData Protection Challenges
Actual protection is not the challenge
Management of solutions
• Key management
• Security policy
• Auditing and reporting
Minimizing impact on business operations
Minimizing impact on business operations
• Transparency
• Performance vs. security
Minimizing the cost implications
Maintaining compliance
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
Deploy Defenses
Data Security Remains Important for Most
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
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:
Market Drivers for Deeper Data Security
Brand damage
• Staying out of the headlines • Damage to credibility
Regulatory mandates
• PCI
• Country/Provincial/State Privacy Laws • Country/Provincial/State Privacy Laws
• Sarbanes-Oxley
• HIPAA
Cost of recovery and fixes - Forrester Research
gives a cost range of $90-$305 per record
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 • 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
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: But state laws differ:
• Computerized v. paper data • Definition of PII
• Notification to state agencies • Notification to CRAs
• Timing of individual notification • Harm threshold
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 “accessed, acquired or disclosed” as a result of a breach
Business associates are responsible for notifying covered entities of a breach
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 O
Division of Privacy and Identity Protection Division of Privacy and Identity Protection Enforcement trends
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
compliance
In the event of a security breach, possible fines of
up to $500,000 per incident plus associated costs
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.
Errors and Omissions Higher
Probability
Lost Backups, In Transit Application User (e.g. SQL Injection)
SQL Users
RECENT ATTACKS
Understand Your Enemy – Probability of Attacks
What is the Probability of Different Attacks on Data?
Application Developer, Valid User for Data
Higher Complexity Network or Application/RAM Sniffer
Valid User for the Server (e.g. Stack Overflow, data sets)
Administrator
Dataset Comparison – Data Type
Data Entry Database Application Authorized/ Un-authorized Users Database ATTACKERS Data System
Choose Your Defenses
MALWARE / TROJAN SQL INJECTION
SNIFFER ATTACK
RECENT ATTACKS Where is data exposed to attacks?
111 - 77 -1013 990 - 23 - 1013 File System Storage (Disk) Database Admin System Admin HW Service People Contractors < Backup (Tape) DATABASE ATTACK FILE ATTACK MEDIA ATTACK < 111 - 77 -1013
Protected sensitive information Unprotected sensitive information:
Not Compliant
User Access Patient Health Record
x Read a xxx
DBA Read b xxx
z Write c xxx
Compliant
Compliance – How to be Able to Produce Required Reports
Database
Database
Process 001 User Access Patient Health Record
Patient Health Record a xxx b xxx c xxx Performance? 3rd Party Possible DBA manipulation Protected No Read Log Application/Too l
User X (or DBA)
OS File
Database
Process 001 User Access Patient Health Record
z Write c xxx
User Access Patient Health Data Record
Health Data File
Database
Process 0001 Read ? ? PHI002
Database
Process 0001 Read ? ? PHI002
Database
Process 0001 Write ? ? PHI002
Health Data File PHI002 DB Native 3rd Party Not Compliant Protected Log No Information On User or Record
Protected sensitive information Unprotected sensitive information:
Compliance - How to Control ALL Access to PHI Data
DBA Box File Backup (Tape) Encrypted Database Compliant Database Administration Encrypted Encrypted EncryptedProtected sensitive information Unprotected sensitive information:
Not Compliant File Backup (Tape) Clear Text Database Database Administration Encrypted Clear Text Clear Text
2009 Data Breach Investigations
Top 15
Threat Action Types
2009 Data Breach Investigations
Supplemental Report,
Top 15 Threat Action Types
NW DMZ TRUSTED SEGMENT Serve r In te rn e t Load Balancing Enterprise Apps SAN, NAS, Tape Internal Users DB Server TRANSACTIONS End-point DBA ATTACK MALWARE / TROJAN
Data Level Attacks on the Enterprise Data Flow
NW Web Apps In te rn e t Proxy FW Proxy FW Network Devices Server Tape Proxy FW IDS/ IPS Wire-less OS ADMIN FILE ATTACK SQL INJECTION MEDIA ATTACK SNIFFER ATTACK
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
Top 6 threat action types - Mitigation
Known usernames Abuse of resources Specially crafted SQL statements Infected systems Collect usernames and passwords Encryption of data in transit Monitoring And blocking Web Application Firewall Token or Point-to-point encryption (E2EE) Token, Point-to-point encryption (E2EE) or File protection Monitoring And blockingSource: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team
and passwords
Monitoring And blocking
Positioning Different
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
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’
How much is ‘good enough’
Security versus compliance
• Good Security = Compliance • Compliance ≠ Good Security
Choose Your Defenses – Cost Effective PCI
Encryption 74%
WAF 55%
DLP 43%
Source: 2009 PCI DSS Compliance Survey, Ponemon Institute
DLP 43%
Cost
Optimal
Expected Losses from the Risk Cost of Aversion –
Protection of Data
Total Cost
Choose Your Defenses – Find the Balance
Risk
Level
Optimal
Risk
I Passive Protection I Active ProtectionEvaluation Criteria
Performance
• Impact on operations - end users, data processing windows
Storage
• Impact on data storage requirements
Security & Separation of Duties
Security & Separation of Duties
• How secure Is the data at rest
• Impact on data access – separation of duties
Transparency
• Changes to application(s)
Passive Database Protection Approaches
Database Protection Approach
Performance Storage Security Transparency Separation of Duties
Web Application Firewall Data Loss Prevention Database Activity
Choose Your Defenses - Operational Impact
Database Activity Monitoring
Database Log Mining
Best Worst
Active Database Protection Approaches
Database Protection Approach
Performance Storage Security Transparency Separation of Duties
Application Protection - API Column Level Encryption; FCE, AES, 3DES
Column Level Replacement;
Choose Your Defenses - Operational Impact
Column Level Replacement; Tokens
Tablespace - Datafile Protection
Best Worst
• ‘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
Point of Sale E-Commerce Branch Office
Choose Your Defenses – Example
Encryption
Aggregation
Operations Collection
-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
Data Token
Operations
Analysis
Application Databases
Choose Your Defenses – New Methods
Key Manager
Format Controlling Encryption
Example of Encrypted format:
111-22-1013
Token Server
Token
Data Tokenization
Example of Token format:
1234 1234 1234 4560
Application Databases
Format Controlling Encryption (FCE)
What Is FCE?
Where did it come from?
• Before 2000 – Different approaches, some are based on block ciphers (AES, 3DES O)
• 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
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 Storage space – does not require expanded storage Test data – partial protection
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)
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
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
Applications are Sensitive to the Data Format
Binary (Hash) Binary (Encryption) Alphanum (FCE, Token)
-Data Type Many Applications Few Applications No Applications Increased intrusiveness: Bin Data Text Data
Alphanum (FCE, Token) Numeric (FCE, Token) Numeric (Clear Text)
-Data Field Length I Original I Longer All Applications Most Applications Many Applications
This is a generalized example
intrusiveness:
- Application changes
- Limitations in functionality
- Limitations in data search
Data Tokenization
Newer Data Protection Options
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?
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)
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 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
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
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.
Tokenization Use Cases
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
A Central Token Solution
Token Server Customer Application Customer Application Customer ApplicationA Distributed Token Solution
Customer Application Token Server Customer Application Customer Application Token Server Customer Application Token ServerAn Integrated Token Solution
Token Server Customer Application Customer Application Token Server Customer Application Customer ApplicationEvaluating Different Tokenization Implementations
Evaluating Different Tokenization Implementations
Evaluation Area Hosted/Outsourced On-site/On-premisesArea Criteria Central (old) Distributed Central (old) Distributed Integrated
Operati onal Needs Availability Scalability Performance Pricing Per Server
Best
Worst
PricingModel Per Transaction Data Types Identifiable - PII Cardholder - PCI Security Separation Compliance Scope
A Central Token Solution vs. A Distributed Token Solution
Dynamic Random Token Table -- Distributed Static Static Random Token Table Static Random Token Table Distributed Static Token Tables Static Random Token Table Static Random Token Table Customer Application Customer Application Customer Customer Application Central Dynamic Token Table Customer Application Customer Application -. . . . . . . . . Static Token Tables Token Tables Application Distributed Static Token Tables Static Random Token Table Static Random Token Table Distributed Static Token Tables Static Random Token Table Static Random Token Table Customer Application Customer ApplicationAn Integrated Token
Solution
Distributed Static Static Random Token Table Static Random Token Table Distributed Static Token Tables Static Random Token Table Static Random Token Table Customer Application Customer ApplicationA Distributed Token
Solution
Static Random Token Table Static Token TablesIntegrated with Pep-Server Static Random Token Table Static Random Token
Table ApplicationCustomer Customer Application Static Token Tables Token Tables Distributed Static Token Tables Static Random Token Table Static Random Token Table Distributed Static Token Tables Static Random Token Table Static Random Token Table Customer Application Customer Application Static Random Token Table Static Token Tables
Integrated with PepServer Static Random Token Table Static Random Token
Table ApplicationCustomer Customer Application Integrated with Pep-Server
Choose Your Defenses – Strengths & Weakness
*
*
Best Worst
* Compliant to PCI DSS 1.2 for making PAN unreadable
*
*
An Enterprise View of Different Protection Options
Evaluation Criteria StrongEncryption Formatted Encryption Token Disconnected environments Distributed environments
Performance impact when loading data Transparent to applications
Expanded storage size 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
Matching Data Protection Solutions with Risk Level
Risk Level Solution
Monitor Monitor, mask, Low Risk (1-5) Data Field Risk Level
Credit Card Number 25
Social Security Number 20
CVV 20
Deploy Defenses
Monitor, mask, access control limits, format control encryption Replacement, strong encryption At Risk (6-15) High Risk (16-25) CVV 20 Customer Name 12 Secret Formula 10 Employee Name 9Employee Health Record 6
Data Protection Implementation Layers
System Layer Performance Transparency Security
Application Database File System
Topology Performance Scalability Security
Local Service Remote Service
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
Crunch the Numbers – Conclusion
a project to reduce the number of places where
sensitive data is stored
Protect the remaining sensitive data with a
comprehensive data protection solution
Managing encryption keys
across different
across different
platforms
Deployment
Hardware Security Module RACF Applications DB2 Files ICSF Encryption Solution Mainframe z/OS Central Key Manager DB2 UDB Informix System i Oracle < Hardware Security ModuleExample - Centralized Data Protection Approach
Database Protector
File System
Protector Policy & Key Policy
Creation Secure Storage Secure Distribution Secure Usage Audit Log Policy Policy Secure Archive Enterprise Data Security Auditing & Reporting Secure Collection Data Security Administrator Application Protector Big Iron Protector
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
Protegrity Value Proposition
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 &Please contact us for more information
Ulf Mattsson Phone – 203 570 6919