• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
ISSA Boston - PCI and Beyond: A Cost Effective Approach to Data Protection
 

ISSA Boston - PCI and Beyond: A Cost Effective Approach to Data Protection

on

  • 1,213 views

PCI and Beyond: A Cost Effective Approach to Data Protection, ISSA New England Chapter, Ulf Mattsson, Oct 20, 2009.

PCI and Beyond: A Cost Effective Approach to Data Protection, ISSA New England Chapter, Ulf Mattsson, Oct 20, 2009.

Statistics

Views

Total Views
1,213
Views on SlideShare
1,209
Embed Views
4

Actions

Likes
0
Downloads
16
Comments
0

2 Embeds 4

http://www.linkedin.com 3
http://www.slideshare.net 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

    ISSA Boston - PCI and Beyond: A Cost Effective Approach to Data Protection ISSA Boston - PCI and Beyond: A Cost Effective Approach to Data Protection Presentation Transcript

    • 01
      Ulf Mattsson
      Chief Technology Officer
      Protegrity Corporation
      Ulf . mattsson at protegrity . com
    • 02
    • Source of Information about PCI Research
      http://www.knowpci.com
    • PCI Requirements and Data Protection Options
      Advanced Attacks on Cardholder Data
      PCI Requirements
      Data Protection Options
      Data Protection Use Cases
      A Risks Adjusted Data Protection Approach
      Appendix: PCI Research and Resources
    • Enterprise Data Flow – Cardholder Data
      • ‘Information in the wild’
      - Short lifecycle / High risk
      Collection
      POS
      Branch
      e-commerce
      • Temporary information
      - Short lifecycle / High risk
      Aggregation
      • Operating information
      - Typically 1 or more year lifecycle
      - Broad and diverse computing and database environment
      Operations
      • Decision making information
      - Typically multi-year lifecycle
      - Homogeneous computing environment
      - High volume database analysis
      Analysis
      • Archive
      -Typically multi-year lifecycle
      -Preserving the ability to retrieve the data in the future is important
      Archive
    • 06
    • Data Level Attacks on the Enterprise Data Flow
      MALWARE /
      TROJAN
      DBA
      ATTACK
      TRUSTED
      SEGMENT
      DMZ
      TRANSACTIONS
      End-
      point
      Internal
      Users
      Enterprise
      Apps
      DB Server
      Server
      Load
      Balancing
      SAN,
      NAS,
      Tape
      Internet
      NW
      Proxy
      FW
      Proxy
      FW
      Proxy
      FW
      IDS/
      IPS
      Wire-
      less
      Network
      Devices
      Server
      Web Apps
      OS ADMIN
      FILE ATTACK
      SQL
      INJECTION
      SNIFFER
      ATTACK
      MEDIA
      ATTACK
      07
    • 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
      8
    • 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
    • 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
      010
    • PCI DSS 1.2 Applicability Information & PII Aspects
      11
    • Discussion of Data Protection for PCI DSS
      12
    • PCI – Compensating Controls
      13
    • Data Protection Layers
      Data Protection - Wrapping
      How sensitive data is rendered unreadable
      Data Access Control - Path
      How the data is presented to the end user and/or application
      014
    • Data Protection Options
      Data Stored As
      Clear – actual value is readable
      Hash – unreadable, not reversible
      Encrypted – unreadable, reversible, binary/text
      Replacement value (tokens) – unreadable, reversible
      Partial encryption/replacement – unreadable, reversible
      015
    • Data in the Clear
      Control the Access Path
      Reporting and alerting
      Display masking
      Data usage control
      Advantages
      Low impact on existing applications
      Performance
      Time to deploy
      Considerations
      Underlying data exposed
      Discover breach after the fact
      PCI aspects
      016
    • Hash
      Non – reversible
      Strong protection if …
      Keyed hash (HMAC) or salt
      Advantages
      None really for PCI and PII data
      Considerations
      Size and type
      Transparency
      Key rotation for keyed hash
      017
    • Traditional Strong Encryption
      Industry Standard
      Algorithms & modes - AES CBC, 3DES CBC …
      Approved by NIST (National Institute of Standards and Technology)
      Advantages
      Widely deployed
      Compatibility
      Performance
      Considerations
      Storage and type
      Transparency to applications
      Key rotation
      018
    • Newer Data Protection Options
      Format Controlling Encryption (FCE)
    • FCE Security Model
      Example of Formatted Encryption
      1234 1234 1234 4560
      Application Databases
      (e.g. Marketing, Loss Prevention, POS)
      Original Credit Card Number
      Key Manager
    • 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
    • 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
    • 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
    • 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
    • 025
      Applications are Sensitive to the Data Format
      Data Type
      Binary (Hash) -
      Binary (Encryption) -
      Alphanum (FCE, Token) -
      Numeric (FCE, Token) -
      Numeric (Clear Text) -
      No Applications
      Bin
      Data
      Few Applications
      Increased intrusiveness:
      • Application changes
      • Limitations in functionality
      • Limitations in data search
      • Performance issues
      Many Applications
      Most Applications
      Text
      Data
      All Applications
      Data
      Field
      Length
      I
      Original
      I
      Longer
      This is a generalized example
    • Newer Data Protection Options
      Tokenization
    • Original Credit Card Number
      Example of Token format:
      1234 1234 1234 4560
      $%.>/$&#
      Cipher
      Text
      Application
      Databases
      (e.g. Marketing,
      Loss Prevention, POS)
      Token
      Key Manager
      Token Server
      Tokenization Data Security Model
    • 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)
    • 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
    • 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
    • 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
    • Evaluation Criteria
      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
      032
    • Evaluating Data Protection Options
      033
      Worst
      Best
    • Enterprise View of Different Protection Options
      034
    • Application Transparency – Encryption, Tokens & Hashing
      Transparency level
      High
      Low
      Database Encryption
      Smart Tokens
      Hashing
      Database
      Operation
      I
      Look-up
      I
      Range
      Search
      I
      Process
      Clear-values
    • Data Protection Options-Use Cases
      036
    • Data Protection Options in the Enterprise
      Application Databases
      (CCN, SSN …)
      Strong Encryption
      Kjh3409)(*&@$%^&
      Key Manager
      Formatted Encryption
      1234 1234 1234 4560
      Token
      1234 1234 1234 4560
      Token
      Server
      $%.>/$&#
      Cipher
      Text
      Token
      037
    • Partial Encryption/Tokenizing - Example
      Many applications/tools
      • Moving data around
      Some applications
      • Partial clear data
      Application
      Application
      Application
      Application
      Application
      Application
      Application
      Application
      Application
      Application
      Application
      Application
      Application
      123456 777777 1234
      Application
      Application
      Few applications
      • Full clear data
      Decryption
      Application
    • Data Protection Options – 3 Use Cases
      Can use stored protected value:
      1234 1234 1234 4560
      Or
      Kjh3409)(*&@$%^&
      Application 1
      Need partial Information
      in clear:
      1234 1234 1234 4560
      Application 2
      Need full Information
      in clear:
      55 49 9437 0789 4560
      Application 3
      039
    • How will different Protection Options Impact Applications?
      Application
      Databases
      (CCN, SSN …)
      Can use stored
      protected value:
      1234 1234 1234 4560
      Or
      Kjh3409)(*&@$%^&
      Application 1
      Key Manager
      Strong Encryption
      Kjh3409)(*&@$%^&
      Need partial Information
      in clear:
      1234 1234 1234 4560
      Application 2
      Formatted Encryption
      1234 1234 1234 4560
      Need full Information
      in clear:
      55 49 9437 0789 4560
      Application 3
      $%.>/$&#
      Cipher
      Text
      Token
      1234 1234 1234 4560
      Token
      Token Server
      Token
      Cipher
      040
    • Application Impact with Different Protection Options
      Transparency
      Security
      041
    • Application Impact with Different Protection Options
      Performance and scalability
      Availability
      042
    • Data Protection in the Enterprise – Implementation Example
      Collection
      Need partial Information
      in clear:
      1234 1234 1234 4560
      Key Manager
      POS
      Branch
      e-commerce
      Aggregation
      Need full Information
      in clear:
      55 49 9437 0789 4560
      Operations
      Analysis
      $%.>/$&#
      Can use stored
      protected value:
      1234 1234 1234 4560
      Cipher
      Text
      Token
      Token Server
      Archive
      Token
      Cipher
      043
    • Data Protection Implementation Layers
      Data Protection Options are not mutually exclusive
      Data Protection Layers
      Application
      Database
      File System
      Data Protection Topologies
      Remote services
      Local service
      Data Security Management
      Central management of keys, policy and reporting
      044
    • 045
      Data Protection Implementation - Enforcement Points
      Data
      Entry
      Network
      123456 123456 1234
      123456 123456 1234
      @$%$^D&^YTOIUO*^
      Application
      Application
      Application
      Application
      Database
      Database
      File
      System
      File
      System
      Storage (Disk)
      Storage (Disk)
      Backup (Tape)
      Backup (Tape)
      Protected sensitive information
      Unprotected sensitive information:
    • Generalization: Encryption at Different System Layers
      High
      Ease of Deployment
      (Transparency)
      Separation of Duties
      (Security Level)
      Low
      Encryption
      Layer
      I
      File System
      Layer
      I
      Database
      Layer
      I
      Storage Layer
      SAN/NAS…
      I
      Application
      Layer
    • 047
      Data Protection Implementation Layers
      Best
      Worst
    • Column Encryption Performance - Different Topologies
      Rows Per Second
      10 000 000 –
      1 000 000 –
      100 000 –
      10 000 –
      1 000 –
      Data Warehouse
      Platforms
      Mainframe
      Platforms
      Unix Platforms
      Windows Platforms
      Data Loading (Batch)
      Queries (Data Warehouse & OLTP)
      Encryption
      Topology
      I
      Network Attached
      Encryption (SW/HW)
      I
      Local
      Encryption (SW/HW)
    • A Few Comments on PCI Compliance
      Formatted encryption is NOT for PCI
      • When PCI refers to encryption, it must be “strong”
      • PCI provides high-level examples of what constitutes strong encryption, then refers to NIST for more details
      • NIST publishes a list of acceptable ciphers and operating modes
      • NIST has been considering new operating modes related to formatted encryption since 2000
      Tokenization
      • PCI refers to this as an “index pad”
      • The pad needs to be protected with strong encryption
    • Main Takeaways
      Formatted encryption and tokenization are two very different techniques
      They are good solutions for particular use cases
      Enterprises should carefully evaluate these techniques against their use cases, adjusting for factors such as risk, cost, and compliance
      050
    • Data Protection and Encryption in the Enterprise
      RACF
      Applications
      ICSF
      Mainframe
      z/OS
      Encryption
      Solution
      DB2
      Hardware
      Security
      Module
      Files
      DB2 UDB
      Central Key
      Manager
      Informix
      Hardware
      Security
      Module
      System i
      Oracle

      Resource Access Control Facility (RACF)
      Integrated Cryptographic Service Facility (ISCF)
    • 052
      CPACF - CP Assist for Cryptographic Functions
      CP = Central Processor
    • Vendors Providing Encryption on IBM Mainframe
      053
      Worst
      Best
    • Data Protection and Encryption on z/OS – PCI DSS
      API
      RACF
      Applications
      ICSF
      Fieldproc,
      Editproc,
      UDF
      Encryption
      Solution
      Mainframe
      z/OS
      DB2
      Hardware
      Security
      Module
      Utility
      Files
    • Evaluation of Encryption Options for DB2 on z/OS
      Best
      Worst
      055
    • Field Encryption – Protecting the Data Flow
      Windows,
      Unix,
      Linux,
      iSeries

      File
      Encrypt
      Application
      Crypto
      Solution
      Fields
      File
      File
      Central Key
      Manager
      Application
      Mainframe
      z/OS
      DB2
      Decrypt
      Crypto
      Solution
      Application
      Fields
    • Transparent Encryption – No Application Changes
      Encrypt
      Database
      Windows,
      Unix,
      Linux,
      iSeries

      Fields
      Crypto
      Solution
      Application
      File
      File
      Central Key
      Manager
      Decrypt
      Utility
      Fields
      Mainframe
      z/OS
      File
      Crypto
      Solution
      Application
      Encrypt
      DB2
      Fields
    • Main Takeaways
      DB2 for z/OS has good data protection options. 
      Often data and use cases may require additional protection options, including better protection granularity
      Data protection approaches – transparency vs. security
      Different topologies for data protection solutions – performance, scalability and availability
      Enterprise management – keys, policy and reporting
      Enterprises should carefully evaluate these techniques against their use cases, adjusting for factors such as risk, cost, and compliance
      058
    • Vendors Providing Data Protection
      059
      Worst
      Best
    • Protecting Data in the Enterprise Data Flow
      Passive Approaches
      +
      Active Approaches
      =
      End-To-End Protection
    • Protecting Data in the Enterprise Data Flow
      Passive Approaches
      Active Approaches
      Passive Approaches and Active Approaches = End-To-End Protection
      Database Server
      Database
      Columns
      Web Application
      Firewall
      Database
      Activity
      Monitoring
      Applications
      Database Activity
      Monitoring /
      Data Loss Prevention
      Database
      Log Files
      Tablespace
      Datafiles
    • Passive Data Protection Approaches
      Web Application Firewall
      Protects against malicious attacks by inspecting application traffic
      Data Loss Prevention
      Tags and monitors movement of sensitive assets
      Protects against the unintentional outbound leakage of sensitive assets
      Database Activity Monitoring
      Inspects , monitors, and reports database traffic into and out of databases
      Can block malicious activity; seldom used due to false positives
      Database Log Mining
      Mines log files that are created by databases for good or bad activity
    • Active Data Protection Approaches
      Application Protection
      Utilizes crypto APIs to protect sensitive assets in applications
      This approach helps you protect data as it enters your business systems
      Column Level Protection
      Protects data inside the database at the column level
      Can be deployed in a transparent approach to minimizes changes to your environment
      Considered to be the most secure approach to protect sensitive assets
      Database file protection
      Protects the data by encrypting the entire database file
    • Passive Database Protection Approaches
      Operational Impact Profile
      Best
      Worst
    • Active Database Protection Approaches
      Operational Impact Profile
      Best
      Worst
    • Risk Adjusted Data Protection
      066
      Assign value to your data
      Assess exposure
      Determine risk
      Understand which Data Protection solutions are available to you
      Estimate costs
      Choose most cost effective method
    • Assign Value to Your Data
      067
      Identify sensitive data
      If available, utilize data classification project
      Rank what is sensitive on its own (think PCI)
      Consider what is sensitive in combination (think Privacy)
      How valuable is the data to (1) your company and (2) to a thief
      Corporate IP, Credit Card numbers, Personally Identifiable Information
      Assign a numeric value: high=5, low=1
    • Assess Exposure and Probability
      Locate the sensitive data
      Applications, databases, files, data transfers across internal and external networks
      Location on network
      Segmented
      External or partner facing application
      Access
      How many users have access to the sensitive data?
      Who is accessing sensitive data?
      How much and how frequently data is being accessed?
      Assign a numeric value: high=5, low=1
      068
    • Determine “Risk” – A Simplified Model
      Data Security Risk=Data Value * Exposure
      069
      Enables prioritization
      Groups data for potential solutions
    • Matching Data Protection Solutions with Risk Level
      070
      Risk
      Solutions
      Low Risk
      (1-5)
      Monitor
      Monitor, mask, access control limits, format control encryption
      At Risk
      (6-15)
      Select risk-adjusted solutions for costing
      Replacement, strong encryption
      High Risk
      (16-25)
    • Estimate Costs
      Cost = Solution Cost + Operations Cost
      Solution Cost = cost to license or develop, install and maintain
      Operations Cost = cost to change applications, impact on downstream systems, meeting SLAs, user experience
      071
    • Operation Cost Factors
      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
      072
    • Operation Cost Factors
      Solution should be able to change with the environment
      Progress from less to more secure solution, or the reverse
      Add new defenses for future threats
      Plug into existing infrastructure, integrate with other systems
      073
    • How to Protect the Weak Links in your Data Flow
      074
      Review Risk & Determine Protection Approach
      • Analyze the Data Flow
      • Identify Assets and Assign Business Value to each
      • Identify Vulnerabilities for each Asset
      • Identify potential Attack Vectors & Attackers
      • Assess the Risk
      • Compliance Aspects
      • Select Data Protection Points & Protection Methods
      Assess Total Impact
      • Functionality Limitations
      • Performance & Scalability
      • Application Transparency
      • Platform Support & Development Life Cycle Support
      • Key Management, Administration & Reporting
      • Deployment Cost, Time & Risk
      Adjust
    • Cost Effective Data Protection
      Uses Risk as an adjusting factor for determining a Data Protection strategy
      Risk=Data Value*Exposure
      Determines solutions that fit the risk level, then determines cost
      Cost=Solution Cost + Operational Cost
      Prepare for the future
      075
    • Use of production data in a test system
      Production data is in many cases needed to ensure quality in system testing
      Key data fields that can be used to identify an individual or corporation need to be cleansed to depersonalize the information
      Cleansed data needs to be easily restored (for downstream systems and feeding systems), at least in the early stages of implementation
      This requires two-way processing.
      The restoration process should be limited to situations for which there is no alternative to using production data (interface testing with a third party or for firefighting situations, for example).
      Authorization to use this process must be limited and controlled. In some situations, business rules must be maintained during any cleansing operation (addresses for processing, dates of birth for age processing, names for gender distinction).
      There should also be the ability to set parameters, or to select or identify fields to be scrambled, based on a combination of business rules.
      A solution must be based on secure encryption, robust key management, separation of duties, and auditing.
      076
    • Data Masking – One-way vs. Two-way
      Data Quality &
      Exposed Details
      3rd Party
      Interface
      Testing
      Data Entry
      Partner
      Interface
      Fire
      Fighting
      High –
      Low –
      Two-Way
      Masking
      Two-Way
      Masking
      One-Way
      Masking
      One-Way
      Masking
      Information
      Life Cycle
      I I I I I I I
      Development Testing Staging Production Operational Analytics Archive
      Protected sensitive information
      Unprotected sensitive information:
      077
    • Business Value vs. Ease of Compliance
      Ease of
      Compliance
      High
      Business
      Value
      Encryption
      Tokenizing
      Hashing
      Simple
      Masking
      Low
      I I I I
      Deleting Data Masking One-way Masking-Two-Way Clear Data
      Lost Data
      Reusable Data
    • Data Security Management
      An integral part of technical and business process
      Security Policy
      Centralized control of security policy
      Consistent enforcement of protection
      Separation of duties
      Reporting and Auditing
      Compliance reports
      Organization wide security event reporting
      Alerting
      Integration with SIM/SEM
      Key Management
      079
    • Managing Data Security in the Enterprise
      Central Management of Security Policy, Reporting,
      Encryption Keys,
      And Data Tokens
      Mainframe
      z/OS
      DB2 UDB
      Informix
      iSeries
      Oracle,
      SQL Server

    • How about Native Database Encryption?
      Advantages
      Available from most database vendors
      Enables you to get started quickly
      Disadvantages
      Mostly non-transparent solutions
      Some vendors do not protect the Data Encryption Keys well enough
      Lack of secure interoperability between instances of the same vendor
      No secure interoperability with databases from other vendors
      No centralization of policy, key management, and audit reporting
    • http://www.net-security.org/dl/insecure/INSECURE-Mag-2.pdf
    • Protecting the Data Flow:
      Case Studies
      083
    • Partners
      (Financial
      Institutions)
      Data Protection in the Enterprise Data Flow
      Points of collection
      Store Back Office
      Web
      Apps
      Retail
      Locales
      Store Back Office Applications
      Store
      DB
      T-Logs,Journals
      $%&#
      Collection
      $%&#
      $%&#
      $%&#
      $%&#
      Branches/Stores
      HQ
      Polling Server
      Aggregation
      Log
      $%&#
      Policy
      Policy
      Policy
      Policy
      Policy
      Policy
      Policy
      Manager
      Multiplexing Platform
      ERP
      $%^&
      *@K$
      Operations
      Reports
      Log
      Log
      Analytics
      Detailed Analytical
      Archive
      7ks##@
      Focused / Summary Analytical
      Tactical
      Active Access / Alerting
      Log
    • http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1144290
    • http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1051481
    • Case Studies
      One of the most widely recognized credit and debit card brands in the world
      • Their volume of data is in the multiple billions of rows and needed a solution that would not degrade performance.
      Major financial institution
      Protecting high-worth clients financial information.
      Central key management and separation of duties were of the utmost importance.
      One of the world largest retailers
      Protecting the flow of sensitive credit card information from the store, through to back office systems and into the data warehouse and storage.
      The central key management and ability to support thousands of stores was critical for this success.
      Transparent to exiting applications. 
      Protect sensitive information in their Teradata data warehouse. iSeries (AS/400), zSeries (mainframe), Oracle and MS SQL Server, and to protect files that reside across platforms including Unix and z/Series.
      087
    • Case 1: Goal – PCI Compliance & Application Transparency
      Credit
      Card
      Entry
      Application
      Application
      File
      Encryption
      FTP
      Settlement
      Batch
      File
      Encryption
      Windows
      File
      Encryption:
      Windows,
      UNIX,Linux,
      zOS
      Database
      Encryption:
      DB2 (zOS, iSeries),
      Oracle,
      SQL Server
      Local
      Store Location
      (Branch)
      Financial
      Institution
      Central HQ Location
    • 089
      Case 1: File Encryption & FTP
      Credit
      Card
      Entry
      Attacker
      Attacker
      Network
      POS Application
      FTP
      Application
      123456 123456 1234
      123456 123456 1234
      @$%$^D&^YTOIUO*^
      @$%$^D&^YTOIUO*^
      File System (Memory)
      Storage (Disk)
      Backup (Tape)
      Protected sensitive information
      Unprotected sensitive information:
    • 090
      Case 1: From Encrypted File to Encrypted Database
      Attacker
      Application
      Attacker
      Network
      @$%$^D&^YTOIUO*^
      123456 123456 1234
      123456 123456 1234
      FTP Application
      Database
      @$%$^D&^YTOIUO*^
      File
      File
      Protected sensitive information
      Unprotected sensitive information:
    • Case 2a: Goal – Addressing Advanced Attacks & PCI
      Credit
      Card
      Entry
      Continuously encrypted computing:
      protection of sensitive data fields
      Application
      Encryption
      Application
      Application
      FTP
      Decryption
      Settlement
      FTP
      File
      Encryption
      Windows
      File
      Encryption:
      Windows,
      UNIX,Linux,
      zOS
      Database
      Encryption:
      DB2
      Oracle
      SQL Server
      Financial
      Institution
      Local
      Store Location
      (Branch)
      Central HQ Location
    • 092
      Case 2a: Application Encryption to Encrypted Database
      Point
      Of Data
      Acquisition
      Network
      123456 123456 1234
      POS
      Application
      Application
      123456 777777 1234
      Database
      File
      System
      Storage (Disk)
      Backup (Tape)
      Protected sensitive information
      Unprotected sensitive information:
    • Case 2b: Goal – Addressing Advanced Attacks & PCI
      Credit
      Card
      Entry
      Continuously encrypted computing:
      protection of sensitive data fields
      Application
      Database
      Encryption:
      SQL Server
      Application
      FTP
      Database
      Encryption:
      DB2 zOS
      Central
      HQ Location
      Local
      Store Location
    • 094
      Case 2b: From Encrypted Database to File & FTP
      Point
      Of Data
      Acquisition
      aVdSaH 1F4hJ5 1D3a
      123456 123456 1234
      Extraction
      Application
      Order
      Application
      FTP Application
      aVdSaH 1F4hJ5 1D3a
      Database
      aVdSaH 1F4hJ5 1D3a
      File
      Storage (Disk)
      Backup (Tape)
      Protected sensitive information
      Unprotected sensitive information:
    • 095
      Case 2b: From Selectively Encrypted File to Encrypted Database
      Network
      123456 123456 1234
      Application
      aVdSaH 1F4hJ5 1D3a
      aVdSaH 1F4hJ5 1D3a
      FTP Application
      Database
      File
      Storage (Disk)
      Backup (Tape)
      Protected sensitive information
      Unprotected sensitive information:
    • Case 3: Goal – Addressing Advanced Attacks & PCI
      Credit
      Card
      Entry
      Continuously encrypted computing:
      protection of sensitive data fields
      Authorization
      Transaction
      Online
      Decrypting
      Gateway
      Encrypting
      Gateway
      Application
      Application
      Files
      Databases
      Local
      Store Location
      (Branch)
      Financial
      Institution
      Central
      HQ Location
    • 097
      Case 3: Gateway Encryption
      Attacker
      Attacker
      Network
      123456 123456 1234
      123456 123456 1234
      Encrypting Gateway
      Decrypting Gateway
      123456 777777 1234
      123456 777777 1234
      Applications
      Database
      File System
      Storage (Disk)
      Backup (Tape)
      Protected sensitive information
      Unprotected sensitive information:
    • 098
      http://papers.ssrn.com/sol3/papers.cfm?abstract_id=940287
    • Different ‘Tokenizing’ Approaches & Topologies
      Algorithmic
      Tokenizer
      CCN
      123456 123456 1234
      ABCDEF GHIJKL 1234
      Application
      ‘Encryption’
      Algorithm
      On-site
      Local
      Tokenizer
      Token
      Token
      &
      Encrypted
      CCN
      Branch Office / Stores
      Network
      Home Office / HQ
      On-site
      Central
      Tokenizer
      Token
      &
      Encrypted
      CCN
      Token
      Network
      Outsourced / ASP
      ASP
      Central
      Tokenizer
      Token
      &
      Encrypted
      CCN
    • How to Protect the Data Flow Against Advanced Attacks
      0100
      Point Of Data Acquisition
      123456 123456 1234
      Continuously protected data flow
      Encrypt
      123456 777777 1234
      123456 777777 1234
      123456 777777 1234
      Decrypt
      Decrypt
      123456 123456 1234
      123456 123456 1234
      Payment
      Authorization
      Settlement &
      Charge-back
      Unprotected sensitive information:
      Protected sensitive information
    • How to Protect the Data Flow Against Advanced Attacks
      0101
      Point Of Data Acquisition
      123456 123456 1234
      Continuously protected data flow
      Encrypt
      123456 777777 1234
      123456 777777 1234
      123456 777777 1234
      Decrypt
      Decrypt
      Payment
      Authorization
      Settlement &
      Charge-back
      Unprotected sensitive information:
      123456 123456 1234
      123456 123456 1234
      Protected sensitive information
    • http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1330466
    • 0103
      http://www.quest-pipelines.com/newsletter-v7/0706_C.htm
    • 0104
    • Protegrity Solutions
      0105
      Protecting data
      Protecting web applications
      Managing data security
    • Data Security Management
      An integral part of technical and business process
      Security Policy
      Centralized control of security policy
      Consistent enforcement of protection
      Separation of duties
      Reporting and Auditing
      Compliance reports
      Organization wide security event reporting
      Alerting
      Integration with SIM/SEM
      Key Management
      0106
    • The Protegrity Defiance© Suite
      Data Protection System (DPS)
      Encryption, monitoring, masking
      Database, file and application level
      Threat Management System (TMS)
      Web application firewall
      Enterprise Security Administrator
      Security policy
      Key management
      Alerting, reporting, and auditing
      107
    • Questions?
      If you would like a copy of the slides, please email ulf.mattsson@protegrity.com
    • 0109
      APPENDIX
    • Current Discussion of Data Protection for PCI DSS
      110
      https://www.pcisecuritystandards.org
      Protegrity:
      Participating
      Organization
      PCI SSC is currently studying the effect on the standard by different technologies (i.e. End to end encryption, tokenization, chip and pin etc.)
      Bob Russo (GM) & PCI SSC is currently are working in Europe with the European Payment Council (EPC) .
    • PCI Security Standards Council about Data in Transit
      The PCI Security Standards Council (https://www.pcisecuritystandards.org/) manages the PCI DSS standards 
      End-to-end encryption is likely to be a central focus as the council seeks input on how this might best be achieved in the payment-card environment through different technologies.
      If that is accomplished, it might result in a decidedly new PCI standard in the future for card-data protection, PCI Security Standards Council says in http://www.networkworld.com/news/2008/100108-pci-credit-card.html?page=2 .
      "Today we say if you're going outside the network, you need to be encrypted, but it doesn't need to be encrypted internally," PCI Security Standards Council says.
      "But as an example, if you add end-to-end encryption, it might negate some requirements we have today, such as protecting data with monitoring and logging.
      Maybe you wouldn’t have to do that. So we'll be looking at that in 2009."
      0111
    • the PCI Knowledge Base (www.KnowPCI.com)-Based on Over 450 Hours of 100% Anonymous Interviews – Not a Survey
    • 0113
    • The Major Features of the PCI Knowledge Base (www.KnowPCI.com)
      IT IS FREE TO REGISTER
      INTERACT WITH OUR PANEL OF 85+ PCI EXPERTS
      LATEST PCI NEWS FEEDS
      WE HOST A WEEKLY PCI RESEACH WEBINAR SERIES
      YOU WON’T SEE THE “KNOWLEDGE BASE” UNTIL YOU ARE LOGGED IN
      ASK QUESTIONS OF PEERS AND ASSESSORS IN OUR FREE PCI DISCUSSION FORUMS
      SEARCH OUR DATABASE OF OVER 3000 BEST PRACTICES FROM MERCHANTS, PCI ASSESSORS, BANKS, CARD PROCESSORS AND MANY OTHERS.
      PURCHASE OUR LATEST RESEARCH REPORTS & TREND ANALYSIS
      WE’VE CONDUCTED 300 HOURS OF ANONYMOUS INTERVIEWS AND HAVE 1800+ MEMBERS
    • Based on Over 450 Hours of 100% Anonymous Interviews – Not a Survey
      Interviews with retailers focus on best practices, experiences, QSA and vendor feedback, budgets and priorities.
      450+
      Hours
      Interviews with QSAs, consultants and IT providers focused on vulnerabilities, risks and technology adoption trends.
      Source: PCI Knowledge Base, July 2009
    • Why is Tokenization Such a Hot Issue for PCI Compliance?
      Lowers Security Cost – Tokenization reduces or eliminates “sensitive” data from your systems. The less data you have to protect, the less it costs to secure it.
      Reduces Compliance Scope – Only systems that store, process or transmit cardholder data are in PCI scope. By eliminating card data from most or all of your systems, the number of systems that have to be assessed and secured is greatly reduced.
      Lowers Breach Risk – Tokenization replaces data that has “black market” value with data that has no value. If thieves know that you have no valuable data, they have no reason to try to break into your systems.
      Source: PCI Knowledge Base, July 2009
    • Why is Tokenization Such a Hot Issue for PCI Compliance?
      Source: PCI Knowledge Base, July 2009
    • Multi-Channel Issues: Is One Tokenization Solution Possible?
      BUYER 1
      BUYER 2
      BUYER 3
      (Virtual)
      POS
      Call
      Center
      Shopping
      Cart
      GL / AR / AP
      Loss
      Prevention
      Sales
      Audit
      FRONT OFFICE APPLICATIONS
      BACK OFFICE APPLICATIONS
      Secure Data Storage,
      Mgmt & Retrieval
      “Fake” Data
      “Real” Data
      PAYMENT PROCESSING
      ISO /
      Processor
      Acquiring
      Bank
      Payment
      Gateway
      Source: PCI Knowledge Base, July 2009
    • Proving Tokenization Works: Is it Being Used Beyond Pilots / Trials?
      Since June 2008, our interview data has shown a major shift in how merchants, payment processors and PCI assessors view tokenization.
      In our anonymous discussions, we find that more merchants are aware of tokenization, and most are now planning to implement it, or at least considering tokenization.
      Source: PCI Knowledge Base, July 2009
    • Cost: How to Compare Tokenization Costs vs PCI Compliance Costs?
      ISSUE: The cost savings due to tokenization vs the cost of all PCI controls, not just encryption.
      Access Controls
      Access Controls
      Access Controls
      Encryption
      Encryption
      Encryption
      Payment
      Terminal
      POS
      Server
      Polling
      Server
      PW Vaulting
      PW Vaulting
      PW Vaulting
      Temp
      FTP
      Logging
      Logging
      Logging
      E2E Encryption & Enterprise Key Management, A Needed, but Complex Dependency
      Access Controls
      Access Controls
      Access Controls
      Email
      Encryption
      Encryption
      Encryption
      Web
      Store
      Call
      Center
      Fraud
      Mgmt
      ISSUE: E2E encryption will also reduce costs long term, but the up front costs are likely to be higher
      PW Vaulting
      PW Vaulting
      PW Vaulting
      Logging
      Logging
      Logging
      Source: PCI Knowledge Base, May 2009
    • Token Options: How and When Can Tokens be Generated & Managed?
      OPTION #1
      Example: Homegrown tokenization
      Card #
      In-Store
      POS Apps
      ERP
      Application
      Token
      The best token generation & management may vary depending on business needs. Hospitality has different transaction timeframes than most retail, for example.
      Processor
      Token Mgmt
      Card #
      Most Web
      or POS
      Applications
      E-Commerce
      Web Host
      Token
      Token
      OPTION #2
      OPTION #3
      Card #
      Industry
      Token Mgmt
      Hospitality
      Applications
      Call Center
      Applications
      Token
      Token
      Source: PCI Knowledge Base, July 2009
    • PED / POS
      Vendors
      (Encrypt from Swipe to Acquirer)
      Corporations
      Homegrown tokens (e.g., Hashes)
      Vendor Decisions: How to Choose Among the Tokenization Options?
      ISSUE: Who is best positioned to manage end-to-end encryption?
      Processors
      (Outsourced Payment Mgmt
      Solutions)
      Encryption SW
      Encryption & Key Mgmt SW that generates tokens
      ISSUE: How to best reduce the number of data repositories and ensure that “encrypt / decrypt / re-encrypt” cycles are eliminated, so the vulnerabilities can be eliminated or reduced?
      Payment Terminal
      Card Swipe
      POS Terminal
      w/Payment SW
      Store Server
      w/Payment SW
      In-House Payment
      Gateway / Switch
      Source: PCI Knowledge Base, January 2009
    • Getting the Most Value from Tokenization Solutions
      Scalability: The more data repositories and systems that store, process or transmit cardholder (or other confidential) data, the more value you will receive from tokenization. Consider these examples:
      E-Commerce
      Website
      Call Center
      Applications
      In-Store
      POS Apps
      Operations
      Applications
      Fraud / Loss
      Prevention
      Sales Audit
      System
      SMEs
      Mid-Tier Merchants
      F1000 Level Merchants
      Single Channel
      Single App
      POS + MOTO Sales Channels
      + Some Tracking Apps
      Multi-Channel Business + Internal Data Stores +
      Service Providers for Sales Analysis, etc.
      Value added:
      1. Data Mgmt
      2. Reduce Risk
      3. Part of data outsourcing
      Value added:
      1. Reduces data redundancy
      2. Reduces unauthorized access by employees
      3. May be homegrown
      Value added:
      1. Major PCI scope and cost reductions
      2. Identifies risky data flows & processes
      3. Offered as a service by processors or other third parties
      Source: PCI Knowledge Base, July 2009
      MOTO = Mail Order / Telephone Order
    • Integrating Tokenization: How to Make it “Part of” Applications?
      ISSUE: The debit & credit settlement process often means that ERP, CRM and SCM apps are in PCI scope, and rewriting them is far more costly than PCI compliance.
      ISSUE: The movement of card data among systems creates dozens of different intermediate processes & data stores, greatly increasing risk, and process re-design can take years.
      ISSUE: The average Level 1 or large Level 2 merchant has 4-6 different encryption systems. Complete replacement is not an option for most of them, and enterprise-wide encryption can cost > $1M
      Source: PCI Knowledge Base, May 2009
    • Why Keep Card Data at All? When to Outsource Payment Processing
      One of the biggest changes we have seen in the last year is the growth in the consideration of outsourcing. Mostly, this is among firms that have been running their own payment gateway across their divisions.
      Source: PCI Knowledge Base, May 2009
    • Adopt “Secure Tokenization” to Remove Card Data But Retain Analytics
      Current vs Potential Use of Secure Tokenization
      A few leading retailers are using secure tokenization systems. But some of the first generation tools and in-house projects are not sufficiently secure and will need to be replaced before they will pass.
      Source: PCI Knowledge Base, January 2009
    • The Bottom Line: Tokenization is an Enterprise Strategy
      Tokenization is a strategy when it is applied as a way to centralize and improve the management of confidential data, enterprise-wide.
      Tokenization’s value is not in the “substitution” process but in the management of confidential data.
      Tokenization drives the discovery (and removal) of confidential data from potentially hundreds or thousands of files and DBs across the enterprise.
      Tokenization has tactical value for PCI compliance, because it can greatly reduce the scope of PCI assessment as well as PCI compliance costs.
      Tokenization, at an enterprise level, must not impact system and process performance by making “real” data retrieval impossible or cumbersome.
      Tokenization as an enterprise strategy must be capable of supporting a multi-channel sales and service environment.
      Tokenization does not necessarily require that confidential data be removed from all enterprise systems, but the fewer systems that contain this data, the lower the risk.
      Tokenization providers must be thoroughly vetted, both technically and as service providers, as they become mission critical partners.
      Source: PCI Knowledge Base, July 2009
      Data Breach Survey, Ponemon Institue, 2006
    • 0128
    • 0129
    • PCI Research
      0130
    • 0131
    • 0132
    • 0133
    • 0134
    • 0135
    • 0136
    • 0137
    • 0138
    • 0139
    • Data Protection Formats
      0140
    • 0141
      Preserving the Data Format
      Data Type
      !@#$%a^&*B()_+!@4#$2%p^&*
      Hash -
      Encryption -
      Alphanumeric –
      Encoding –
      Partial Enc–
      Clear Text -
      Binary
      Data
      !@#$%a^&*B()_+!@
      aVdSaH 1F4hJ5 1D3a
      666666 777777 8888
      Token /
      Encoding
      Text
      Data
      123456 777777 1234
      Numeric
      Data
      Field
      Length
      123456 123456 1234
      I
      Original
      Length
      I
      Longer
      This is a generalized example
    • Field Level Data Protection Methods vs. Time
      Protection
      Level
      Tokenized Data
      High
      Key
      Rotation
      Strong Encryption
      (AES CBC)
      Keyed Hash
      (HMAC)
      Format Controlling
      Encryption
      (AES FCE)
      Plain Hash
      (SHA-1 on CCN)
      Medium
      Time
    • Format Controlling Encryption vs. Time
      Protection
      Level
      Tokenized Data
      High
      AES FCE
      (numeric & IV)
      AES FCE
      (alphanumeric & fix IV)
      Medium
      Time
    • Field Level Data Protection Methods vs. Time
      Protection
      Level
      Tokenized Data
      High
      AES CBC (rotating IV)
      AES CBC (fix IV, long data)
      AES CBC (fix IV, short data)
      AES ECB
      Medium
      Time
    • Application Transparency
      Transparency level
      High
      Low
      Database
      File Encryption
      3rd Party Database
      Column Encryption
      Native Database
      Column Encryption
      Smart
      Tokens
      Tokens
      Key based
      Hash
      (HMAC)
      Plain
      Hash
      (SHA-2)
      Security
      Level
    • PCI DSSTesting Procedures
    • PCI 3.1 Keep cardholder data storage to a minimum.
      147
    • PCI 3.2 Do not store sensitive authentication data
      148
    • PCI 3.3 Mask PAN when displayed
      149
    • PCI 3.4 Render PAN unreadable anywhere it is stored
      150
    • PCI 3.5 Protect cryptographic keys
      151
    • PCI 3.6 Fully document and implement all key-managementprocesses and procedures
      152