ISSA: Cloud data security
1 like916 views
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.
ISSA: Cloud data security
- 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
- 3. ISSA Article, Dec 2010
- 4. PCI DSS & Visa USA – 10 Years 04
- 6. ISACA - Articles About Compliance 06
- 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
- 19. Evaluating Options 019
- 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
- 24. Protecting the Data Flow - Choose Your Defenses
- 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