ISSA: Cloud data security


Published on

Data security for cloud

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

ISSA: Cloud data security

  1. 1. Next Generation Tokenization for Compliance and Cloud Data Protection Ulf Mattsson CTO Protegrity ulf . mattsson AT protegrity . com
  2. 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. 3. ISSA Article, Dec 2010
  4. 4. PCI DSS & Visa USA – 10 Years04
  5. 5. ISACA - Articles About Compliance06
  6. 6. Data Breaches07
  7. 7. 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: • Were 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:
  8. 8. 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 USSS09
  9. 9. 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 USSS010
  10. 10. 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 BackupSource: 2010 Data Breach Investigations Report, Verizon Business RISK team and USSS
  11. 11. Cloud Security012
  12. 12. 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 :
  13. 13. 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 Study014
  14. 14. 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 theyre 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.
  15. 15. What Amazon AWS’s PCI Compliance Means to You, Dec 7 20101. Just because AWS is certified doesnt 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 doesnt address multi-tenancy concerns3. AWS is certified as a service provider doesnt mean all cloud IaaS providers will be4. You can store PAN data on S3, but it still needs to be encrypted in accordance with PCI-DSS requirements5. Amazon doesnt do this for you -- its 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 QSA7. What this certification really does is eliminate any doubts that you are allowed to deploy an in-scope PCI system on AWS8. This is a big deal, but your organizations assessment scope isnt necessarily reduced9. it might be when you move to something like a tokenization service where you reduce your handling of PAN data016
  16. 16. 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 System017
  17. 17. 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 data018
  18. 18. Evaluating Options019
  19. 19. 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 Months020
  20. 20. 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 systemsCorrelation or event management systems Web application firewalls (WAF) WAF Endpoint encryption solution Data loss prevention systems (DLP) DLP Intrusion detection or prevention systemsDatabase 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
  21. 21. 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
  22. 22. 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 Longer23
  23. 23. Protecting the Data Flow - Choose Your Defenses
  24. 24. 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 Worst25
  25. 25. 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:
  26. 26. Hiding Data in Plain Sight – Data Tokenization Data Entry Y&SFD%))S( Tokenization Server 400000 123456 7899 Data Token 400000 222222 7899 Application Databases027
  27. 27. Data Tokens 123456 123456 1234 123456 999999 1234 123456 123456 1234 User User User TokenizationTokenization Service Service Application Databases 123456 999999 1234 123456 999999 1234 123456 999999 1234 : Data Token Unprotected sensitive information:028 Protected sensitive information
  28. 28. Limit Exposure to Sensitive Data Development Testing Production Data encoding: 1. Tokenization Exposure 2. Encryptionto sensitive data High - Low - I I I I I I I I I Life Cycle Phase
  29. 29. 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 point030
  30. 30. 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
  31. 31. 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
  32. 32. 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 SLA033
  33. 33. 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
  34. 34. 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 servers035
  35. 35. Best Practices for Tokenization * Unique Sequence Number One way Hash Secret per Irreversible merchant Function** Randomly generated value *: Published July 14, 2010 **: Multi-use tokens036
  36. 36. 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
  37. 37. Different Approaches for Tokenization Traditional Tokenization • Dynamic Model • Pre-Generated Model Next Generation Tokenization: Protegrity Tokenization38
  38. 38. 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 378539
  39. 39. 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
  40. 40. 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 Number41
  41. 41. 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
  42. 42. Evaluating Encryption & Tokenization Approaches Evaluation Criteria Encryption Tokenization Database Database Centralized Distributed Area Impact File Column Tokenization Tokenization Encryption Encryption (old) (new) AvailabilityScalability Latency CPU Consumption Data Flow Protection Compliance Scoping Security Key Management Randomness Separation of Duties043 Best Worst
  43. 43. Making Data Unreadable – Protection Methods (Pro’s & Con’s) Evaluating Different Tokenization Method IO Interface Protection ImplementationsSystem 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
  44. 44. 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
  45. 45. 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 Worst46
  46. 46. Positioning Different Protection Options Evaluation Criteria Strong Formatted Tokens Encryption Encryption Security & Compliance Total Cost of Ownership Use of Encoded Data Best Worst47
  47. 47. 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 security048 Source:
  48. 48. 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 Time049
  49. 49. Best Practices - Data Security Management Policy File System Protector Database Protector Audit Log Application Protector Enterprise Data Security Administrator Tokenization Secure Server Archive050 : Encryption service
  50. 50. 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 Government51
  51. 51. 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
  52. 52. Please contact me for more information Ulf Mattsson Ulf . Mattsson AT protegrity . com