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.

ISACA Houston Texas Chapter 2010

928 views

Published on

ISACA Houston Texas Chapter 2010

  • Be the first to comment

  • Be the first to like this

ISACA Houston Texas Chapter 2010

  1. 1. Myths & Realities of Data Security & Compliance Ulf Mattsson, CTO, Protegrity
  2. 2. Ulf Mattsson 20 years with IBM Development, Manufacturing & Services Inventor of 21 patents - Encryption Key Management, Policy Driven Data Encryption, Internal Threat Protection, Data Usage Control and Intrusion Prevention. Received Industry's 2008 Most Valuable Performers (MVP) award together with technology leaders from IBM, Cisco Systems., Ingres, Google and other leading companies. Co-founder of Protegrity (Data Security Management) Received US Green Card of class ‘EB 11 – Individual of Extraordinary Ability’ after endorsement by IBM Research in 2004. Research member of the International Federation for Information Processing (IFIP) WG 11.3 Data and Application Security Member of • American National Standards Institute (ANSI) X9 • Information Systems Audit and Control Association (ISACA) • Information Systems Security Association (ISSA) • Institute of Electrical and Electronics Engineers (IEEE)
  3. 3. ISACA Articles (NYM)
  4. 4. The Gartner 2010 CyberThreat Landscape
  5. 5. Data Security Remains Important for Most Source: Forrester, 2009
  6. 6. 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)
  7. 7. Top 15 Threat Action Types Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team
  8. 8. Targeted Threat Growth
  9. 9. Understand Your Enemy – Probability of Attacks Higher Probability What is the Probability of Different Attacks on Data? Errors and Omissions RECENT Lost Backups, In Transit ATTACKS Application User (e.g. SQL Injection) SQL Users Network or Application/RAM Sniffer Valid User for the Server (e.g. Stack Overflow, data sets) Application Developer, Valid User for Data Administrator Higher Complexity Source: IBM Silicon Valley Lab(2009)
  10. 10. 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
  11. 11. Protecting the Data Flow - Example
  12. 12. Choose Your Defenses – Different Approaches
  13. 13. 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
  14. 14. Choose Your 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
  15. 15. A Distributed and Scalable Tokenization Approach Customer Application Token Server Customer Application Customer Application Token Token Server Customer Server Application
  16. 16. Deploy Defenses Matching Data Protection Solutions with Risk Level Risk Level Solution Data Risk Field Level Low Risk Monitor Credit Card Number 25 (1-5) Social Security Number 20 CVV 20 Monitor, mask, At Risk Customer Name 12 access control (6-15) Secret Formula 10 limits, format Employee Name 9 control encryption Employee Health Record 6 High Risk Replacement, Zip Code 3 (16-25) strong encryption
  17. 17. Choose Your Defenses – Find the Balance Cost Expected Losses Cost of Aversion – Protection of Data from the Risk Total Cost Optimal Risk Risk I I Active Passive Level Protection Protection
  18. 18. Practical Examples of using a Risk Based Approach to Data Security Ulf Mattsson, CTO, Protegrity
  19. 19. Developing a Risk-adjusted Data Protection Plan Know Your Data Find Your Data Understand Your Enemy Understand the New Options in Data Protection Deploy Defenses Crunch the Numbers
  20. 20. Know Your Data – Identify High Risk Data Begin by determining the risk profile of all relevant data collected and stored • Data that is resalable for a profit • Value of the information to your organization • Anticipated cost of its exposure Data Field Risk Level Credit Card Number 25 Social Security Number 20 CVV 20 Customer Name 12 Secret Formula 10 Employee Name 9 Employee Health Record 6 Zip Code 3
  21. 21. Choose Your Defenses – Different Approaches
  22. 22. Choose Your Defenses – Cost Effective PCI Encryption 74% WAF 55% DLP 43% DAM 18% Source: 2009 PCI DSS Compliance Survey, Ponemon Institute
  23. 23. Evaluation Criteria Performance • Impact on operations - end users, data processing windows Storage • Impact on data storage requirements Security & Separation of Duties • How secure Is the data at rest • Impact on data access – separation of duties Transparency • Changes to application(s) • Impact on supporting utilities and processes
  24. 24. Choose Your Defenses - Operational Impact Passive Database Protection Approaches Database Protection Performance Storage Security Transparency Separation Approach of Duties Web Application Firewall Data Loss Prevention Database Activity Monitoring Database Log Mining Best Worst Source: 2009 Protegrity Survey
  25. 25. Choose Your Defenses - Operational Impact Active Database Protection Approaches Database Protection Performance Storage Security Transparency Separation Approach of Duties Application Protection - API Column Level Encryption; FCE, AES, 3DES Column Level Replacement; Tokens Tablespace - Datafile Protection Best Worst Source: 2009 Protegrity Survey
  26. 26. Choose Your 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
  27. 27. Newer Data Protection Options Format Controlling Encryption (FCE)
  28. 28. What Is 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
  29. 29. FCE Selling Points Ease of deployment -- limits the database schema changes that are required. Reduces changes to downstream systems Applicability to data in transit – provides a strict/known data format that can be used for interchange Storage space – does not require expanded storage Test data – partial protection Outsourced environments & virtual servers
  30. 30. 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
  31. 31. FCE Use Cases Suitable for lower risk data Compliance to NIST standard not needed Distributed environments Protection of the data flow Added performance overhead can be accepted Key rollover not needed – transient data Support available for data size, type, etc. Point to point protection if “big iron” mixed with Unix or Windows Possible to modify applications that need full clear text – or database plug-in available
  32. 32. Newer Data Protection Options Data Tokenization
  33. 33. 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)
  34. 34. Tokenization Selling Points Provides an alternative to masking – in production, test and outsourced environments Limits schema changes that are required. Reduces impact on downstream systems Can be optimized to preserve pieces of the actual data in-place – smart tokens Greatly simplifies key management and key rotation tasks Centrally managed, protected – reduced exposure Enables strong separation of duties Renders data out of scope for PCI
  35. 35. 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
  36. 36. Tokenization Use Cases Suitable for high risk data – payment card data When compliance to NIST standard needed Long life-cycle data Key rollover – easy to manage Centralized environments Suitable data size, type, etc. Support for “big iron” mixed with Unix or Windows Possible to modify the few applications that need full clear text – or database plug-in available
  37. 37. A Centralized Tokenization Approach Customer Application Token Server Customer Application Customer Application
  38. 38. A Distributed and Scalable Tokenization Approach Customer Application Token Server Customer Application Customer Application Token Token Server Customer Server Application
  39. 39. 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
  40. 40. Choose Your Defenses – 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 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
  41. 41. Choose Your Defenses – Strengths & Weakness * * * Best Worst * Compliant to PCI DSS 1.2 for making PAN unreadable Source: 2009 Protegrity Survey
  42. 42. An Enterprise View of Different Protection Options Evaluation Criteria Strong Formatted Token Encryption Encryption 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
  43. 43. Deploy Defenses Matching Data Protection Solutions with Risk Level Risk Level Solution Data Risk Field Level Low Risk Monitor Credit Card Number 25 (1-5) Social Security Number 20 CVV 20 Monitor, mask, At Risk Customer Name 12 access control (6-15) Secret Formula 10 limits, format Employee Name 9 control encryption Employee Health Record 6 High Risk Replacement, Zip Code 3 (16-25) strong encryption
  44. 44. Data Protection Implementation Layers System Layer Performance Transparency Security Application Database File System Topology Performance Scalability Security Local Service Remote Service Best Worst
  45. 45. 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
  46. 46. Compliance - How to Control ALL Access to PHI Data DBA Box Database Administration Database Encrypted Encrypted Backup (Tape) Compliant File Encrypted Encrypted Database Administration Database Clear Text Clear Text Backup (Tape) Not Compliant File Encrypted Clear Text Unprotected sensitive information: Protected sensitive information
  47. 47. 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
  48. 48. Example - Centralized Data Protection 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
  49. 49. 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)
  50. 50. Please contact us for more information Ulf Mattsson Phone – 203 570 6919 Email - ulf.mattsson@protegrity.com

×