© 2011 ISACA. All rights reserved.
Risk Management Practices for PCI DSS 2.0
Ulf Mattsson
CTO Protegrity
ulf.mattsson [at] protegrity.com
© 2011 ISACA. All rights reserved.
Ulf Mattsson
• 20 years with IBM Development & Global Services • Inventor of 22 patents – Encryption and Intrusion
Prevention• Co-founder of Protegrity (Data Security)• Research member of the International Federation for
Information Processing (IFIP) WG 11.3 Data and Application Security
• Member of– PCI Security Standards Council (PCI SSC)– American National Standards Institute (ANSI) X9– Information Systems Audit and Control Association
(ISACA)– Institute of Internal Auditors (IIA)– Information Systems Security Association (ISSA)– Cloud Security Alliance (CSA)
02
© 2011 ISACA. All rights reserved.
ISACA Articles
03
Volume 6, November, 2011
Choosing the Most Appropriate Data Security Solution for an Organization
Ulf Mattsson, CTO, Protegrity
© 2011 ISACA. All rights reserved.
04
© 2011 ISACA. All rights reserved.
Agenda
1. Present trends in data breaches
2. Review data security methods available today
3. Discuss emerging technologies for protecting data
4. Present what tokenization is and how it differs from other data security methods
5. Review case studies on how new technologies can minimize costs and complexities
6. Summary and conclusion
05
© 2011 ISACA. All rights reserved.
Data Breaches
06
© 2011 ISACA. All rights reserved.
The Attacks on Sony Corporation
• Majority of attacks were SQL Injection - not advanced• Data including passwords and personal details were not encrypted• Data stolen
– 77 million names, addresses, passwords – 102 million email addresses, birth dates– 25 million phone numbers and payment cards– 54 Mbyte Sony software code
• 21 uncoordinated attacks during Apr 4 to Jul 6, 2011• 55 class action suits in the US (8/16/2011)• Sony’s stock dropped 30 percent after attacks were disclosed
Source: http://defensesystems.com/articles/2011/07/18/digital-conflict-cyberattacks-economy-security.aspx
07
© 2011 ISACA. All rights reserved.
The Attack on RSA Security
• Attackers stole information relating to the SecurID two-factor authentication technology
• APT malware tied to a network in Shanghai• 60 different types of customized malware to
launch their attacks• Based on a commonly used tool written by a
Chinese hacker 10 years ago
08
© 2011 ISACA. All rights reserved.
The AT&T Breach
• Security vulnerability in a Web site used by iPad customers• Programming tricked the site into divulging e-mail addresses • 100,000 e-mail addresses and iPad identification numbers were exposed • Some examples
• New York Mayor Michael Bloomberg, • FBI, • US Departments of Defense and Justice, • NASA, • Executives from Google, Microsoft, • Amazon, Goldman Sachs, and JP Morgan
9
Source 2010: http://news.cnet.com/8301-27080_3-20007417-245.html#ixzz1Y9IW9a7o
© 2011 ISACA. All rights reserved.
“It is fascinating that the top threat events in both 2010 and 2011 are the same
and involve external agents hacking and installing malware to compromise the confidentiality and integrity of servers.”
Best Source of Incident Data*
Source: 2011 Data Breach Investigations Report, Verizon Business RISK team*: Securiosis
010
© 2011 ISACA. All rights reserved.
Who is Behind Data Breaches*?
Business partners (-10%)
Multiple parties (-18%)
Insiders (-31%)
External agents (+22%)
0 10 20 30 40 50 60 70 80 90100
*: Number of breachesSource: 2011 Data Breach Investigations Report, Verizon Business RISK team and USSS
%
011
© 2011 ISACA. All rights reserved.
Demographics
• Criminals may be making a classic risk vs. reward decision and opting to “play it safe” in light of recent arrests and prosecutions following large-scale intrusions into Financial Services firms.
• Numerous smaller strikes on hotels, restaurants, and retailers represent a lower-risk alternative– Cybercriminals may be taking greater advantage of
that option
012
© 2011 ISACA. All rights reserved.
Compromised Data Types*
Sensitive organizational data
System information
Classified information
Medical records
Bank account data
Intellectual property
Usernames, passwords
Personal information
Payment card data
0 20 40 60 80 100 120%
013
*: Number of recordsSource: 2011 Data Breach Investigations Report, Verizon Business RISK team and USSS
© 2011 ISACA. All rights reserved.
*: Number of breachesSource: 2011 Data Breach Investigations Report, Verizon Business RISK team and USSS
Industry Groups Represented*
Business Services
Healthcare
Media
Transportation
Manufacturing
Tech Services
Government
Financial Services
Retail
Hospitality
0 5 10 15 20 25 30 35 40 45%
014
© 2011 ISACA. All rights reserved.
Breach Discovery Methods*
%
Third party monitoring service
Brag or blackmail by perpetrator
Internal fraud detection
Internal security audit or scan
Reported by employee
Unusual system behavior
Reported by customer/partner effected
Notified by law enforcement
Third party fraud detection
0 5 10 15 20 25 30 35 40 45 50
015
*: Number of breachesSource: 2011 Data Breach Investigations Report, Verizon Business RISK team and USSS
© 2011 ISACA. All rights reserved.
Trend in Number of Breaches*
%
Social (-17%)
Misuse (-31%)
Physical (+14%)
Malware (+11%)
Hacking (+10%)
0 10 20 30 40 50 60
*: Number of breachesSource: 2011 Data Breach Investigations Report, Verizon Business RISK team and USSS
016
© 2011 ISACA. All rights reserved.
How are Records Breached*
%
Social
Misuse
Error
Physical
Malware
Hacking
0 10 20 30 40 50 60 70 80 90 100
017
*: Number of recordsSource: 2011 Data Breach Investigations Report, Verizon Business RISK team and USSS
© 2011 ISACA. All rights reserved.
Most Important Trends in DBIR
018
Source: Securosis comments on 2011 Data Breach Investigations Report, Verizon Business RISK team
• The industrialization of attacks: – There is an industry encompassing many actors, from coders to attackers to
money launderers– They use automated tools and manage themselves and their operations as
businesses – including use of independent contractors
• All forms of attack are up by all threat actors: – APT and IP loss serious issues
• Law enforcement really does catch some of the bad guys: – 1,200 arrests over the past several years by the Secret Service alone.– Many of these bad guys/gals attack small business
© 2011 ISACA. All rights reserved.
Data Security - Catch-22
• We need to protect both data and the business processes that rely on that data
• Enterprises are currently on their own in deciding how to apply emerging technologies for PCI data protection– Data Tokenization - an evolving technology– How to reduce PCI audit scope and exposure to data
019
© 2011 ISACA. All rights reserved.
Protecting the
Data Flow
020
© 2011 ISACA. All rights reserved.
Protecting the Data Flow - Example
Protected sensitive information
Unprotected sensitive information:
: Enforcement point
021
© 2011 ISACA. All rights reserved.
PCI DSS
022
© 2011 ISACA. All rights reserved.
AttackerPublic
Network
OS File System
Database
Storage System
Application
SS
LPrivate Network
Data At Rest
(PCI DSS)
Clear Text Data
EncryptedData
(PCI DSS)
EncryptedData
(PCI DSS)
Clear Text Data
PCI Encryption Rules
023
© 2011 ISACA. All rights reserved.
PCI DSS
Payment Card Industry Data Security Standard (PCI DSS)
The PCI Security Standards Council is an open global forum
American Express, Discover Financial Services, JCB International, MasterCard Worldwide, and Visa Inc
The PCI standard consists of a set of 12 rules
Four ways to render the PAN (credit card number) unreadable Two-way cryptography with associated key management processes Truncation One-way cryptographic hash functions Index tokens and pads
Source: https://www.pcisecuritystandards.org/organization_info/index.php
024
© 2011 ISACA. All rights reserved.
PCI DSS #3 & 4
Protect Cardholder Data • 3.4 Render PAN, at minimum, unreadable anywhere it is
stored by using any of the following approaches:• One-way hashes based on strong cryptography• Truncation• Index tokens and pads (pads must be securely stored)• Strong cryptography with associated key-management processes and procedures
• 4.1 Use strong cryptography to safeguard sensitive cardholder data during transmission over open, public networks.
• Comments – Cost effective compliance• Encrypted PAN is always “in PCI scope”• Tokens can be “out of PCI scope”
025
© 2011 ISACA. All rights reserved.
PCI DSS - Appendix B:
• Compensating controls must satisfy the following criteria:– Meet the intent and rigor of the original PCI DSS requirement.– Provide a similar level of defense as the original PCI DSS requirement, such that the
compensating control sufficiently offsets the risk that the original PCI DSS requirement was designed to defend against.
– Be “above and beyond” other PCI DSS requirements. (Simply being in compliance with other PCI DSS requirements is not a compensating control.)
026
© 2011 ISACA. All rights reserved.
PCI Tokenization Guidelines
027
© 2011 ISACA. All rights reserved.
PCI DSS - Network Segmentation
• Network segmentation of, or isolating (segmenting), the cardholder data environment from the remainder of an entity’s network is not a PCI DSS requirement.
• However, it is strongly recommended as a method that may reduce:– The scope of the PCI DSS assessment– The cost of the PCI DSS assessment– The cost and difficulty of implementing and maintaining PCI DSS
controls– The risk to an organization (reduced by consolidating cardholder
data into fewer, more controlled locations)
028
© 2011 ISACA. All rights reserved.
PCI Mandates Risk Assessment
Source: https://www.pcisecuritystandards.org/organization_info/index.php
029
• PCI 2.0 Requirement 12.1.2 mandates the use of formal risk assessment based on established methodologies
• 12.1.2 Includes an annual process that identifies threats, and
vulnerabilities, and results in a formal risk assessment
– 12.1.2.a Verify that an annual risk assessment process is documented that identifies threats, vulnerabilities, and results in a formal risk assessment
– 12.1.2.b Review risk assessment documentation to verify that the risk assessment process is performed at least annually
• Examples of risk assessment methodologies include but are not limited to OCTAVE, ISO 27005 and NIST SP 800-30
© 2011 ISACA. All rights reserved.
Data Security Methods
030
© 2011 ISACA. All rights reserved.
Advancements in Cryptography
Year Event2010 In-memory Data Tokenization introduced as a fully distributed model
2005
Centralized Data Tokenization introduced with hosted payment service
DTP (Data Type Preserving encryption) used in commercial databases
Attack on SHA-1 announced DES was withdrawn
2001 AES (Advance Encryption Standard) accepted as a FIPS-approved algorithm
1991 PGP (Pretty Good Privacy) was written 1988 IBM AS/400 used tokenization in shadow files1978 RSA algorithm was published 1975 DES (Data Encryption Standard) draft submitted by IBM
1900 BC Cryptography used in Egypt
031
© 2011 ISACA. All rights reserved.
123456 777777 1234
123456 123456 1234
aVdSaH 1F4hJ 1D3a
!@#$%a^///&*B()..,,,gft_+!@4#$2%p^&*Hashing -
Strong Encryption -
Alpha -
Numeric -
Partial -
Clear Text Data -
Intrusiveness (to Applications and Databases)
I
Original
!@#$%a^.,mhu7/////&*B()_+!@
666666 777777 8888Tokenizing or
FormattedEncryption
Data
Length
Sta
ndar
dE
ncry
ptio
n
Intrusiveness of Data FormatsE
ncod
ing
032
© 2011 ISACA. All rights reserved.
Encryption vs. Tokenization
Used Approach Cipher System Code System
Cryptographic algorithms
Cryptographic keys
Code books
Index tokens
Source: McGraw-HILL ENCYPLOPEDIA OF SCIENCE & TECHNOLOGY
TokenizationEncryption
033
© 2011 ISACA. All rights reserved.
Use of Enabling Technologies
47%
35%
39%
28%
29%
23%
16%
10%
7%
7%
13%22%
7%
28%
21%
30%
18%
1% 91% 5%
4%
Access controls
Database activity monitoring
Database encryption
Backup / Archive encryption
Data masking
Application-level encryption
Tokenization
Evaluating Current Use Planned Use <12 Months
034
© 2011 ISACA. All rights reserved.
Use of Enabling Technologies, by Maturity
035
© 2011 ISACA. All rights reserved.
Application Database
Hiding Data in Plain Sight
400000 123456 7899
400000 222222 7899
Y&SFD%))S( Tokenization Server
Data Token
Data Entry
036
© 2011 ISACA. All rights reserved.
Applications & Databases
: Data Token
Reducing the Attack Surface
Protected sensitive information
Unprotected sensitive information:
123456 999999 1234 123456 999999 1234 123456 999999 1234
123456 123456 1234123456 999999 1234123456 123456 1234 123456 999999 1234 123456 999999 1234
037
© 2011 ISACA. All rights reserved.
Fully Distributed Tokenization
Customer Application
TokenServer
Customer Application
Customer Application
Token Server
Customer Application
TokenServer
• How do you deliver tokenization to many locations without the impact of latency?
038
© 2011 ISACA. All rights reserved.
• Multi-Use Tokens• Random Static Lookup Tables
– Remains the same size no matter the number of unique tokens
• Example: 50 million = 2 million tokens
• Performance: 200,000 tokens per second on a commodity standard dual core machine
Application
Application
Application
288910288910288910288910288910
1,000,000 max entries
288910288910288910288910288910
1,000,000 max entries
Application
Random Static Lookup Tables
A Fully Distributed Approach
039
© 2011 ISACA. All rights reserved.
Best Worst
Area ImpactDatabase
File Encryption
DatabaseColumn
Encryption
OldToken
Approach
MemoryToken
Approach
Scalability
Availability
Latency
CPU Consumption
Security
Data Flow Protection
Compliance Scoping
Key Management
Separation of Duties
Evaluating Encryption & Tokenization
040
© 2011 ISACA. All rights reserved.
Evaluation Criteria Strong Field Encryption
Formatted Encryption
Memory TokenApproach
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”
Easy re-keying of data in a data flow
High risk data
Security - compliance to PCI, NIST
Best Worst
Evaluating Encryption & Tokenization
041
© 2011 ISACA. All rights reserved.
Best Practices for Tokenization
Token Generation Token Types
Single Use Token
Multi Use Token
Algorithm and Key Reversible
Known strong algorithm
One way Irreversible Function
Unique Sequence Number
Hash
Randomly generated value
-
Secret per transaction
Secret per merchant
Published July 14, 2010.
042
© 2011 ISACA. All rights reserved.
• Visa recommendations should be simply to use a random number
• The only way to discover PAN data from a real token is a (reverse) lookup in the token server database
• The odds are that if you are saddled with PCI-DSS responsibilities, you will not write your own 'home-grown' token servers
Comments on Best Practices
043
© 2011 ISACA. All rights reserved.
What Makes a “Secure Tokenization” Algorithm?
• Ask vendors what their token-generating algorithms are
• Be sure to analyze anything other than strong random number generators for security.
Secure Tokenization
044
© 2011 ISACA. All rights reserved.
Aggregating Hub for Store
Channel
Loss Prevention
Settlement
Analysis - EDWSettlement ERP
StoresStoresAuthorization
Token Servers
A Retail Scenario
Token Servers
: Integration point
045
© 2011 ISACA. All rights reserved.
Case Study – Simplify Compliance
Case Study - Large Chain Store Uses Tokenization to Simplify PCI Compliance
• By segmenting cardholder data with tokenization, a regional chain of 1,500 local convenience stores is reducing its PCI audit from seven to three months
• “ We planned on 30 days to tokenize our 30 million card numbers. With Protegrity Tokenization, the whole process took about 90 minutes”
046
© 2011 ISACA. All rights reserved.
• Qualified Security Assessors had no issues with the effective segmentation provided by Tokenization
• “With encryption, implementations can spawn dozens of questions”
• “There were no such challenges with tokenization”
047
Case Study – Simplify Compliance
© 2011 ISACA. All rights reserved.
• Faster PCI audit – half that time• Lower maintenance cost – don’t have to apply all 12
requirements of PCI DSS to every system• Better security – able to eliminate several business
processes such as generating daily reports for data requests and access
• Strong performance – rapid processing rate for initial tokenization, sub-second transaction SLA
048
Case Study – Simplify Compliance
© 2011 ISACA. All rights reserved.
Why Tokenization?
Why Tokenization – A Triple Play1. No Masking2. No Encryption3. No Key Management
Why In-memory Tokenization1. Better 2. Faster 3. Lower Cost / TCO
$
049
© 2011 ISACA. All rights reserved.
Risk Management
050
© 2011 ISACA. All rights reserved.
AccessLevel
Risk
Data Tokens
TraditionalAccessControl
IHigh
ILow
High –
Low -
Old and flawed:Minimal access levels so people can only carry out their jobs
New:CreativityHappens
At the edge
Source: InformationWeek Aug 15, 2011
Data Security - Catch-22
051
© 2011 ISACA. All rights reserved.
SystemType
Risk
Data Tokens
Data display Masking
IProduction
ITest / dev
Data Masking vs. Tokenization - Risk
High –
Low -
Data at rest Masking
IIntegration
testing
ITroubletesting
Exposure:Data in clear
before masking
Exposure:Data is only obfuscated
052
© 2011 ISACA. All rights reserved.
RiskLevel
Cost
OptimalRisk
Expected Losses from the Risk
Cost of Aversion – Protection of Data
Total Cost
IPassive
Protection
IActive
Protection
Choose Your Defenses
053
© 2011 ISACA. All rights reserved.
Source: 2009 PCI DSS Compliance Survey, Ponemon Institute
Cost Effective PCI DSS
ID & credentialing system
Database scanning and monitoring (DAM)
Intrusion detection or prevention systems
Data loss prevention systems (DLP)
Endpoint encryption solution
Web application firewalls (WAF)
Correlation or event management systems
Identity & access management systems
Access governance systems
Encryption for data in motion
Anti-virus & anti-malware solution
Encryption/Tokenization for data at rest
Firewalls
0 10 20 30 40 50 60 70 80 90
WAF
DLP
DAM
%Encryption/Tokenization
054
© 2011 ISACA. All rights reserved.
Matching Data Protection with Risk Level
Risk Level Solution
Monitor
Monitor, mask, access control limits, format control encryption
Replacement, strong encryption
Low Risk (1-5)
At Risk (6-15)
High Risk (16-25)
Data Field
Risk Level
Credit Card Number 25Social Security Number 20
CVV 20Customer Name 12Secret Formula 10
Employee Name 9Employee Health Record 6
Zip Code 3
055
© 2011 ISACA. All rights reserved.
10 000 000 -
1 000 000 -
100 000 -
10 000 -
1 000 -
100 -
Transactions per second (16 digits)
I
Format
Preserving
Encryption
Speed of Different Methods
I
Data
Type
Preservation
I
Memory
Data
Tokenization
I
AES CBC
Encryption
Standard
I
Traditional
Data
Tokenization
Encryption
*: Speed will depend on the configuration056
© 2011 ISACA. All rights reserved.
I
Format
Preserving
Encryption
Security Level of Different Methods
I
Data
Type
Preservation
I
Memory
Data
Tokenization
I
AES CBC
Encryption
Standard
I
Traditional
Data
Tokenization
High -
Low -
Security Level
Encryption
057
© 2011 ISACA. All rights reserved.
10 000 000 -
1 000 000 -
100 000 -
10 000 -
1 000 -
100 -
Transactions per second (16 digits)
I
Format
Preserving
Encryption
Speed and Security
I
Data
Type
Preservation
I
Memory
Data
Tokenization
I
AES CBC
Encryption
Standard
I
Traditional
Data
Tokenization
Speed*
Security
- High
- Low
Security
Level
Encryption
*: Speed will depend on the configuration058
© 2011 ISACA. All rights reserved.
Quality of Information (Granularity)
Applications and Data - PCI vs. PII
I
Many
I
Few
PCI
PII
High -
Low - # of
Apps
059
Performanceneed
400000 123456 7899
111111 222222 7899
123- 12-1234
777-77-8888
400000 222222 7899
777-77-1234
© 2011 ISACA. All rights reserved.
Data Security Method
System Layer
Hashing Formatted Encryption
Strong Encryption
DataTokenization
Application
Database Column
Database File
Storage Device
Best Worst
Risk Management Aspects
060
• Different data security methods and algorithms• Enforcement implemented at different system layers
© 2011 ISACA. All rights reserved.
Data Security Method
System Layer
Hashing Formatted Encryption
Strong Encryption
DataTokenization
Application
Database Column
Database File
Storage Device
Best Worst: N/A
061
Risk Management Aspects
• Different methods integrated at different system layers
© 2011 ISACA. All rights reserved.
Cloud Security
062
© 2011 ISACA. All rights reserved.
Risks with Cloud Computing
Dource: The evolving role of IT managers and CIOs Findings from the 2010 IBM Global IT Risk Study
Inability to customize applications
Financial strength of the cloud computing provider
Uptime/business continuity
Weakening of corporate network security
Threat of data breach or loss
Handing over sensitive data to a third party
0 10 20 30 40 50 60 70 %
063
© 2011 ISACA. All rights reserved.
What Amazon’s PCI Compliance Means
• PCI-DSS 2.0 doesn't address multi-tenancy concerns
• You can store PAN data on S3, but it still needs to be encrypted in accordance with PCI-DSS requirements
• Amazon doesn't do this for you -- it's something you need to implement yourself; including key management, rotation, logging, etc.
• If you deploy a server instance in EC2 it still needs to be assessed by your QSA
• What this certification really does is eliminate any doubts that you are allowed to deploy an in-scope PCI system on AWS
• This is a big deal, but your organization's assessment scope isn't necessarily reduced
• It might be when you move to something like a tokenization service where you reduce your handling of PAN data
Source: securosis.com064
© 2011 ISACA. All rights reserved.
Summary
065
© 2011 ISACA. All rights reserved.
Data Protection Challenges
Actual protection is not the challenge Management of solutions
Key management Security policy Auditing, Monitoring and reporting
Minimizing impact on business operations Transparency Performance vs. security
Minimizing the cost implications
Maintaining compliance
Implementation Time
066
© 2011 ISACA. All rights reserved.
Best Practices - Data Security
Database Protector
File System Protector
Policy
AuditLog
Secure Archive
Application Protector
Tokenization Server
EnterpriseData SecurityAdministrator
: Enforcement point
067
© 2011 ISACA. All rights reserved.
Risk Management Practices for PCI DSS 2.0
Ulf Mattsson
CTO Protegrity
ulf.mattsson [at] protegrity.com
Top Related