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

Michelle West

Cards and Merchant Solutions TD Bank Financial Group

04 . 20 . 2016

Tokenization on TD NonStop Systems

Agenda

1.

Who is TD Bank Group?

2.

Why TD Bank Needs to Secure Data-at-Rest

3.

Intro to Tokenization

4.

Alternatives Considered

5.

Implementation Plan

6.

Results

7.

Summary

2

Internal

Internal

Internal

• 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

• 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

• 3. Tokenization – the concept

 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!

Tokenization Engine

PAN: 4026157151401408 Token: AB3ce7xn12VT5982

16 byte

Token: 4738218214678978 Token: 402615xn12VT1408

“664” tokenization

5

Transaction Log before Tokenization

9

$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:

Transaction Log after Tokenization

10

$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:

• 4. Alternatives considered

11

Alternatives considered: Volume Level Encryption vs comForte SecurData/Tokenization

Alternatives considered: VLE (Volume Level Encryption)

12

 Using VLE with the storage CLIM is an effective way to protect

the disk from physical theft

Encrypted DB Data Encrypted

Rats! I can’t exploit encrypted data

Data “in the clear”

Is VLE (Volume Level Encryption) enough?

13

Encrypted DB Data “in the clear” Data Encrypted

>FUP DUP $VLEDISK.SECURE, $UNSECURE.UNSAFE

 VLE doesn’t

protect from TACL attacks

“In the clear” DB That was easy!

Introducing SecurData: Transparent tokenization for HP NonStop

14

Application

SecurData Manager .

Intercept of Enscribe file system calls

TKN PAN

DB

TKN

PAN

TKN

 SecurData

transparently tokenizes Sensitive Data in DB (Enscribe

• r SQL)

 No changes to

Application code required.

Audit Log

I/O Intercept

SecurData Tokenization Engine

API

Transparent intercept: No code changes required

Stateless Tokenization Table

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

Progress with SecurData

Part 5: Implementation Plan

16

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

SecurData Pilot – Status Quo

18

HP NonStop

IBM Mainframe TCP/IP Process

local loopback Port 21 Port 1234

NonStop SSL FTPSERV

PAN1 PAN2 ...

FTPS

FUP BASE24 classic

read entries update entries process

B24 Production Enscribe DB (incl. PANs) Intermediate Enscribe File (incl. PANs)

Write to filesystem ACI TACL macro invokes

SecurData Pilot – Environment with SecurData in place

19

HP NonStop

IBM Mainframe TCP/IP Process

local loopback Port 21 Port 1234

NonStop SSL FTPSERV

PAN1 PAN2 ...

FTPS

BASE24 classic

Read entries (de-tokenize

• n-the-fly)

update entries process

B24 Production Enscribe DB (incl. PANs) Intermediate Enscribe File (incl. Tokens)

Write to filesystem (tokenize

• n-the-fly)

SecurData

ACI TACL macro invokes

FUP SecurData

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

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

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

• f 2015

22

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

• n 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

POS Tokenization phases: Avoiding the “Big Bang”

24

Phase Activity

TD POS Tokenization Phase 1

Implementation of the Defines, Installing SecurData, Tokenizing 1 small file Completed

TD POS Tokenization Phase 2

OMF Audit, Visa ILF, Banknet ILF, Vantiv ILF, ICTS SAF, PIP SAF, NRT SAF, IMNI SAF, 1 IMNI ILF (Acq,Iss), CTF Extracts, IMNAdmn Completed

TD POS Tokenization Phase 3

PTLF, VMS Extracts, Remainder of IMNI ILFs, SMS Extract, SMS ILF Completed

TD POS Tokenization Phase 4

Encrypted Extracts (FTP will decrypt before it is sent to the HOST - SMS, CTF ILF Extract, VMS PTLF Extract, PTD) In Progress

TD POS Tokenization Phase 5

CAF Scheduled for May 2016

The Phased Approach:

Phase 0

 Pre-Implementation activity:

– Added the DEFINE referring to the the SecurData Manager. – Recycled Pathway and the Base24 POS nodes

Phase 1

 HPE resources installed the SecurData vault with TD Key

Custodians.

 Chose small ILF files to tokenize in order to ensure tokenization

was functioning as expected.

 Updated utility tools with the SecurData library to make sure we

could still detokenize the PANs in these files and view them.

25

The Phased Approach:

Phase 2

 Used the SDF to set date/times for files to be tokenized

– The files we were planning on tokenizing were larger than the last phase so we wanted to be cautious. We set it up in SDF to tokenize some on the first day and slowly, throughout the week, tokenize more of the same type.

 By the end of the week, BNET and Visa ILFs were completed

as well as 1 of each (acquiring and issuing) IMN ILFs

 Also started to tokenize some SAF files and the OMF audit file

26

The Phased Approach:

Phase 3

 PTLF, Remaining IMN ILFs, Internal Files

– still broken up by dates in the SDF file to determine when the tokenization of these files would begin. – Verification took place at each of the times set in the SDF to ensure tokenization was working and detokenization could be done.

Phase 4

 Encryption/Decryption of the Extract Files

– All files (except the CAF) were now tokenized – online processing was functioning as expected – during the extract process, the extracted files had to be stored somewhere during creation; prior to being transferred to the host for batch processing

27

The Phased Approach:

Phase 5 – Implementation planned for May 2016

 CAF Tokenization  Still to be completed  Once complete, TD ABM and POS will be fully tokenized in

production

28

Considerations:

 Security

– determine who should be able to see the PAN in the clear and set up Utilities to allow for this and ensure other IDs can only see the tokenized PAN

 PAN Recognition

– determine how PANs need to be identified in your environment; by placement in the file or by the of the PAN format

 Timing

– determine when you would like the tokenization to begin; this can be set in the SDF so one implementation can include multiple files with the Tokenization beginning at different times.

 Tokenization Scheme

– determine how the PANs should be tokenized (eg. Alpha, Numeric, Partially Tokenized – 664 rule)

29

Considerations Continued:

 Delimiters:

– Because TD chose to tokenize the entire PAN with Alpha characters between A-H, we had to look at our delimiters. In some cases, a "D" was being used as a delimiter. When the PAN was being DeTokenized, SecurData was unable to determine where the PAN ended and included the delimiter in a character to be de-tokenized.

 File Conversion?

– Most files (ILF, PTLF) don't need to have conversion programs run against them to have them converted to tokenized files all at once. A date and time when tokenization starts can be added to the SDF and when a new file is created, tokenization can begin. – For other files, it needs to be determined if conversion programs should be run and the processes recycled. – Is the PAN a key? If this is the case, some planning of how to tokenize this file is needed.

30

Summary

 Securing data-at-rest is a solvable problem (PCI)

– No code changes

 Not a “Big Bang” solution

– 5 phases; some with multiple implementations – One file tokenized…. then another… validations throughout

 Back out plans are a fundamental part of implementation  No issues with any of the implementations  No performance degradation; in some cases, performance

improvement

 Phase 5: Tokenization of CAF still to do for POS but has already

been done for ABM

31

Questions?

32