IBM Share Conference 2010, Boston, Ulf Mattsson
Upcoming SlideShare
Loading in...5
×
 

IBM Share Conference 2010, Boston, Ulf Mattsson

on

  • 1,747 views

IBM Share Conference 2010, Boston, Ulf Mattsson

IBM Share Conference 2010, Boston, Ulf Mattsson

Statistics

Views

Total Views
1,747
Views on SlideShare
1,746
Embed Views
1

Actions

Likes
1
Downloads
37
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Protegrity Questions From a strict compliance standpoint, what is your view on the requirements regarding storage of tokens within the same RDBMS vs. storing the tokens in a separate and distinct system (e.g. an appliance)? Can you compare and contrast the different ways of delivering tokenization; for example, as a add-on to payment processing services vs. as an in-house enterprise solution for the data center? (Even if you have it externally, you are still responsible for that data) What is your estimate of the size and growth rate of the token marketplace? How many inquiries are you getting about tokenization? Who are the leaders in the token marketplace in your opinion? Is there a Forrester Wave for this?
  • ULF
  • Performance Impact on operations - end users, data processing windows Storage Impact on data storage requirements Security 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
  • ULF
  • These are particular use cases where you should “watch out”. It does not capture ALL of criteria and use cases
  • 53 Lets go back to our Example of Data with different Risk Levels WE can now Pick a Risk Value, and map it to the most Cost-Effective solution from a Risk management Perspective. The key thing to remember here is that one size security solutions are never the best fit. The strongest protection for high risk data will be strong encryption (or tokenization) of individual data fields. . The risk levels here will depend on value of the data, data volumes, the servers, connectivity, physical security, HR aspects, geography, compensating controls and other issues.
  • 39 Source: 2009 PCI DSS Compliance Survey, Ponemon Institute According to the report, only 18% considered database scanning and monitoring highly cost effective for PCI DSS compliance -- ranking 15 out of 18 security technologies surveyed . In fact, almost half (49%) gave DAM a low rating for cost effectiveness in enabling PCI DSS compliance . Database activity monitoring had its roots in inspection of SQL traffic for indications of data loss. However, most database access is through an application path which has its own security mechanisms. The DAM market was hyped well ahead of actual customer requirements and well beyond the track record of early entrants to the space. Security technology needs to evolve into the infrastructure to be effective and efficient. New security concepts are often necessarily layered on existing infrastructures to lessen side-effects on applications while the security technology and administration procedures mature. However, over time selective capabilities such as database activity monitoring should be assimilated into database systems and application designs to improve performance and reduce overhead costs.  
  • This slide includes the original animation.
  • Protection of data from acquisition to deletion Defense in depth

IBM Share Conference 2010, Boston, Ulf Mattsson IBM Share Conference 2010, Boston, Ulf Mattsson Presentation Transcript

  • Beyond PCI – A Cost Effective Approach to Data Protection Ulf Mattsson CTO Protegrity [email_address] August 5, 2010 Session 7192
  • Ulf Mattsson
    • 20 years with IBM Software Development
      • Received US Green Card ‘EB 11 – Individual of Extraordinary Ability’ endorsed by IBM Research
    • Inventor of 21 Patents
      • Encryption Key Management, Policy Driven Data Encryption, Distributed Tokenization and Intrusion Prevention
    • Research member of the International Federation for Information Processing (IFIP) WG 11.3 Data and Application Security
    • Created the Architecture of the Protegrity Database Security Technology
    • Received Industry's 2008 Most Valuable Performers (MVP) award together with technology leaders from IBM, Google, Cisco, Ingres and other leading companies
  • 0
  • 0 September 23, 2009
  • http://www.knowpci.com Source of Information about PCI Research
  • Agenda
    • Review trends in data security threats
    • Present case studies - protecting PCI and PII data
    • Position different data security options
    • Discuss how to protect the entire data flow
    • Present a risk adjusted approach to data security
    • Discuss data security in cloud and test environments
  • Online Data Under Attack – Not Laptops or Backup Slide source: Verizon Business 2008 Data Breach Investigations Report Breaches attributed to insiders are much larger than those caused by outsiders The type of asset compromised most frequently is online data:
  • Source: 2009 Data Breach Investigations Supplemental Report, Verizon Top 15 Threat Action Types % of Records % of Breaches
  • The Gartner 2010 CyberThreat Landscape The danger of advanced persistent threats (APTs) to enterprises.
  • File System Data Entry Database Storage Application Attacks at Different System Layers Backup DATABASE ATTACK MALWARE / TROJAN FILE ATTACK SQL INJECTION MEDIA ATTACK … SNIFFER ATTACK Network Authorized/ Un-authorized Users HW Service Contractors Vendors Database Admin System Admin … “ The perimeter is gone – need for new security approaches”
  • PCI DSS - Payment Card Industry Data Security Standard
    • Applies to all organizations that hold, process, or exchange cardholder information
    • A worldwide information security standard defined by the Payment Card Industry Security Standards Council (formed in 2004)
    • Began as five different programs:
      • Visa Card Information Security Program, MasterCard Site Data Protection, American Express Data Security Operating Policy, Discover Information and Compliance, and the JCB Data Security Program.
    • 12 requirements for compliance, organized into six logically related groups, which are called "control objectives."
  • PCI DSS # 3, 6, 7, 10 & 12 Build and maintain a secure network.
    • Install and maintain a firewall configuration to protect data
    • Do not use vendor-supplied defaults for system passwords and other security parameters
    Protect cardholder data.
    • Protect stored data
    • Encrypt transmission of cardholder data and sensitive information across public networks
    Maintain a vulnerability management program.
    • Use and regularly update anti-virus software
    • Develop and maintain secure systems and applications
    Implement strong access control measures.
    • Restrict access to data by business need-to-know
    • Assign a unique ID to each person with computer access
    • Restrict physical access to cardholder data
    Regularly monitor and test networks.
    • Track and monitor all access to network resources and cardholder data
    • Regularly test security systems and processes
    Maintain an information security policy.
    • Maintain a policy that addresses information security
  • PCI DSS #3 & 4 – Protect Cardholder Data
    • 3.4 Render PAN, at minimum, unreadable anywhere it is stored by using any of the following approaches:
      • One-way hashes based on strong cryptography
      • Truncation
      • Index tokens and pads (pads must be securely stored)
      • Strong cryptography with associated key-management processes and procedures
    • 4.1 Use strong cryptography to safeguard sensitive cardholder data during transmission over open, public networks.
    • Comments – Cost effective compliance
      • Encrypted PAN is always “in PCI scope”
      • Tokens can be “out of PCI scope”
    • ‘ Information in the wild’
      • Short lifecycle / High risk
      • Databases often found at collection points
    • Temporary information
      • Short lifecycle / High risk
      • Use the transition to re-key the locks
    • Operating information
      • Typically 1 or more year lifecycle
      • Broad and diverse computing and
      • database environment
    • Decision making information
      • Typically multi-year lifecycle
      • High volume database analysis
      • Wide internal audience with privileges
    • Archive
      • Typically multi-year lifecycle
      • Preserving the ability to retrieve the
      • data in the future is important
    Aggregation Operations Analysis Archive Point of Sale E-Commerce Branch Office Case Studies – Retail Environments : Encryption service
  • Case Studies – PCI DSS Compliance
    • Case study #1: US Retailer
    • Transparent to exiting applications
    • Protect the flow of sensitive credit card information
      • From thousands of stores, Back office systems and Data warehouse
    • Central key management
    • Ensuring performance on the mainframe
    • Case study #2: US Retailer
    • Protection against advanced attacks
    • Protect the flow of sensitive credit card information
      • From thousands of stores, Back office systems and Data warehouse
    • Central key management
    0
  • Case Study 1: Goal – PCI Compliance & Application Transparency File Encryption: Windows Database Encryption: DB2 (zOS, iSeries), Oracle, SQL Server Applications Retail Store Applications FTP File Decryption Central HQ Location File Encryption: Windows, UNIX, Linux, zOS Credit Card Entry : Encryption service
  • Case Study 2: Goal – Addressing Advanced Attacks & PCI DSS Application Application FTP Database Encryption: DB2, SQL Server File Encryption: Windows, UNIX, zOS Retail Store Central HQ Location Credit Card Entry Application Application Encryption : Encryption service End-to-End-Encryption (E2EE)
  • UDF VIEW CPACF (CCF) EDITPROC ICSF CPACF EDITPROC FIELDPROC
      • Encryption Topologies – Mainframe Example
    : Encryption service * : 20 bytes Local Encryption Remote Encryption TCP/IP UDF VIEW Mainframe (z/OS) DB2 DB2 DB2 DB2 User Defined Function Integrated Cryptographic Services Facility CP Assist for Cryptographic Function Key Server Crypto Server 1 Micro-second* 1 Micro-second* 1000 Micro-seconds* 1 Micro-second*
  • Data Loading (Batch) 1 000 000 – 100 000 - 10 000 – 1 000 – Encryption Topology Rows Decrypted / s (100 bytes) z/OS Hardware Crypto - CPACF (All Operations) Queries (Data Warehouse & OLTP) Column Encryption Performance - Different Topologies I Network Attached Encryption (SW/HW) I Local Encryption (SW/HW)
  • Evaluation of Encryption Options for DB2 on z/OS Best Worst Encryption Interface Performance PCI DSS Security Transparency API UDF DB2 V8 UDF DB2 V9 - Fieldproc Editproc
  • Choose Your Defenses – Newer Data Security Approaches Application Databases Key Manager Format Controlling Encryption Token Server Token Data Tokenization Example of Token format: 1234 1234 1234 4560 Application Databases Key Manager Example of Encrypted format: 111-22- 1013 : Encryption service
  • What Is Formatted Encryption?
    • 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
  • Formatted Encryption - 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
  • 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)
  • 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
      • Imposes significant overhead if token server is remote or outsourced
    • Security
      • Vulnerabilities of the tokens themselves – randomness and possibility of collisions
      • Vulnerabilities typical in in-house developed systems – exposing patterns and attack surfaces
  • New Tokenization Approach - Distributed Servers Security Management Customer Application Token Server Customer Application Customer Application Token Server Customer Application Token Server
  • 200 000 – 100 000 – 10 000 – 1000 – 5 – Tokenization Topology PAN Tokenization (per second) New Distributed Tokenization Approach (per deployed token server) Different Tokenization Approaches - Performance I New Old Centralized Tokenization Approach (enterprise total) I Old Outsourced On-site On-site
  • Evaluating Different Tokenization Solutions Best Worst Evaluating Different Tokenization Implementations Evaluation Area Hosted/Outsourced On-site/On-premises Area Criteria Central (old) Distributed Central (old) Distributed Integrated Operational Needs Availability Scalability Performance Pricing Model Per Server Per Transaction Data Types Identifiable - PII Cardholder - PCI Security Separation Compliance Scope
  • 0 123456 777777 1234 123456 123456 1234 aVdSaH gF4fJh sDla !@#$%a^&*B()_+!@4#$2%p^&* How to not Break the Data Format Hashing - Binary Encryption - Alpha Encoding - Encoding - Partial Encoding - Clear Text - Data Field Length Protection Method !@#$%a^&*B()_+!@ 666666 777777 8888 Tokenizing or Formatted Encryption Length and Type Changed Type Changed CCN / PAN
  • Different Security Options for Data Fields Best Worst Evaluation Criteria Strong Encryption Formatted Encryption New Distributed Tokenization Old Central Tokenization Disconnected environments Distributed environments Performance impact – data loading Transparent to applications Expanded storage size Transparent to database schema Long life-cycle data Unix or Windows &“big iron” Re-keying of data in a data flow High risk data Compliance to PCI, NIST
  • Matching Data Protection Solutions with Risk Level Risk Level Solution Monitor Monitor, mask, access control limits, format control encryption Tokenization, strong encryption Low Risk (1-5) At Risk (6-15) High Risk (16-25) 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
  • Choose Your Defenses – A Balanced Approach Database Server Database Activity Monitoring / Data Loss Prevention Web Application Firewall Database Files Database Log Files Applications Database Columns Database Activity Monitoring
  • Source: 2009 PCI DSS Compliance Survey, Ponemon Institute Cost Effective Technology for PCI DSS Encryption 74% WAF 55% DLP 43% DAM 18%
  • Best Worst Choose Your Defenses – Positioning of Alternatives Database Protection Approach Performance Storage Availability Transparency Security Monitoring, Blocking, Masking Column Level Formatted Encryption Column Level Strong Encryption Distributed Tokenization Central Tokenization Database File Encryption
  • Use Case –Data Protection in Cloud Environments Cloud Environment Data Token Encryption User Security Administrator Encryption Token
  • Use Case – Data Protection in Test/Dev Environments Test Environment Production Environment Security Administrator Data Tokenization Formatted Encryption Masking Encryption Token
  • 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
  • Single Point of Control for Data Encryption
    • Central Manager for:
    • Encryption keys
    • Security policy
    • Reporting
    Hardware Security RACF Applications DB2 z/OS Files ICSF Encryption Solution Mainframe z/OS DB2 LUW Informix System i Other Hardware Security API : Encryption service
  • Summary
      • New threats to data & new regulations
      • New “best practices” for data protection
      • New approaches for data protection
      • Protect the data flow
      • Risk-adjusted approach to data security
    • Centralized key management, policy and reporting
  • Protegrity Data Security Management Database Protector Secure Distribution Audit Log Secure Archive Secure Collection Enterprise Data Security Administrator Broad Platform Support File System Protector Policy Application Protector Tokenization Server
  • Protegrity Corporate Overview
      • Enterprise Data Security Management
      • Founded 1996
      • 300+ customers
      • Market leader in PCI DSS & PII data security
      • 14 patents granted/issued
      • Global reach - 60% NA, 30% EMEA, 10% Asia
  • Beyond PCI – A Cost Effective Approach to Data Protection Ulf Mattsson CTO Protegrity [email_address] August 5, 2010 Session 7192