Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Atlanta ISSA 2010 Enterprise Data Protection Ulf Mattsson


Published on

Atlanta ISSA 2010 Enterprise Data Protection Ulf Mattsson

  • Be the first to comment

  • Be the first to like this

Atlanta ISSA 2010 Enterprise Data Protection Ulf Mattsson

  1. 1. Enterprise Data Protection - Understanding your Options and Strategies Ulf Mattsson, CTO, Protegrity
  2. 2. Ulf Mattsson 20 years with IBM Research, Development & Services Inventor of 21 patents – Distributed Tokenization, Encryption Key Management, Policy Driven Data Encryption, Internal Threat Protection, Data Usage Control and Intrusion Prevention Research member of the International Federation for Information Processing (IFIP) WG 11.3 Data and Application Security Received Industry's 2008 Most Valuable Performers (MVP) award together with technology leaders from IBM, Google, Cisco, Ingres and other leading companies Received US Green Card ‘EB 11 – Individual of Extraordinary Ability’ endorsed by IBM Research Created the Architecture of the Protegrity Database Security Technology Member of • American National Standards Institute (ANSI) X9 • Institute of Electrical and Electronics Engineers (IEEE) • Information Systems Security Association (ISSA) • Information Systems Audit and Control Association (ISACA) 2
  3. 3. This session will review Current/evolving data security risks Different options for data protection strategies for PCI DSS and other regulations • Solutions for protecting enterprise data against advanced attacks from internal and external sources • How to provide a balanced mix of different approaches to protect sensitive information like credit cards across different systems in the enterprise, including tokenization, encryption and hashing Studies on data protection in an enterprise environment • Recommendations for how to balance performance and security, in real- world scenarios, and when to use encryption at the database level, application level and file level 4
  4. 4. The Gartner 2010 CyberThreat Landscape 5
  5. 5. 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: Source: Verizon Business Data Breach Investigations Report (2008 and 2009) 6
  6. 6. Top 15 Threat Action Types Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team 7
  7. 7. Targeted Threat Growth 8
  8. 8. 9
  9. 9. Choose Your Defenses Where is data exposed to attacks? Data Entry ATTACKERS 990 - 23 - 1013 RECENT ATTACKS Data System SNIFFER ATTACK Authorized/ Application SQL INJECTION Un-authorized MALWARE / TROJAN Users Database 111 - 77 - 1013 DATABASE ATTACK Database Admin File System FILE ATTACK System Admin MEDIA ATTACK Storage HW Service People (Disk) Contractors Backup (Tape) Unprotected sensitive information: Protected sensitive information 10
  10. 10. Dataset Comparison – Data Type Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team 11
  11. 11. Data Defenses – New Methods Format Controlling Encryption Example of Encrypted format: Key Manager 111-22-1013 Application Databases Data Tokenization Token Server Example of Token format: 1234 1234 1234 4560 Key Manager Application Token Databases 12
  12. 12. What Is Format Controlling Encryption (FCE)? Where did it come from? • Before 2000 – Different approaches, some are based on block ciphers (AES, 3DES ) • Before 2005 – Used to protect data in transit within enterprises What exactly is it? • 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 13
  13. 13. 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 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 14
  14. 14. 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? • 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) 15
  15. 15. Old Technology - A Centralized Token Solution Customer Application Token Server Customer Application Customer Application 16
  16. 16. Choose Your Defenses – Data Flow Example Point of Sale • ‘Information in the wild’ Collection E-Commerce - Short lifecycle / High risk Branch Office Encryption • Temporary information Aggregation - Short lifecycle / High risk • Operating information - Typically 1 or more year lifecycle Operations -Broad and diverse computing and database environment Central Data Token • Decision making information Analysis - Typically multi-year lifecycle - Homogeneous environment - High volume database analysis • Archive Archive -Typically multi-year lifecycle -Preserving the ability to retrieve the data in the future is important 17
  17. 17. 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 Security vulnerabilities of the tokens themselves – randomness and possibility of collisions Security vulnerabilities typical in in-house developed systems – exposing patterns and attack surfaces 18
  18. 18. An Enterprise View of Different Protection Options Evaluation Criteria Strong Formatted Old Central Encryption Encryption Tokenization 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” (EBCDIC) Easy re-keying of data in a data flow High risk data Security - compliance to PCI, NIST Best Worst 19
  19. 19. Old Technology - A Centralized Token Solution Customer Application Token Server Customer Application Customer Application 20
  20. 20. New Technology - Distributed Tokenization Customer Application Token Server Customer Application Customer Application Token Token Server Customer Server Application 21
  21. 21. A Central Token Solution vs. A Distributed Token Solution Static Random Customer Dynamic Static Static Token Application Random Random Random Static Table Token Table Token Token Random - Table Table Customer Token Customer - Application Table Application - Distributed - Static Customer Distributed - Token Tables Application Static . Token Tables . . Customer . Application . Static . Random Customer Static Static . Customer Token Application Random Random . Application Static Table Token Token . Random Table Table Token Customer Table Application Distributed Static Distributed Central Dynamic Token Tables Static Token Table Token Tables
  22. 22. Evaluating Different Tokenization Implementations Evaluating Different Tokenization Implementations Evaluation Area Hosted/Outsourced On-site/On-premises Area Criteria Central (old) Distributed Central (old) Distributed Integrated Availability Operati onal Scalability Needs Performance Per Server Pricing Model Per Transaction Identifiable - PII Data Types Cardholder - PCI Separation Security Compliance Scope Best Worst 23
  23. 23. Protecting the Data Flow - Choose Your Defenses 24
  24. 24. Choose Your Defenses - Operational Impact Database Protection Performance Storage Availability Transparency Security Approach Monitoring, Blocking, Masking Column Level Formatted Encryption Column Level Strong Encryption Column Level Replacement; Scalable Distributed Tokens Column Level Replacement; Central Tokens Tablespace - Datafile Protection Best Worst 25
  25. 25. Compliance to Legislation - Technical Safeguards HIPAA, HITECH, State Laws, PCI DSS Policy Data •Separation of Duties •Access Control PHI, PII, PAN Database •Data Integrity Admin, •Audit & Reporting Users •Data Transmission Business Associates, Covered Entities Examples of PII/PHI breaches: Express Scripts extortion attempt, Certegy breach and the Countrywide breach 26
  26. 26. Compliance – How to be Able to Produce Required Reports User X (or DBA) Application/Tool Compliant Database User Access Patient Health Record 3rd Party Protected x Read a xxx Patient Health Log Record DBA Read b xxx a xxx z Write c xxx b xxx Possible DBA c xxx Not Compliant manipulation Performance? Database User Access Patient Health Record Process 001 No Read DB Native z Write c xxx Log Not Compliant Health Data Health User Access Patient Record Data File OS File No 3rd Party Database Read ? ? PHI002 Process 0001 Information Health Data Database On User File PHI002 Read ? ? PHI002 Process 0001 or Record Database Write ? ? PHI002 Process 0001 27
  27. 27. 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 • Performance vs. security Minimizing the cost implications Maintaining compliance Implementation Time 28
  28. 28. Protegrity – A Centralized Data Security Approach Secure Secure Database Archive Storage Protector Secure Distribution File System Secure Protector Policy & Key Policy Usage Creation Audit Log Enterprise Data Security Administrator Secure Collection Application Auditing & Protector Reporting Big Iron Protector 29
  29. 29. Protegrity Value Proposition 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. Enables customers to achieve data security compliance (PCI, HIPAA, PEPIDA, SOX and Federal & State Privacy Laws) 30
  30. 30. Protegrity and PCI DSS Build and maintain a secure 1. Install and maintain a firewall configuration to network. 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 5. Use and regularly update anti-virus software management program. 6. Develop and maintain secure systems and applications Implement strong access control 7. Restrict access to data by business need-to-know measures. 8. Assign a unique ID to each person with computer access 9. Restrict physical access to cardholder data Regularly monitor and test 10. Track and monitor all access to network networks. resources and cardholder data 11. Regularly test security systems and processes Maintain an information security 12. Maintain a policy that addresses information policy. security 31
  31. 31. Please contact us for more information Ulf Mattsson Rose Rieger Iain Kerr, President and CEO 203 326 7200 32