ISACA Los Angeles 2010 Compliance - Ulf Mattsson

796 views

Published on

ISACA Los Angeles 2010 Compliance - Ulf Mattsson

  • Be the first to comment

  • Be the first to like this

ISACA Los Angeles 2010 Compliance - Ulf Mattsson

  1. 1. Myths and Realities of Data Security and Compliance: The Risk-based Data Protection Solution 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 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. Topics Review current/evolving data security risks Explore the methods that enable organizations to achieve the right balance between cost, performance, usability, compliance demands and real-world security needs Develop a risk adjusted methodology for securing data and evaluating security solutions Review real world examples: protecting PCI, PII and MNPI (Material Non-Public Information) data throughout its entire lifecycle Other topics? Q&A Review real world examples for IBM, Microsoft & Oracle
  5. 5. Protect Sensitive Data PCI & Customer Data PII Credit & Loyalty cards Social security number Banking/mortgage data Drivers license number Customer profiles Private account numbers Prospect information Date of birth Company Data Health Records Salary / bonus Insurance claims HR data Medical records Corporate secrets Prescriptions Financial results Billing information
  6. 6. 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
  7. 7. 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
  8. 8. The Gartner 2010 CyberThreat Landscape
  9. 9. Data Security Remains Important for Most Source: Forrester, 2009
  10. 10. 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
  11. 11. 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)
  12. 12. Market Drivers for Deeper Data Security Brand damage • Staying out of the headlines • Damage to credibility Regulatory mandates • PCI • Country/Provincial/State Privacy Laws • Sarbanes-Oxley • HIPAA Cost of recovery and fixes - Forrester Research gives a cost range of $90-$305 per record Increasing liability and insurance
  13. 13. Information Security Breaches In the U.S., 2005 was the year of the security breach • Followed by 2006, 2007, 2008 and 2009 . . . Since 2005, over 1,000 information security breaches • Choice Point - Card Systems • Bank of America - Boston Globe • Lexis Nexis - Veterans Administration • Heartland Payment Systems - TJX Over 236 million potentially affected Over 40 U.S. jurisdictions have security breach notification laws • California SB 1386 started the trend New federal breach notification law for health information Numerous federal bills
  14. 14. State Security Breach Notification Laws Generally, the duty to notify arises when unencrypted computerized “personal information” was acquired or accessed by an unauthorized person “Personal information” is an individual’s name, combined with: • SSN • Driver’s license or state ID card number • Account, credit or debit card number, along with password or access code But state laws differ: • Computerized v. paper data • Definition of PII • Notification to state agencies • Notification to CRAs • Timing of individual notification • Harm threshold • Contents of notification letter
  15. 15. Federal Breach Notification Law The HITECH Act has changed the federal breach notification landscape • HHS and FTC have promulgated breach notification rules pursuant to HITECH Act requirements The HITECH Act requires HIPAA covered entities to: • notify individuals whose “unsecured protected health information” in any format has been, or is reasonably believed to have been “accessed, acquired or disclosed” as a result of a breach Business associates are responsible for notifying covered entities of a breach
  16. 16. Recent FTC Enforcement Actions Federal Trade Commission (FTC) enforcement authority: Section 5 of the FTC Act Most FTC privacy enforcement actions result from security breaches • Card Systems, Petco, ChoicePoint, Tower Records, DSW, Barnes & Noble.com, BJ’s Wholesale Club, Guess.com Inc., CVS, Caremark, Genica Corporation Division of Privacy and Identity Protection Enforcement trends
  17. 17. Costs of Non-Compliance with PCI Costs of non-compliance can be significant Card brands fine merchant banks, and costs are “passed through” to merchants by contract Possible fines of $5,000 to $25,000 per month for Level 1 and 2 merchants that have not validated compliance In the event of a security breach, possible fines of up to $500,000 per incident plus associated costs
  18. 18. Avoiding Breach Notification HHS issued guidance on April 17, 2009 setting forth an exhaustive list of what technologies and methodologies will render PHI secure. HHS provided additional guidance on August 24, 2009. Technologies and Methodologies that will render PHI secure: • Encryption. • Destruction. Nothing else will render your PHI secure. In most recent guidance, HHS: • Rejected access controls, such as firewalls, as a method for securing PHI.
  19. 19. 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)
  20. 20. Dataset Comparison – Data Type Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team
  21. 21. Targeted Threat Growth
  22. 22. 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
  23. 23. Compliance – How to be Able to Produce Required Reports Application/Too User X (or DBA) l Compliant Database User Access Patient Health Record 3rd Party x Read a xxx No Read Health Patient Record DBA Read b xxx Log a xxx z Write c xxx b xxx c xxx Possible DBA Not Compliant manipulation Performance? Database User Access Patient Health Record Process 001 Protected 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 Unprotected sensitive information: Protected sensitive information
  24. 24. 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
  25. 25. Top 15 Threat Action Types 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team
  26. 26. Top 15 Threat Action Types Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team
  27. 27. Data Level Attacks on the Enterprise Data Flow MALWARE / DBA TROJAN ATTACK TRUSTED DMZ SEGMENT TRANSACTIONS End- Enterprise Internal Internet point Serve Load DB Server SAN, r Balancing Apps Users NAS, Tape NW Wire- Proxy IDS/ Proxy Network Proxy Server less FW IPS Web Apps FW Devices FW SQL SNIFFER MEDIA OS ADMIN INJECTION ATTACK ATTACK FILE ATTACK
  28. 28. Addressing Data Protection Challenges Full mapping of sensitive data flow • Where is the data • Where does it need to be Identify what data is needed for processing in which applications • What are the performance SLAs Understand the impact of changing/removing data • Will it break legacy systems Address PCI, strategize for the larger security issue
  29. 29. Protecting the Data Flow - Example
  30. 30. Top 6 threat action types - Mitigation Token, Point-to-point Monitoring encryption (E2EE) And blocking Encryption of or File protection data in transit Collect Token or Infected usernames Point-to-point systems and passwords encryption (E2EE) Monitoring And blocking Specially crafted SQL statements Abuse of Web Application resources Firewall Known usernames and passwords Monitoring And blocking Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team
  31. 31. Example of Secure Login – One Time Password
  32. 32. Positioning Different Data Protection Approaches
  33. 33. Data Protection Challenges Actual protection is not the challenge Management of solutions • Key management • Reporting • Policy Minimizing impact on business operations • Performance v. security Minimizing impact (and costs) • Changes to applications • Impact on downstream systems Time
  34. 34. The Goal: Good, Cost Effective Security The goal is to deliver a solution that is a balance between security, cost, and impact on the current business processes and user community Security plan - short term, long term, ongoing How much is ‘good enough’ Security versus compliance • Good Security = Compliance • Compliance ≠ Good Security
  35. 35. Choose Your Defenses – Different Approaches
  36. 36. Choose Your Defenses – Cost Effective PCI Encryption 74% WAF 55% DLP 43% DAM 18% Source: 2009 PCI DSS Compliance Survey, Ponemon Institute
  37. 37. Choose Your Defenses – Cost Effective PCI
  38. 38. 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
  39. 39. 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
  40. 40. 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
  41. 41. 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
  42. 42. 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
  43. 43. 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
  44. 44. Newer Data Protection Options Format Controlling Encryption (FCE)
  45. 45. 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
  46. 46. 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
  47. 47. 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
  48. 48. 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
  49. 49. Applications are Sensitive to the Data Format Data Type Binary (Hash) - No Applications Bin Data Binary (Encryption) - Few Applications Increased Alphanum (FCE, Token) - Many Applications intrusiveness: - Application changes - Limitations in functionality Text Numeric (FCE, Token) - Most Applications - Limitations in data search Data - Performance issues Numeric (Clear Text) - All Applications Data I I Field Original Longer Length This is a generalized example
  50. 50. Newer Data Protection Options Data Tokenization
  51. 51. 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)
  52. 52. 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
  53. 53. 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
  54. 54. 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
  55. 55. Tokenization Users Show Significantly Better Results
  56. 56. A Central Token Solution Customer Application Token Server Customer Application Customer Application
  57. 57. A Distributed Token Solution Customer Application Token Server Customer Application Customer Application Token Token Server Customer Server Application
  58. 58. An Integrated Token Solution Customer Customer Application Application Token Server Customer Customer Application Application Token Server
  59. 59. 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
  60. 60. 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
  61. 61. A Distributed Token An Integrated Token Solution Solution Static Customer Static Random Application Static Token Static Customer Random Application Static Token Random Table Random Static Token Random Table Token Static Token Random Table Table Customer Random Table Token Customer Application Token Table Application Table Distributed Static Static Distributed Tables Token Tables Token Static Integrated with Pep-Server Token Tables Static Random Static Customer Static Token Static Customer Random Application Random Table Random Application Static Token Static Token Token Random Table Static Token Random Table Table Random Table Customer Token Customer Token Application Table Application Table Distributed Static Static Distributed Tables Token Token Tables Static Integrated with PepServer Token Tables
  62. 62. Choose Your Defenses – Strengths & Weakness * * * Best Worst * Compliant to PCI DSS 1.2 for making PAN unreadable Source: 2009 Protegrity Survey
  63. 63. 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
  64. 64. 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
  65. 65. Data Protection Implementation Layers System Layer Performance Transparency Security Application Database File System Topology Performance Scalability Security Local Service Remote Service Best Worst
  66. 66. Crunch the Numbers – Conclusion Risk-adjusted data security plans are cost effective Switching focus to a holistic view rather than security silo methodology Understanding of where data resides usually results in a project to reduce the number of places where sensitive data is stored Protect the remaining sensitive data with a comprehensive data protection solution
  67. 67. Managing encryption keys across different platforms
  68. 68. Deployment Applications RACF ICSF Encryption Mainframe DB2 Solution z/OS Hardware Security Module Files DB2 UDB Central Key Manager Informix System i Hardware Security Module Oracle
  69. 69. 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
  70. 70. 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)
  71. 71. Please contact us for more information Ulf Mattsson Phone – 203 570 6919 Email - ulf.mattsson@protegrity.com

×