isaca los angeles 2010 compliance - ulf mattsson
Post on 19-Oct-2014
696 views
DESCRIPTION
ISACA Los Angeles 2010 Compliance - Ulf MattssonTRANSCRIPT
Myths and Realities of Data Security and Compliance:
The Risk-based Data Protection Solution The Risk-based Data Protection Solution
Ulf Mattsson, CTO, Protegrity
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)
Institute of Electrical and Electronics Engineers (IEEE)
ISACA Articles (NYM)
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
Review real world examples for IBM, Microsoft & Oracle
PIISocial security number
Drivers license number
Private account numbers
Date of birth
PCI & Customer DataCredit & Loyalty cards
Banking/mortgage data
Customer profiles
Prospect information
Health RecordsCompany Data
Protect Sensitive Data
Health RecordsInsurance claims
Medical records
Prescriptions
Billing information
Company DataSalary / bonus
HR data
Corporate secrets
Financial results
Data Protection Challenges
Actual protection is not the challenge
Management of solutions• Key management
• Security policy
• Auditing and reporting
Minimizing impact on business operationsMinimizing impact on business operations• Transparency
• Performance vs. security
Minimizing the cost implications
Maintaining compliance
Implementation Time
Developing a Risk-adjusted Data Protection Plan
Know Your Data
Find Your Data
Understand Your Enemy
Understand the New Options in Data Protection
Deploy DefensesDeploy Defenses
Crunch the Numbers
The Gartner 2010 CyberThreat Landscape
Data Security Remains Important for Most
Source: Forrester, 2009
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
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)
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
Increasing liability and insurance
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
• Contents of notification letter
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 ProtectionDivision 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 compliancecompliance
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
Source: IBM Silicon Valley Lab(2009)
Dataset Comparison – Data Type
Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team
Targeted Threat Growth
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
DatabaseProcess 001
User Access Patient Health Record
PatientHealth
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
DatabaseProcess 001
User Access Patient Health Record
z Write c xxx
User Access PatientHealth Data
Record
Health
Data File
Database Process 0001
Read ? ? PHI002
Database Process 0001
Read ? ? PHI002
Database Process 0001
Write ? ? PHI002
Health DataFile PHI002
DB Native
3rd Party
Not Compliant
Protected
Log
No
Information
On User
or Record
Protected sensitive informationUnprotected sensitive information:
Compliance - How to Control ALL Access to PHI Data
DBA Box
File
Backup (Tape)EncryptedDatabase
Compliant
Database
Administration
Encrypted
Encrypted
Encrypted
Protected sensitive informationUnprotected sensitive information:
Not Compliant
File
Backup (Tape)Clear TextDatabase
Database
Administration
Encrypted
Clear Text
Clear Text
2009 Data Breach Investigations
Top 15 Threat Action Types
2009 Data Breach Investigations Supplemental Report,
Verizon Business RISK team
Top 15 Threat Action Types
Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team
NW
DMZ
TRUSTED
SEGMENT
Serve
r
Inte
rne
t
Load
Balancing
Enterprise
AppsSAN,
NAS,
Tape
Internal
UsersDB Server
TRANSACTIONSEnd-
point
DBA
ATTACK
MALWARE /
TROJAN
Data Level Attacks on the Enterprise Data Flow
NW
Web Apps
Inte
rne
t
Proxy
FW
Proxy
FWNetwork
DevicesServer
Tape
Proxy
FWIDS/
IPS
Wire-
less
OS ADMIN
FILE ATTACK
SQL
INJECTIONMEDIA
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
Address PCI, strategize for the larger security issue
Protecting the Data Flow - Example
Top 6 threat action types - Mitigation
Known usernames
Abuse of resources
Specially crafted SQL statements
Infected systems
Collect usernames and passwords
Encryption ofdata 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 blocking
Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team
and passwords
Monitoring
And blocking
Example of Secure Login – One Time Password
Positioning Different Data Protection Approaches
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
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 – Different Approaches
Choose Your Defenses – Cost Effective PCI
Encryption 74%
WAF 55%
DLP 43%
Source: 2009 PCI DSS Compliance Survey, Ponemon Institute
DLP 43%
DAM 18%
Choose Your Defenses – Cost Effective PCI
Cost
Optimal
Expected Losses
from the RiskCost of Aversion –
Protection of Data
Total Cost
Choose Your Defenses – Find the Balance
Risk
Level
Optimal
Risk
I
Passive
Protection
I
Active
Protection
Evaluation Criteria
Performance
• Impact on operations - end users, data processing windows
Storage
• Impact on data storage requirements
Security & Separation of DutiesSecurity & 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
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
Source: 2009 Protegrity Survey
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
Source: 2009 Protegrity Survey
• ‘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
Archive
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
Key Manager
Format Controlling Encryption (FCE)
Newer Data Protection Options
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
• The new modes are not approved by NIST
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 storageStorage space – does not require expanded storage
Test data – partial protection
Outsourced environments & virtual servers
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
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 dataKey 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
- Performance issues
Data Tokenization
Newer Data Protection Options
Data Tokenization
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)
• Still requires strong encryption to protect the lookup table(s)
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 tasksGreatly 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
Tokenization Users Show Significantly Better Results
A Central Token Solution
Token
Server
Customer Application
Customer Application
Customer Application
A Distributed Token Solution
Customer Application
Token
Server
Customer Application
Customer Application
Token
Server
Customer Application
Token
Server
An Integrated Token Solution
Token Server
Customer Application
Customer Application
Token Server
Customer Application
Customer Application
Evaluating Different Tokenization Implementations
Evaluating Different Tokenization ImplementationsEvaluation Area Hosted/Outsourced On-site/On-premises
Area Criteria Central (old) Distributed Central (old) Distributed Integrated
Operational
Needs
Availability
Scalability
Performance
PricingPer Server
Best Worst
PricingModel Per Transaction
DataTypes
Identifiable - PII
Cardholder - PCI
SecuritySeparation
Compliance Scope
A Central Token Solution vs. A Distributed Token Solution
Dynamic
Random
Token Table
-
-
-
-
-Distributed
Static
Static
Random
Token
Table
Static
Random
Token
TableDistributed
Static
Token Tables
Static
Random
Token
Table
Static
Random
Token
TableCustomer
Application
Customer
Application
Customer
Customer
Application
Central Dynamic
Token Table
Customer
Application
Customer
Application
-
.
.
.
.
.
.
.
.
.
Static
Token Tables
Token TablesApplication
Distributed
Static
Token Tables
Static
Random
Token
Table
Static
Random
Token
TableDistributed
Static
Token Tables
Static
Random
Token
Table
Static
Random
Token
TableCustomer
Application
Customer
Application
An Integrated Token Solution
Distributed
Static
StaticRandomTokenTable
StaticRandomTokenTable
Distributed
Static
Token Tables
StaticRandomTokenTable
StaticRandomTokenTable
Customer
Application
Customer
Application
A Distributed Token Solution
StaticRandomTokenTable
Static
Token Tables
Integrated with Pep-Server
StaticRandomTokenTable
StaticRandomTokenTable
Customer
Application
Customer
Application
Static
Token Tables
Token Tables
Distributed
Static
Token Tables
StaticRandomTokenTable
StaticRandomTokenTable
Distributed
Static
Token Tables
StaticRandomTokenTable
StaticRandomTokenTable
Customer
Application
Customer
Application
StaticRandomTokenTable
Static
Token Tables
Integrated with PepServer
StaticRandomTokenTable
StaticRandomTokenTable
Customer
Application
Customer
Application
Integrated with Pep-Server
Choose Your Defenses – Strengths & Weakness
*
*
Best Worst
* Compliant to PCI DSS 1.2 for making PAN unreadable
*
*
Source: 2009 Protegrity Survey
An Enterprise View of Different Protection Options
Evaluation Criteria Strong
Encryption
Formatted
Encryption
Token
Disconnected environments
Distributed environments
Performance impact when loading data
Transparent to applications
Expanded storage sizeExpanded 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
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 9
Employee Health Record 6
Zip Code 3
Data Protection Implementation Layers
System Layer Performance Transparency Security
Application
Database
File System
Topology Performance Scalability Security
Local Service
Remote Service
Best Worst
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
RACFApplications
DB2
Files
ICSFEncryption
SolutionMainframe
z/OS
Central Key
Manager
DB2 UDB
Informix
System i
Oracle
<
Hardware
Security
Module
Example - Centralized Data Protection Approach
Database Protector
File System Protector PolicyPolicy & Key
Creation
Secure Storage
Secure Distribution
Secure Usage
AuditLog
PolicyPolicy
Secure Archive
EnterpriseData 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 & State Privacy Laws)