This document discusses next generation tokenization technologies for data protection. It provides background on the speaker, Ulf Mattsson, and discusses challenges with current data security practices. Traditional tokenization approaches like dynamic and pre-generated models are outlined, noting their large data footprints and performance limitations. Next generation tokenization is presented as an improved approach.
08448380779 Call Girls In Civil Lines Women Seeking Men
Next Generation Tokenization for Compliance and Cloud Data Protection
1. Next Generation Tokenization for
Compliance and Cloud Data
Protection
Ulf Mattsson
CTO Protegrity
ulf . mattsson AT protegrity . com
2. Ulf Mattsson
20 years with IBM Development & Global Services
Inventor of 22 patents – Encryption and Tokenization
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
• Cloud Security Alliance (CSA)
• Information Systems Security Association (ISSA)
• Information Systems Audit and Control Association (ISACA)
02
8. The Changing Threat Landscape (Aug, 2010)
Some issues have stayed constant:
1. Threat landscape continues to gain sophistication
2. Attackers will always be a step ahead of the defenders
Different motivation, methods and tools today:
• We're fighting highly organized, well-funded crime syndicates and nations
Move from detective to preventative controls needed:
• Several layers of security to address more significant areas of risks
Source: http://www.csoonline.com/article/602313/the-changing-threat-landscape?page=2
08
9. 2010 Data Breach Investigations Report
Six years, 900+ breaches, and over 900 million
compromised records
The majority of cases have not yet been disclosed and
may never be
Over half of the breaches occurred outside of the U.S.
Online Data is Compromised Most Frequently:
%
Source: 2010 Data Breach Investigations Report, Verizon Business RISK team and USSS
09
10. Threat Action Categories
Compromised records
1. 90 % lost in highly sophisticated attacks
2. Hacking and Malware are more dominant
Source: 2010 Data Breach Investigations Report, Verizon Business RISK team and USSS
010
11. Patching Software vs. Locking Down Data
User
Attacker
Application
Software
Patching Not a
Database Single Intrusion
Exploited
OS File System a Patchable
Vulnerability
Storage
System
Backup
Source: 2010 Data Breach Investigations Report, Verizon Business RISK team and USSS
13. No Confidence in Cloud Security (Oct 2010)
CSO Magazine Survey: Cloud Security Still a
Struggle for Many Companies
A recent article written by Bill Brenner, senior editor at CSO Magazine,
reveals that companies are still a bit scared of putting critical data in the
cloud. Results from the 8th Annual Global Information Security Survey
conducted by CSO, along with CIO and PriceWaterhouseCoopers,
cites: 62% of companies have little to no confidence in their ability to
secure any assets put in the cloud. Also, of the 49% of respondents
who have ventured into cloud computing, 39% have major qualms
about security.
Source, CSO. October, 2010 : http://www.csoonline.com/
013
14. Risks Associated with Cloud Computing
Handing over sensitive data to a
third party
Threat of data breach or loss
Weakening of corporate network
security
Uptime/business continuity
Financial strength of the cloud
computing provider
Inability to customize applications
0 10 20 30 40 50 60 70 %
The evolving role of IT managers and CIOs Findings from the 2010 IBM Global IT Risk Study
014
15. Cloud Computing to Fuel Security Market (Oct 2010)
1. "Concerns about cloud security have grown in the past year”
2. "In 2009, the fear was abstract: a general concern as there is with all new
technologies when they're introduced ...
3. “Today, however, concerns are both more specific and more weighty”
4. “We see organizations placing a lot more scrutiny on cloud providers as to their
controls and security processes; and they are more likely to defer adoption
because of security inadequacies than to go ahead despite them."
5. Opportunities in the cloud for vendors are data security, identity and access
management, cloud governance, application security, and operational security.
http://www.eweek.com/c/a/Security/Forrester-Cloud-Computing-to-Fuel-Security-Market-170677/
015
16. What Amazon AWS’s PCI Compliance Means to You, Dec 7 2010
1. Just because AWS is certified doesn't mean you are. You still need to deploy a PCI compliant
application/service and anything on AWS is still within your assessment scope.
2. The open question? PCI-DSS 2.0 doesn't address multi-tenancy concerns
3. AWS is certified as a service provider doesn't mean all cloud IaaS providers will be
4. You can store PAN data on S3, but it still needs to be encrypted in accordance with PCI-DSS
requirements
5. Amazon doesn't do this for you -- it's something you need to implement yourself; including
key management, rotation, logging, etc.
6. If you deploy a server instance in EC2 it still needs to be assessed by your QSA
7. What this certification really does is eliminate any doubts that you are allowed to deploy an
in-scope PCI system on AWS
8. This is a big deal, but your organization's assessment scope isn't necessarily reduced
9. it might be when you move to something like a tokenization service where you reduce your
handling of PAN data
016 securosis.com
17. Not Enough to Encrypt the Pipe & Files
Attacker
SSL
Encrypted Public
Data Network
(PCI DSS)
Private Network
Application
Clear Text Clear Text Data
Data
Database
Encrypted Data
Data OS File
System At Rest
(PCI DSS) (PCI DSS)
Storage
System
017
18. Data Security Today is a 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
018
20. Current, Planned Use of Enabling Technologies
Strong interest in database encryption, data masking, tokenization
Access controls 1% 91% 5%
Database activity monitoring 18% 47% 16%
Database encryption 30% 35% 10%
Backup / Archive encryption 21% 39% 4%
Data masking 28% 28% 7%
Application-level encryption 7% 29% 7%
Tokenization 22% 23% 13%
Evaluating Current Use Planned Use <12 Months
020
21. Choose Your Defenses – Cost Effective PCI DSS
Firewalls
Encryption/Tokenization for data at rest
Anti-virus & anti-malware solution
Encryption for data in motion
Access governance systems
Identity & access management systems
Correlation or event management systems
Web application firewalls (WAF) WAF
Endpoint encryption solution
Data loss prevention systems (DLP) DLP
Intrusion detection or prevention systems
Database scanning and monitoring (DAM) DAM
ID & credentialing system
Encryption/Tokenization
0 10 20 30 40 50 60 70 80 90 %
Source: 2009 PCI DSS Compliance Survey, Ponemon
Institute
22. PCI DSS - Ways to Render the PAN Unreadable
Two-way cryptography with associated key management
processes
One-way cryptographic hash functions
Index tokens and pads
Truncation (or masking – xxxxxx xxxxxx 6781)
22
23. Evaluating Field Encryption & Tokenization
Intrusiveness
(to Applications and Databases)
Hashing - !@#$%a^///&*B()..,,,gft_+!@4#$2%p^&*
Standard
Encryption
Strong Encryption - !@#$%a^.,mhu7/////&*B()_+!@
Alpha - 123456 aBcdeF 1234
Encoding Tokenizing or
Partial - 123456 777777 1234 Formatted Encryption
Clear Text Data - 123456 123456 1234
Data
I I
Length
Original Longer
23
25. Positioning Different Protection Options
Area Evaluation Criteria Strong Field Formatted Distributed
Encryption Encryption Token
High risk data
Security
Compliance to PCI, NIST
Transparent to applications
Initial Expanded storage size
Cost
Transparent to databases schema
Performance impact when loading data
Long life-cycle data
Unix or Windows mixed with “big iron”
Operational
(EBCDIC)
Cost
Easy re-keying of data in a data flow
Disconnected environments
Distributed environments
Best Worst
25
26. Securing Encryption Keys
User Encryption Key
Administration
An entity that uses a
given key should not
SaaS
be the entity that
stores that key
PaaS
IaaS
Encryption
Keys
Cloud
Source: http://csrc.nist.gov/groups/SNS/cloud-computing/
026
27. Hiding Data in Plain Sight – Data Tokenization
Data Entry
Y&SFD%))S( Tokenization
Server
400000 123456 7899 Data Token
400000 222222 7899
Application
Databases
027
28. Data Tokens
123456 123456 1234 123456 999999 1234 123456 123456 1234
User User User
Tokenization
Tokenization Service
Service
Application
Databases
123456 999999 1234
123456 999999 1234 123456 999999 1234
: Data Token
Unprotected sensitive information:
028
Protected sensitive information
29. Limit Exposure to Sensitive Data
Development Testing Production
Data encoding:
1. Tokenization
Exposure 2. Encryption
to sensitive
data
High -
Low -
I I I I I I I I I
Life
Cycle
Phase
30. PCI Case Study - Large Chain Store
Stores Stores Token
Authorization Servers
Aggregating
Hub for Store
Token
Channel
Servers
Settlement Loss Prevention Analysis - EDW ERP
Settlement
: Integration point
030
31. 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”
031
32. Case Study
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”
032
33. Case Study
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
033
34. What Exactly Makes a “Secure Tokenization” Algorithm?
Ramon Krikken:
Ask vendors what their token-generating algorithms are
Be sure to analyze anything other than strong random
number generators for security.
034
35. Comments on Visa’s Tokenization Best Practices
Visa recommendations should have been simply to
use a random number
You should not write your own 'home-grown' token
servers
035
36. Best Practices for Tokenization *
Unique Sequence
Number
One way Hash Secret per
Irreversible merchant
Function**
Randomly generated
value
*: Published July 14, 2010
**: Multi-use tokens
036
37. Centralized vs. Distributed
Tokenization
Large companies may need to utilize the tokenization
services for locations throughout the world
How do you deliver tokenization to many locations
without the impact of latency?
037
38. Different Approaches for Tokenization
Traditional Tokenization
• Dynamic Model
• Pre-Generated Model
Next Generation Tokenization: Protegrity Tokenization
38
39. Traditional Tokenization: Dynamic Model
Token Encrypted CCN
Dynamic Token Lookup Tables
1667 2815 2678 2890 9920 2556 1678 2267
• Lookup tables are dynamic.
2837 3674 8590 2637 3904 2673 3950 5968
• They grow as more unique tokens are needed.
8473 2673 4890 7825 1234 5672 4098 5589
Example: number of Credit Cards processed
by a merchant.
Application 9473 2678 4567 8902 9940 3789 4457 1234
• Table includes a hash value, a token,
3892 3674 5896 9026 0094 6789 2201 3785 encrypted CCN and other administrative
columns
1234 5678 9012 3456 3789 2001 8943 2289
Application • Large footprint. On the order of tens or
0048 2536 4782 3748 5678 4459 2098 1267 hundreds of millions of CCNs
Application
9937 2456 2738 4665 0093 2678 1298 2678 Performance
9926 1452 8364 3784 9903 2890 3789 4567 • 5 tokens per second (outsourced) to
• 5000 tokens per second (in-house)
0245 3678 5647 3957 2908 2567 1905 3785
39
40. Traditional Tokenization: Pre-generated Model
Token Encrypted SSN Pre-Generated Static Lookup Tables.
667 27 1890 009 38 2908
Assume that all possible combinations are
pre-generated.
039 27 1789 467 28 3905
• Lookup tables are static
567 38 2098 478 39 2096
• Contain all possible combinations. Example:
Application 409 28 1234 456 47 8765 all social security numbers required to support
a healthcare provider’s membership.
489 37 2290 768 56 0987
• Table includes a hash value, a token,
Application 774 36 5578 783 24 9906 encrypted SSN and other administrative
columns
990 37 2289 567 35 2341
• Large footprint. On the order of tens or
774 37 2907 009 48 3890 hundreds of millions of SSNs
Application
558 37 2908 884 56 0098
• Pre-generation may be impractical due to the
sheer size of all combinations (example; credit
667 49 2678 467 28 9036 card)
Performance
• Improved performance by not having to do as
many operations – dynamic tokenization and
encryption.
40
41. Additional Complexity with Additional Tokenization
Token Server Dynamic &
Pre-Generated Model
• Large footprint becomes
larger with the addition of
Application more data categories to
protect.
• Makes tokenizing additional
Application categories of data a major
challenge.
Application
Credit Card Social Passport
Number Security Number
Number
41
42. Performance
Traditional Tokenization
• 5 tokens per second (outsourced)
• 5000 tokens per second (in-house)
Protegrity Tokenization
• 200,000 tokens per second (Protegrity)
• Single commodity server with 10 connections.
• Will grow linearly with additional servers and/or connections
• 9,000,000+ tokenizations per second (Protegrity /Teradata)
42
43. Evaluating Encryption & Tokenization Approaches
Evaluation Criteria Encryption Tokenization
Database Database Centralized Distributed
Area Impact File Column Tokenization Tokenization
Encryption Encryption (old) (new)
Availability
Scalability Latency
CPU Consumption
Data Flow
Protection
Compliance Scoping
Security Key Management
Randomness
Separation of Duties
043 Best Worst
44. Making Data Unreadable – Protection Methods (Pro’s & Con’s)
Evaluating Different Tokenization Method
IO Interface Protection Implementations
System Layer Granularity AES/CBC, Formatted Data Hashing Data
AES/CTR Encryption Tokenization Masking
Column/Field
Application
Record
Column
Database Table
Table Space
OS File IO Block
Storage
IO Block
System
Best Worse
45. Tokenization Server Location
Tokenization Server Location
Evaluation Aspects Mainframe Remote
Area Criteria DB2 Work Separate In-house Out-sourced
Load Address Space
Manager
Availability
Operational Latency
Performance
Separation
Security
PCI DSS Scope
Best Worst
46. Positioning Different Protection Options
Area Evaluation Criteria Strong Formatted Distributed
Encryption Encryption Tokenization
High risk data
Security
Compliance to PCI, NIST
Transparent to applications
Initial Expanded storage size
Cost
Transparent to databases schema
Performance impact when loading data
Long life-cycle data
Unix or Windows mixed with “big iron”
Operational
(EBCDIC)
Cost
Easy re-keying of data in a data flow
Disconnected environments
Distributed environments
Best Worst
46
47. Positioning Different Protection Options
Evaluation Criteria Strong Formatted Tokens
Encryption Encryption
Security & Compliance
Total Cost of Ownership
Use of Encoded Data
Best Worst
47
48. Mapping the Cloud to Compliance – PCI DSS
Cloud Service Models Compliance Model – PCI DSS
1. Install and maintain a firewall configuration to
protect data
2. Do not use vendor-supplied defaults for system
Applications passwords and other security parameters
Data / Meta-data / Content 3. Protect stored data
4. Encrypt transmission of cardholder data and
SaaS – Software as a Service sensitive information across public networks
5. Use and regularly update anti-virus software
6. Develop and maintain secure systems and
Middleware applications
PaaS – Platform as a Service 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
Hardware
10. Track and monitor all access to network resources
IaaS – Infrastructure as a Service and cardholder data
11. Regularly test security systems and processes
12. Maintain a policy that addresses information
security
048 Source: http://csrc.nist.gov/groups/SNS/cloud-computing/
49. 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
049
50. Best Practices - Data Security Management
Policy
File System
Protector Database
Protector
Audit
Log
Application
Protector
Enterprise
Data Security
Administrator
Tokenization Secure
Server Archive
050 : Encryption service
51. Who is Protegrity?
Proven enterprise data protection software leader since the late 90’s.
Business driven by compliance
• PCI (Payment Card Industry)
• PII (Personally Identifiable Information)
• PHI (Protected Health Information) – HIPAA
• State and Foreign Privacy Laws
Servicing many Industries
• Retail, Hospitality, Travel and Transportation
• Financial Services, Insurance, Banking
• Healthcare
• Telecommunications, Media and Entertainment
• Manufacturing and Government
51
52. Tokenization Summary
Traditional Tokenization Protegrity Tokenization
Footprint Large, Expanding. Small, Static.
The large and expanding footprint of Traditional The small static footprint is the enabling factor that
Tokenization is it’s Achilles heal. It is the source of delivers extreme performance, scalability, and expanded
poor performance, scalability, and limitations on its use.
expanded use.
High Complex replication required. No replication required.
Availability, Deploying more than one token server for the Any number of token servers can be deployed without
DR, and purpose of high availability or scalability will require the need for replication or synchronization between the
Distribution complex and expensive replication or servers. This delivers a simple, elegant, yet powerful
synchronization between the servers. solution.
Reliability Prone to collisions. No collisions.
The synchronization and replication required to Protegrity Tokenizations’ lack of need for replication or
support many deployed token servers is prone to synchronization eliminates the potential for collisions .
collisions, a characteristic that severely limits the
usability of traditional tokenization.
Performance, Will adversely impact performance & scalability. Little or no latency. Fastest industry tokenization.
Latency, and The large footprint severely limits the ability to place The small footprint enables the token server to be
Scalability the token server close to the data. The distance placed close to the data to reduce latency. When placed
between the data and the token server creates in-memory, it eliminates latency and delivers the fastest
latency that adversely effects performance and tokenization in the industry.
scalability to the extent that some use cases are not
possible.
Extendibility Practically impossible. Unlimited Tokenization Capability.
Based on all the issues inherent in Traditional Protegrity Tokenization can be used to tokenize many
Tokenization of a single data category, tokenizing data categories with minimal or no impact on footprint
more data categories may be impractical. or performance.
52
53. Please contact me for more information
Ulf Mattsson
Ulf . Mattsson AT protegrity . com