ISACA National Capital Area Chapter (NCAC) in Washington, DC - Ulf Mattsson

  • 883 views
Uploaded on

ISACA National Capital Area Chapter (NCAC) in Washington, DC - Ulf Mattsson

ISACA National Capital Area Chapter (NCAC) in Washington, DC - Ulf Mattsson

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
883
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
14
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Myths and Realities of Data Security and Compliance: A Risk-based Approach to Data Protection Ulf Mattsson, CTO, Protegrity
  • 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) 2
  • 3. ISACA Articles (NYM) 4
  • 4. Topics Review current/evolving data security risks Review newer data protection methods How to achieve the right balance between cost, performance, usability, compliance demands, and real-world security needs Introduce a process for developing a risk- adjusted data security plan 5
  • 5. The Gartner 2010 CyberThreat Landscape 6
  • 6. Targeted Threat Growth 7
  • 7. 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) 8
  • 8. Top 15 Threat Action Types Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team 9
  • 9. Dataset Comparison – Data Type Source: 2009 Data Breach Investigations Supplemental Report, Verizon Business RISK team 10
  • 10. “Everything should be made as simple as possible, but not simpler”, said Albert Einstein. 11
  • 11. Choose Your Defenses Data Entry 990 - 23 - 1013 Data System Application Database Where is data 111 - 77 - 1013 Exposed to attacks? File System Storage (Disk) Backup (Tape) Unprotected sensitive information: Protected sensitive information 12
  • 12. Choose Your Defenses Where is data exposed to attacks? Data Entry 990 - 23 - 1013 RECENT ATTACKS Data System SNIFFER ATTACK Application SQL INJECTION MALWARE / TROJAN Database 111 - 77 - 1013 DATABASE ATTACK File System FILE ATTACK MEDIA ATTACK Storage (Disk) Backup (Tape) Unprotected sensitive information: Protected sensitive information 13
  • 13. 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 14
  • 14. 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 15
  • 15. 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 16
  • 16. Choose Your Defenses – Different Approaches 17
  • 17. 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 18
  • 18. 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 19
  • 19. Choose Your Defenses – Cost Effective PCI Encryption 74% WAF 55% DLP 43% DAM 18% Source: 2009 PCI DSS Compliance Survey, Ponemon Institute 20
  • 20. Beyond PCI DSS - Best Practices for Card Data – E2EE 21
  • 21. 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 22
  • 22. 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 23
  • 23. 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) 24
  • 24. Old Technology - A Centralized Token Solution Customer Application Token Server Customer Application Customer Application 25
  • 25. 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 26
  • 26. 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 27
  • 27. 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 28
  • 28. New Technology - Distributed Tokenization Customer Application Token Server Customer Application Customer Application Token Token Server Customer Server Application 29
  • 29. 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 30
  • 30. Protecting the Data Flow - Choose Your Defenses 31
  • 31. 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 32
  • 32. 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 33
  • 33. Compliance – How to be Able to Produce Required Reports Application/Tool Database Health Patient Record a xxx b xxx c xxx Database Process 001 OS File Health Data File PHI002 34
  • 34. 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 35
  • 35. 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 36
  • 36. 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 37
  • 37. 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) 38
  • 38. 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 39
  • 39. Please contact us for more information Ulf Mattsson ulf.mattsson@protegrity.com Rose Rieger rose.rieger@protegrity.com 40
  • 40. Newer Data Protection Options Format Controlling Encryption (FCE) 41
  • 41. 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 42
  • 42. 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 43
  • 43. 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 44
  • 44. 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 45
  • 45. Newer Data Protection Options Data Tokenization 46
  • 46. 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) 47
  • 47. 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 48
  • 48. 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 49
  • 49. 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 50
  • 50. 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 51
  • 51. 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 52
  • 52. Choose Your Defenses – Strengths & Weakness * * * Best Worst * Compliant to PCI DSS 1.2 for making PAN unreadable Source: 2009 Protegrity Survey 53
  • 53. 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 54
  • 54. Data Protection Implementation Layers System Layer Performance Transparency Security Application Database File System Topology Performance Scalability Security Local Service Remote Service Best Worst 55
  • 55. Example of Secure Login – One Time Password 56