New York Metro ISSA - PCI DSS Compliance - Ulf Mattsson 2009
Upcoming SlideShare
Loading in...5
×
 

New York Metro ISSA - PCI DSS Compliance - Ulf Mattsson 2009

on

  • 792 views

New York Metro ISSA - PCI DSS Compliance - Ulf Mattsson 2009

New York Metro ISSA - PCI DSS Compliance - Ulf Mattsson 2009

Statistics

Views

Total Views
792
Views on SlideShare
792
Embed Views
0

Actions

Likes
0
Downloads
13
Comments
0

0 Embeds 0

No embeds

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
  • We have taken representative approaches from each class; clear, strong encryption, FPE, Tokens, Hashing, and MaskingWe would like to explore the characteristics of each class of data protection against the cost criteria;PerformanceStorageSecurityTransparency
  • Hand off to UlfThis is a ‘simplistic’ calculation, but for this purpose, this is really all that is needed. You are using this to determine a the right data protection solutions for your data.
  • Pick a Risk Value, apply here, choose solutions
  • The main challenge for protecting data isn’t the technology itself; on the interent can get algorithms to encrypt or hash dataThe real challenge for an enterprise is the management of the solution -
  • Our definition of “risk” may not equal a true risk professional, but it does make the point
  • Our definition of “risk” may not equal a true risk professional, but it does make the point
  • Hand off to UlfThis is a ‘simplistic’ calculation, but for this purpose, this is really all that is needed. You are using this to determine a the right data protection solutions for your data.
  • Integrated

New York Metro ISSA - PCI DSS Compliance - Ulf Mattsson 2009 New York Metro ISSA - PCI DSS Compliance - Ulf Mattsson 2009 Presentation Transcript

  • PCI DSS Compliance
    Ulf Mattsson, CTO
    Ulf.mattsson @ protegrity.com
  • Bio
    20 years with IBM Development & Services
    IBM Software Development & IBM Research consulting resource
    IBM Certified in IT Architecture & IT Security
    Created Protegrity's Data Security Technology
    Protegrity Policy driven Data Encryption (1994)
    Inventor of 20+ Patents
    In the areas of Encryption Key Management, Separation of Duties, Policy Driven Data Encryption, Tokenization, Internal Threat Protection, Data Usage Control, Dynamic Access Control, Intrusion Prevention and Cross System Layer Security.
    Master's degree in Physics and degrees in Finance and Electrical engineering
    Research member of the International Federation for Information Processing (IFIP) WG 11.3 Data and Application Security.
    Member of IEEE, OASIS, Computer Security Institute (CSI), Object Management Group (OMG) CORBA Security Service, Open Web Application Security Project (OWASP), Information Systems Security Association (ISSA), Information Systems Audit and Control Association (ISACA),, The International Association of Science and Technology for Development (IAST), The Medical Records Institute (MRI), and The World Scientific and Engineering Academy and Society for Computer Security (WSEAS).
    02
  • 03
    PCI DSS Compliance
    View slide
  • Agenda
    PCI Information Sources
    Data Protection Options for PCI and Beyond
    PCI Case Studies
    Advanced Attacks on Data Flow
    Appendix
    PCI Feedback
    Determining Risks
    Cost Effective Approach
    Resources
    View slide
  • Source of Information about PCI DSS
    http://www.knowpci.com
  • 06
  • Current Discussion of Data Protection for PCI DSS
    7
    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."
    08
  • 09
  • 010
  • 011
    http://papers.ssrn.com/sol3/papers.cfm?abstract_id=940287
  • http://ssrn.com/abstract=1126002
  • PCI DSS 1.2 Applicability Information & PII Aspects
    14
  • Discussion of Data Protection for PCI DSS
    15
  • Requirement 3: Protect stored cardholder data
    Section 3.4
    Render PAN, at minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs) 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
    The MINIMUM account information that must be rendered unreadable is the PAN.
    Notes:
    If for some reason, a company is unable render the PAN unreadable, refer to Appendix B: Compensating Controls.
    “Strong cryptography” is defined in the PCI DSS Glossary of Terms, Abbreviations, and Acronyms
    016
  • Section 3.5
    “Protect encryption keys used for encryption of cardholder data against both disclosure and misuse.
    3.5.1 Restrict access to keys to the fewest number of custodians necessary
    3.5.2 Store keys securely in the fewest possible locations and forms.”
    Section 3.6
    “Fully document and implement all key management processes and procedures for keys used for encryption of cardholder data, including the following:
    3.6.1 Generation of strong keys
     3.6.2 Secure key distribution
     3.6.3 Secure key storage
     3.6.4 Periodic changing of keys
    • As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically. At least annually.
     3.6.5 Destruction of old keys
     3.6.6 Split knowledge and establishment of dual control of keys (so that it requires two or three people, each knowing only their part of the key, to reconstruct the whole key)
     3.6.7 Prevention of unauthorized substitution of keys
     3.6.8 Replacement of known or suspected compromised keys
     3.6.9 Revocation of old or invalid keys
    017
    Requirement 3: Protect stored cardholder data
  • Split knowledge and dual control of keys requires two or three people, each knowing only their part of the key, to reconstruct the whole key
    The principle behind dual control and split knowledge is required to access the clear text key.
    Only a single master key will be needed under this control.
    The determination of any part of the key must require the collusion between at least two trusted individuals.
    Any feasible method to violate this axiom means that the principles of dual control and split knowledge are not being upheld.
    At least two people are required to ‘reconstruct’ the key, and they each must have a physical thing and they each must have some information that is required.
    The use of a key in memory to encipher or decipher data, or access to a key that is enciphered under another key does not require such control by PCI DSS.
    Keys appearing in the clear in memory, the principles of dual control and split knowledge are difficult but not impossible to enforce.
    Please review http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1126002 for additional discussion.
    018
    Requirement 3.6.6: Split knowledge and dual control
  • Currently KM vendor products support different and isolated areas (tape, storage, network, end points …):
    Over time (maybe years from now) the emerging KM standards will be finalized (and hopefully converge) and eventually be supported by major KM vendor products (and end point platforms that actually can use the keys).
    This is a list of the major (and conflicting) emerging KM standards and guidelines:
    OASIS KMIP TC is very broad including e-mail encryption and more compared to the mainly storage-related IEEE P1619.3 and EKMI that is primarily symmetric key focused. 
    KMIP TC is not directly related to the more mature P1619.x and specifically P1619.3, though they share many members. 
    ANSI X9.24 is solving management of symmetric keys with focus on financial and retail industry.
    NIST SP 800-57 is a very solid recommendation for key management and key states.
    IETF KEYPROV is defining how to provision symmetric keys.
    SKSML from the OASIS EKMI group is defining a protocol for acquiring symmetric keys.
    Key Management Standards & Vendors
  • http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1051481
  • PCI – Compensating Controls
    21
  • 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
    22
  • 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
  • Data Protection Approaches
    Data Access Control
    How the data is presented to the end user and/or application
    Data Protection
    How sensitive data is rendered unreadable
    024
  • Data Protection Options
    Data Stored As
    Clear – actual value is readable
    Hash – unreadable, not reversible
    Encrypted – unreadable, reversible
    Replacement value (tokens) – unreadable, reversible
    Partial encryption/replacement – unreadable, reversible
    025
  • Data Protection Options
    Data in the Clear
    Audit only
    Masking
    Access Control Limits
    Advantages
    Low impact on existing applications
    Performance
    Time to deploy
    Considerations
    Underlying data exposed
    Discover breach after the fact
    PCI aspects
    026
  • Data Protection Options
    Hash
    Non – reversible
    Strong protection
    Keyed hash (HMAC)
    Unique value if salt is used
    Advantages
    None really
    Considerations
    Key rotation for keyed hash
    Size and type
    Transparency
    027
  • Data Protection Options
    Strong Encryption
    Industry standard (NIST modes - AES CBC …)
    Highest security level
    Advantages
    Widely deployed
    Compatibility
    Performance
    Considerations
    Storage and type
    Transparency to applications
    Key rotation
    028
  • Data Protection Options
    Format Controlling Encryption
    Maintains data type, length
    Advantages
    Reduces changes to downstream systems
    Storage
    Partial encryption
    Considerations
    Performance
    Security and compliance
    Key rotation
    Transparency to applications
    029
  • Data Protection Options
    Replacement Value (i.e. tokens, alias)
    Proxy value created to replace original data
    Centrally managed, protected
    Advantages
    No changes to most downstream systems
    Out of scope for compliance
    No local key rotation
    Partial replacement
    Considerations
    Transparency for applications needing original data
    Availability and performance for applications needing original data
    030
  • 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
  • Limit Exposure across the Data Flow - Partial Encryption/Tokenizing
    A policy driven approach
    • Decide what sensitive bytes to protect
    • A high level of transparency to applications
    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
  • How to Protect the Data Flow Against Advanced Attacks
    033
    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
  • 034
    Applications are Sensitive to the Data Format
    Data Type
    Binary (Hash) -
    Binary (Encryption) -
    Alphanumeric (Token) -
    Numeric (Token) -
    Numeric (Clear Text) -
    No Applications
    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
  • 035
    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
  • Data Protection Options & Cost Factors
    039
    Highest
    Lowest
  • Data Protection Capabilities
    040
    Highest
    Lowest
  • Data Protection Implementation Choices
    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
    041
  • 042
    Data Protection Implementation Choices
    Highest
    Lowest
  • 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)
  • 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
  • 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
  • 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
  • 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
  • Protecting the Data Flow:
    Case Studies
    048
  • Data Level Attacks
    DBA
    ATTACK
    MALWARE /
    TROJAN
    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
  • 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.
    050
  • Partners
    (Financial
    Institutions)
    Security for the Sensitive 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
    Analytics
    Detailed Analytical
    Archive
    7ks##@
    Focused / Summary Analytical
    Tactical
    Active Access / Alerting
    Log
  • 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
  • 053
    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:
  • 054
    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
  • 056
    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
  • 058
    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:
  • 059
    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
  • 061
    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:
  • Determine Risk
    Data Security Risk=Data Value * Exposure
    062
    Enables prioritization
    Groups data for potential solutions
  • Matching Data Protection Solutions with Risk Level
    063
    Risk
    Solutions
    Low Risk
    (1-5)
    Monitor
    Monitor, mask, access control limits, format control encryption
    At Risk
    (6-15)
    Replacement, strong encryption
    High Risk
    (16-25)
  • Matching Data Protection Solutions with Risk Level
    064
    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
    065
  • 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
    066
  • 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
    067
  • 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
    068
  • 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
    069
  • How to Protect the Data Flow Against Advanced Attacks
    070
    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
  • How to Protect the Weak Links in your Data Flow
    071
    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
  • http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1330466
  • 073
    http://www.quest-pipelines.com/newsletter-v7/0706_C.htm
  • http://www.net-security.org/dl/insecure/INSECURE-Mag-2.pdf
  • 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:
    075
  • 076
  • Separation of Duties (DBA)
    Separation of Duties (DBA)
    Database
    Column
    Encryption
    Yes -
    No -
    No -
    Database
    Table
    Encryption
    Database
    File
    Encryption
    Index
    Protection
    I
    Yes
    I
    No
    I
    No
  • 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
    078
  • Risk Adjusted Data Protection
    079
    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
    080
    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
    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
    081
  • Determine Risk
    Data Security Risk=Data Value * Exposure
    082
    Enables prioritization
    Groups data for potential solutions
  • Example – Software Application
  • Example - Attack by DBA
    Skill & Effort Level
    Attack
    Vector 3
    Programming -
    OS level-
    SQL-
    Attack
    Vector 2
    Attack
    Vector 1
    Damage
    Level
    I
    Key Dump
    I
    Data Dump
    I
    Data Leakage
  • DMZ
    TRUSTED SEGMENT
    TRANSACTIONS
    End-
    point
    Internal
    Users
    Enterprise
    Apps
    DB Server
    Server
    Load
    Balancing
    Internet
    DB
    NW
    SAN,
    NAS,
    Tape
    Proxy
    FW
    Proxy
    FW
    Proxy
    FW
    IDS/
    IPS
    Wire-
    less
    Network
    Devices
    Keys
    Server
    Members
    Web Apps
    Case Study - Data Security Vulnerability Points
    Organization data security vulnerability points under study:
    Endpoint security / desktop security / wireless security
    Customer access to Organization via Web Applications
    Web application development and access controls
    Global bulk file transfer to/from member institutions
    Corporate network infrastructure, including firewalls, IDS/IPS
    XxxNet/YyyNet global infrastructure
    Application-to-database access controls
    Database management controls, including separation of duties
    Key management systems
    Customer premises HW/SW data protection (the XXX)
    Protection of stored data in SAN, NAS and backup tapes
  • Corporate Overview
    Enterprise Data Security Management
    Full services offering including consulting, training and support
    Global reach
    300+ customers
    100% growth in each of last three years
    Founded 1996
    10 patents granted, 18 pending
    86
  • Protegrity Value Proposition
    Protecting your data. Protecting your business.
    Balancing business needs, operational performance, and the risk of data loss
    Achieving security and compliance
    87
  • Protegrity and PCI
    88
  • Our Customers
    Cross industry
    Retailers
    20% of the top 25 retailers
    Financial institutions
    Transportation
    Global
    60% in North America
    30% EMEA
    10% Asia
    089
  • 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
    90
  • Protegrity Solutions
    091
    Protecting data
    Protecting web applications
    Managing data security
  • Questions?
    If you would like a copy of the slides, please email ulf.mattsson@protegrity.com