tokenization on td nonstop systems
play

Tokenization on TD NonStop Systems Michelle West Cards and - PowerPoint PPT Presentation

Tokenization on TD NonStop Systems Michelle West Cards and Merchant Solutions TD Bank Financial Group 04 . 20 . 2016 Agenda Who is TD Bank Group? 1. Why TD Bank Needs to Secure Data-at-Rest 2. Intro to Tokenization 3. Alternatives


  1. Tokenization on TD NonStop Systems Michelle West Cards and Merchant Solutions TD Bank Financial Group 04 . 20 . 2016

  2. Agenda Who is TD Bank Group? 1. Why TD Bank Needs to Secure Data-at-Rest 2. Intro to Tokenization 3. Alternatives Considered 4. Implementation Plan 5. Results 6. Summary 7. 2

  3. Internal

  4. Internal

  5. Internal

  6. 1. Who is TD Bank Group?  The Toronto-Dominion Bank is a Canadian multinational banking and financial services corporation headquartered in Toronto. Commonly known as TD and operating as TD Bank Group .  TD Bank Group is the largest bank in Canada by market capitalization and a top-10 bank in North America.  In Canada, the bank operates as TD Canada Trust and serves more than 11 million customers at over 1,150 branches. In the United States, the company operates as TD Bank. The U.S. subsidiary serves more than 6.5 million customers with a network of more than 1,300 branches in the eastern United States.  Both the POS and ABM use ACI's Base24 and HPE Services 6

  7. 2. Why TD Bank Needs to Secure Data-at-Rest  Protection of customer data – Data breach threats are everywhere!  PCI requirements for both POS and ATM. (QSA Audit requirement) – Requirement 3.2.1 - Do not store the full contents of any track from the magnetic stripe (located on the back of a card, contained in a chip, or elsewhere). This data is alternatively called full track, track, track 1, track 2, and magnetic-stripe data. – Requirement 3.2.2 - Do not store the card verification code or value (three digit or four- digit number printed on the front or back of a payment card) used to verify card-not present transactions. – Requirement Number: 3.4 - Render the PAN unreadable anywhere it is stored – * Identified Risk: Storing sensitive cardholder data without encryption or tokenization may facilitate opportunity for its disclosure to individuals who are not authorized to access this data and who may use the information for fraudulent activity. 7

  8. 3. Tokenization – the concept PAN: 4026157151401408 Token: AB3ce7xn12VT5982 Tokenization Engine Token: 4738218214678978 Token: 402615xn12VT1408 “664” tokenization 16 byte  Sensitive data (e.g., PANs) are replaced with multiuse Tokens in the database  Tokens maintain the format of the original data  PANs can be reconstructed from Tokens (not just a one way hash)  Not just for PANs! 5

  9. Transaction Log before Tokenization $B2402.RYN1PTLF.PO110114 RECORD 11 KEY 12290 (%30002) LEN 1066 0: ....S...01VISAVISA4026157151401408 000RYN1AIB10015001588888830 35: 88888830 001001RYN1AIB188888830 1026410088888830 70: 588888830 11111100210001399....S...................1101 105: 1410264100110114000000110114000000005605TEST TERMINAL ASSET ML JOE 140: DOE NEW YORK IE IE0000 ..63049300000000000000007011 175: 11110000000000005999B24 B24 100000V 050............ 210: ....1306M4026157151401408=1306? 245: P1A^APACS^02 9001000 6910000000000 280: 02000001501109789786100000097861000000........1220 315: 00 00000000000 350: 0000 00 385: & ....! 04.. 0 Y ! C0..111 2 420: 7 1 ! C1..S1A^APACS^AST^02! C4..20351000061 ! B4..011500.. 455: 15060 ! P0.& 88888830 ! B8." 490: POS ! B9.< ISO000000 525: 9

  10. Transaction Log after Tokenization $B2402.RYN1PTLF.PO110114 RECORD 11 KEY 12290 (%30002) LEN 1066 0: ....S...01VISAVISA402615xn12VT1408 000RYN1AIB10015001588888830 35: 88888830 001001RYN1AIB188888830 1026410088888830 70: 588888830 11111100210001399....S...................1101 105: 1410264100110114000000110114000000005605TEST TERMINAL ASSET ML JOE 140: DOE NEW YORK IE IE0000 ..63049300000000000000007011 175: 11110000000000005999B24 B24 100000V 050............ 210: ....1306M402615xn12VT1408=1306? 245: P1A^APACS^02 9001000 6910000000000 280: 02000001501109789786100000097861000000........1220 315: 00 00000000000 350: 0000 00 385: & ....! 04.. 0 Y ! C0..111 2 420: 7 1 ! C1..S1A^APACS^AST^02! C4..20351000061 ! B4..011500.. 455: 15060 ! P0.& 88888830 ! B8." 490: POS ! B9.< ISO000000 525: 10

  11. 4. Alternatives considered Alternatives considered: Volume Level Encryption vs comForte SecurData/Tokenization 11

  12. Alternatives considered: VLE (Volume Level Encryption)  Using VLE with the storage CLIM is an effective way to protect the disk from physical theft Data “in the clear” Rats! Data Encrypted I can’t exploit encrypted data Encrypted DB 12

  13. Is VLE (Volume Level Encryption) enough? >FUP DUP $VLEDISK.SECURE, $UNSECURE.UNSAFE  VLE doesn’t That was easy! protect from TACL attacks “In the clear” DB Data “in the clear” Data Encrypted Encrypted DB 13

  14. Introducing SecurData: Transparent tokenization for HP NonStop Transparent intercept:  SecurData No code changes transparently Application required tokenizes I/O Intercept Sensitive Data Intercept of Enscribe file system calls PAN in DB (Enscribe or SQL) TKN SecurData Manager .  No changes to DB API Application Audit Log SecurData code required. Tokenization Engine TKN PAN TKN Stateless Tokenization Table 14

  15. Alternatives considered:  Volume Level Encrytion (VLE) – Pro: – Effective way to protect sensitive data from physical theft – Easy to implement – Con: – NO protection against attacks while system is running and disk is mounted  Tokenization – Pro: – Fully protects data-at-rest (satisfies PCI 3.4) – Format Preserving (no database changes required) – Application transparent (no code changes) – Can be implemented in phases (no “Big Bang”) – Con: – Requires migration strategy

  16. Progress with SecurData Part 5: Implementation Plan 16

  17. ABM Tokenization Pilot Application –HPE, ACI and comForte scheduled a 2 day workshop to familiarize the technical resources with the SecurData software. –By the end of the first day the software was loaded and a tokenization/de-tokenization of the ACOF file in a test environment was successful 17

  18. SecurData Pilot – Status Quo IBM HP NonStop Mainframe BASE24 TCP/IP ACI classic Process TACL FTPS macro Port 1234 NonStop SSL PAN1 invokes PAN2 ... process FUP local FTPSERV loopback Port 21 read update entries entries Write to filesystem Intermediate B24 Production Enscribe File Enscribe DB (incl. PANs) (incl. PANs) 18

  19. SecurData Pilot – Environment with SecurData in place HP NonStop IBM Mainframe BASE24 TCP/IP ACI classic Process TACL FTPS macro Port 1234 NonStop SSL PAN1 invokes PAN2 ... process FUP FTPSERV SecurData local loopback Port 21 Read entries SecurData update (de-tokenize entries on-the-fly) Write to filesystem (tokenize on-the-fly) Intermediate B24 Production Enscribe File Enscribe DB (incl. Tokens ) (incl. PANs) 19

  20. Lessons Learned From ABM Tokenization Pilot  Test Environment – Test environment needs to closely match the production environment. – ACOF FTP test environment was very different from the production environment – This lead to difficulties in testing FTP communication configuration  Performance – The tokenization/de-tokenization process did not cause any performance degradation 20

  21. Lessons Learned continued….  Strong comForte Support – comForte technical support was available and very knowledgeable – comForte test environments were leveraged to work out FTP issues that arose  HPE team very familiar with SecurData product – Leverage proven HPE process – Leverage HPE/comForte relationship 21

  22. ABM Implementation  ABM Team decided on a Phased Approach  Plans for this phased approach began in April of 2014 – Phases: 1. ILF Files 2. TLF Files 3. CAF  ABM Tokenization completed successfully in Production in March of 2015 22

  23. POS Implementation  Due to TD Org Structure, the ABM team and the POS team fall under different divisions  Because both ABM and POS run Base24, there are often synergies within our projects  There are multiple projects in which both ABM and POS work with HPE to implement; – it often makes sense for HPE to work with POS on one and to work with ABM on another and then, once these are completed, swap; – lessons learned from one, benefit the other  ABM implemented Tokenization while POS worked with HPE on another project  Once ABM was implemented, HPE and Comforte started working with the POS team to implement Tokenization 23

Recommend


More recommend