ISACA National Capital Area Chapter (NCAC) in Washington, DC - Ulf Mattsson
Post on 19-Oct-2014
1187 Views
Preview:
DESCRIPTION
Transcript
Myths and Realities of Data Security and Compliance: A Risk-based Approach to Compliance: A Risk-based Approach to
Data Protection
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)
2
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)
ISACA Articles (NYM)
4
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
Topics
5
and real-world security needs
Introduce a process for developing a risk-
adjusted data security plan
The Gartner 2010 CyberThreat Landscape
6
Targeted Threat Growth
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:
8
Source: Verizon Business Data Breach Investigations Report (2008 and 2009)
Top 15 Threat Action Types
9
Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team
Dataset Comparison – Data Type
10
Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team
“Everything should be made as simple as possible,
but not simpler”,
said Albert Einstein.
11
Data Entry
Database
Application
Data System
Choose Your Defenses
Where is data
Exposed111 - 77 - 1013
990 - 23 - 1013
12
File System
Storage
(Disk)
Backup
(Tape)
Exposed
to attacks?
111 - 77 - 1013
Protected sensitive information
Unprotected sensitive information:
Data Entry
Database
Application
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
13
File System
Storage
(Disk)
Backup
(Tape)
DATABASE ATTACK
FILE ATTACK
MEDIA ATTACK
5
111 - 77 - 1013
Protected sensitive information
Unprotected sensitive information:
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
14
File System
Storage
(Disk)
Database
Admin
System Admin
HW Service People
Contractors
5
Backup
(Tape)
DATABASE ATTACK
FILE ATTACK
MEDIA ATTACK
5
111 - 77 - 1013
Protected sensitive information
Unprotected sensitive information:
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
15
Deploy Defenses
Crunch the Numbers
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
16
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
Choose Your Defenses – Different Approaches
17
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
18
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
19
Column Level Replacement;
Tokens
Tablespace - Datafile
Protection
Best Worst
Source: 2009 Protegrity Survey
Choose Your Defenses – Cost Effective PCI
Encryption 74%
WAF 55%
DLP 43%
20
Source: 2009 PCI DSS Compliance Survey, Ponemon Institute
DLP 43%
DAM 18%
Beyond PCI DSS - Best Practices for Card Data – E2EE
21
Application Databases
Data Defenses – New Methods
Key Manager
Format Controlling Encryption
Example of Encrypted format:
111-22-1013
22
Token Server
Token
Data Tokenization
Example of Token format:
1234 1234 1234 4560
Application
Databases
Key Manager
What Is Format Controlling Encryption (FCE)?
Where did it come from?
• Before 2000 – Different approaches, some are based on
block ciphers (AES, 3DES L)
• Before 2005 – Used to protect data in transit within
enterprises
What exactly is it?
23
• 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
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?
24
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)
Old Technology - A Centralized Token Solution
Token
Server
Customer
Application
25
Customer
Application
Customer
Application
• ‘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 – Data Flow Example
Encryption
Aggregation
Operations
Collection
26
-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
Central
Data Token
Operations
Analysis
Archive
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
27
Security vulnerabilities of the tokens themselves –
randomness and possibility of collisions
Security vulnerabilities typical in in-house developed systems
– exposing patterns and attack surfaces
An Enterprise View of Different Protection Options
Evaluation Criteria Strong
Encryption
Formatted
Encryption
Old Central
Tokenization
Disconnected environments
Distributed environments
Performance impact when loading data
Transparent to applications
Expanded storage size
28
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
New Technology - Distributed Tokenization
Customer
Application
Token
Server
Customer
Application
29
Customer
Application
Token
Server
Customer
Application
Token
Server
Evaluating Different Tokenization Implementations
Evaluating Different Tokenization ImplementationsEvaluation Area Hosted/Outsourced On-site/On-premises
Area Criteria Central (old) Distributed Central (old) Distributed Integrated
Operati
onal
Needs
Availability
Scalability
Performance
Pricing
Per Server
30
Best Worst
Pricing
Model Per Transaction
Data
Types
Identifiable - PII
Cardholder - PCI
Security
Separation
Compliance
Scope
Protecting the Data Flow - Choose Your Defenses
31
Database Protection
Approach
Performance Storage Availability Transparency Security
Monitoring, Blocking,
Masking
Column Level Formatted
Encryption
Column Level Strong
Encryption
Column Level Replacement;
Choose Your Defenses - Operational Impact
32
Column Level Replacement;
Scalable Distributed Tokens
Column Level Replacement;
Central Tokens
Tablespace - Datafile
Protection
Best Worst
Database
Admin,
Users
Compliance to Legislation - Technical Safeguards
•Separation of Duties
•Access Control
•Data Integrity
•Audit & Reporting
•Data Transmission
PHI, PII, PAN
Data
Policy
HIPAA, HITECH,
State Laws, PCI DSS
33
•Data Transmission
Business Associates,
Covered Entities
Examples of PII/PHI breaches: Express Scripts extortion attempt, Certegy breach and the Countrywide breach
Compliance – How to be Able to Produce Required Reports
Database
PatientHealth
Record
a xxx
b xxx
Application/Tool
34
OS File
DatabaseProcess 001
c xxx
Health DataFile PHI002
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
DatabaseUser Access Patient Health Record
PatientHealth
Record
a xxx
b xxx
c xxx
Performance?
3rd Party
Possible DBA
manipulation
Protected
Log
Application/ToolUser X (or DBA)
35
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
No Read
Log
No
Information
On User
or Record
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
36
• Transparency
• Performance vs. security
Minimizing the cost implications
Maintaining compliance
Implementation Time
A Centralized Data Security Approach
Database
Protector
File System
Protector PolicyPolicy & Key
Creation
Secure
Storage
Secure
Distribution
Secure
Usage
Audit
Log
PolicyPolicy
Secure
Archive
Enterprise
Data Security
37
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 comprehensive
data security policy, key management, and audit reporting.
Protegrity Value Proposition
38
data security policy, key management, and audit reporting.
Enables customers to achieve data security compliance (PCI, HIPAA, PEPIDA, SOX and Federal & State Privacy Laws)
Protegrity and PCI DSS
Build and maintain a secure
network.
1. Install and maintain a firewall configuration to
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
management program.
5. Use and regularly update anti-virus software
6. Develop and maintain secure systems and
39
applications
Implement strong access control
measures.
7. Restrict access to data by business need-to-know
8. Assign a unique ID to each person with computer
access
9. Restrict physical access to cardholder data
Regularly monitor and test
networks.
10. Track and monitor all access to network
resources and cardholder data
11. Regularly test security systems and processes
Maintain an information security
policy.
12. Maintain a policy that addresses information
security
40
Please contact us for more information
Ulf Mattsson
ulf.mattsson@protegrity.com
Rose Riegerrose.rieger@protegrity.com
Format Controlling
Newer Data Protection Options
41
Format Controlling
Encryption (FCE)
What Is FCE?
Where did it come from?
• Before 2000 – Different approaches, some are based on
block ciphers (AES, 3DES L)
• Before 2005 – Used to protect data in transit within
enterprises
What exactly is it?
42
• 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 storage
43
Storage 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
44
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 data
45
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
Data Tokenization
Newer Data Protection Options
46
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?
47
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 tasks
48
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
49
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
50
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 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
51
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
Evaluating Different Tokenization Implementations
Evaluating Different Tokenization ImplementationsEvaluation Area Hosted/Outsourced On-site/On-premises
Area Criteria Central (old) Distributed Central (old) Distributed Integrated
Operati
onal
Needs
Availability
Scalability
Performance
Pricing
Per Server
52
Best Worst
Pricing
Model Per Transaction
Data
Types
Identifiable - PII
Cardholder - PCI
Security
Separation
Compliance
Scope
Choose Your Defenses – Strengths & Weakness
*
*
53
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 size
54
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
Data Protection Implementation Layers
System Layer Performance Transparency Security
Application
Database
File System
55
Topology Performance Scalability Security
Local Service
Remote Service
Best Worst
Example of Secure Login – One Time Password
56
top related