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

1. 01 Ulf Mattsson Chief Technology Officer Protegrity Corporation Ulf . mattsson at protegrity . com

2. 02

3. Source of Information about PCI Research http://www.knowpci.com

4. 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

6. 06

7. 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

8. 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

9. 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

10. 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

11. PCI DSS 1.2 Applicability Information & PII Aspects 11

12. Discussion of Data Protection for PCI DSS 12

13. PCI – Compensating Controls 13

14. 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

15. 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

16. 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

17. 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

18. 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

19. Newer Data Protection Options Format Controlling Encryption (FCE)

20. 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

21. 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

22. 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

23. 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

24. 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

26. Limitations in functionality

27. Limitations in data search

28. Performance issuesMany Applications Most Applications Text Data All Applications Data Field Length I Original I Longer This is a generalized example

29. Newer Data Protection Options Tokenization

30. 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

31. 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)

32. 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

33. 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

34. 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

35. 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

36. Evaluating Data Protection Options 033 Worst Best

37. Enterprise View of Different Protection Options 034

38. 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

39. Data Protection Options-Use Cases 036

40. 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

42. 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

43. 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

44. Application Impact with Different Protection Options Transparency Security 041

45. Application Impact with Different Protection Options Performance and scalability Availability 042

46. 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

47. 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

48. 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:

49. 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

50. 047 Data Protection Implementation Layers Best Worst

51. 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)

53. PCI provides high-level examples of what constitutes strong encryption, then refers to NIST for more details

54. NIST publishes a list of acceptable ciphers and operating modes

57. 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)

58. 052 CPACF - CP Assist for Cryptographic Functions CP = Central Processor

59. Vendors Providing Encryption on IBM Mainframe 053 Worst Best

60. 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

61. Evaluation of Encryption Options for DB2 on z/OS Best Worst 055

62. 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

63. 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

64. 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

65. Vendors Providing Data Protection 059 Worst Best

66. Protecting Data in the Enterprise Data Flow Passive Approaches + Active Approaches = End-To-End Protection

67. 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

68. 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

69. 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

70. Passive Database Protection Approaches Operational Impact Profile Best Worst

71. Active Database Protection Approaches Operational Impact Profile Best Worst

72. 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

73. 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

74. 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

75. Determine “Risk” – A Simplified Model Data Security Risk=Data Value * Exposure 069 Enables prioritization Groups data for potential solutions

76. 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)

77. 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

78. 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

79. 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

81. Identify Assets and Assign Business Value to each

82. Identify Vulnerabilities for each Asset

83. Identify potential Attack Vectors & Attackers

84. Assess the Risk

85. Compliance Aspects

87. Performance & Scalability

88. Application Transparency

89. Platform Support & Development Life Cycle Support

90. Key Management, Administration & Reporting

91. Deployment Cost, Time & RiskAdjust

92. 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

93. 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

94. 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

95. 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

96. 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

97. 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 …

98. 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

99. http://www.net-security.org/dl/insecure/INSECURE-Mag-2.pdf

100. Protecting the Data Flow: Case Studies 083

101. 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

102. http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1144290

103. http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1051481

105. 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

106. 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:

107. 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:

108. 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

109. 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:

110. 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

111. 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:

112. 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:

113. 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

114. 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:

115. 098 http://papers.ssrn.com/sol3/papers.cfm?abstract_id=940287

116. 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

117. 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

118. 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

119. http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1330466

120. 0103 http://www.quest-pipelines.com/newsletter-v7/0706_C.htm

121. 0104

122. Protegrity Solutions 0105 Protecting data Protecting web applications Managing data security

123. 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

124. 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

125. Questions? If you would like a copy of the slides, please email ulf.mattsson@protegrity.com

126. 0109 APPENDIX

127. 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) .

128. 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

129. the PCI Knowledge Base (www.KnowPCI.com)-Based on Over 450 Hours of 100% Anonymous Interviews – Not a Survey

130. 0113

131. 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

132. 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

133. 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

134. Why is Tokenization Such a Hot Issue for PCI Compliance? Source: PCI Knowledge Base, July 2009

135. 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

136. 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

137. 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

138. 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

139. 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

140. 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

141. 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

142. 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

143. 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

144. 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

145. 0128

146. 0129

147. PCI Research 0130

148. 0131

149. 0132

150. 0133

151. 0134

152. 0135

153. 0136

154. 0137

155. 0138

156. 0139

157. Data Protection Formats 0140

158. 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

159. 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

160. Format Controlling Encryption vs. Time Protection Level Tokenized Data High AES FCE (numeric & IV) AES FCE (alphanumeric & fix IV) Medium Time

161. 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

162. 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

163. PCI DSSTesting Procedures

164. PCI 3.1 Keep cardholder data storage to a minimum. 147

165. PCI 3.2 Do not store sensitive authentication data 148

166. PCI 3.3 Mask PAN when displayed 149

167. PCI 3.4 Render PAN unreadable anywhere it is stored 150

168. PCI 3.5 Protect cryptographic keys 151

169. PCI 3.6 Fully document and implement all key-managementprocesses and procedures 152