evaluation of the vormetric token server

White PaperEvaluation of the Vormetric Token Server

F o r t r e x . c o m

Evaluation of the Vormetric Token Server



Page | 1

Overview

Tokenization is the process of replacing sensitive data with a non-meaningful value, called a token. The token should have no value to an attacker and should bear no resemblance to the original source data. Whether the tokenized data represents a credit card number, social security number, or other confidential data, the practice is intended to mitigate the risk of accidental or unauthorized access and use. Applications can generally operate just using tokens; a small number of trusted applications can be explicitly permitted to detokenize when strictly necessary for an approved business purpose.

This white paper evaluates the Vormetric Token Server’s use case and its deployment in a typical corporate environment. Recommendations for production implementation and use to support merchant/service provider PCI DSS compliance are also detailed.

The April 2015 Payment Card Industry (PCI) Security Standards Council (SSC) Tokenization Product Security Guidelines – Irreversible and Reversible Tokens www.pcisecuritystandards.org/documents/Tokenization_Product_Security_Guidelines.pdf provides further helpful implementation guidance as well as identifying specific PCI DSS requirements to be validated when assessing the effectiveness of a tokenization solution.

The guidelines categorize valid forms of tokenization as irreversible and reversible. As format-preserving encryption (FPE) tokenization is a type of reversible tokenization process, the PCI DSS controls for reversible tokenization are examined within pages 34–46. The guidelines state:

“A cryptographic tokenization system is where the secret information consists of a cryptographic key of at least 128 bits of strength. In addition, such systems should meet all the Guidelines/Best Practices for tokenization in this section.”

Format-preserving encryption tokenization should not be confused with other encryption techniques, such as hashing, which is a one-way encryption technique. FPE tokens are reversible and can be decrypted to produce unencrypted plaintext.

Scenario: Lab Environment

The FPE-based Vormetric Token Server was installed and configured with access to a lab-based Vormetric Data Security Manager (DSM) appliance for cryptographic key management. The Token Server was registered with the DSM, and an AES 256-bit encryption key was created. The Token Server was further configured without access to a central logging server or external authentication, such as Microsoft Active Directory or other LDAP-based directory service, for purposes of testing.

https://www.pcisecuritystandards.org/documents/Tokenization_Product_Security_Guidelines.pdf

https://www.pcisecuritystandards.org/documents/Tokenization_Product_Security_Guidelines.pdf



Page | 2

Creating Users and Groups

Personnel from corporate business units such as Accounting, Human Resources, or Customer Service typically require access to sensitive data. Using the Vormetric Token Server, several user groups were created to represent these users. User accounts were created locally.

Groups that were created included Accounting, HR, Customer Service, and Retail (see Figure 2).

Figure 1

Figure 2



Page | 3

Next, user accounts were created and assigned to appropriate groups, as illustrated in Figures 3–4.

Figure 3

Figure 4



Page | 4

Token Group and Key

Configuration of encryption and tokenization components was found to be straightforward following a complete review of provided Token Server documentation. A token group identifies the encryption key to be used to create a token. Multiple token groups (see Figure 5) were created to support multiple encryption keys that are created and stored in the DSM server.

Token Templates

Token templates were observed to associate each token group with a selected method of tokenization or detokenization (see Figure 6). Options include Luhn checking (a checksum used to validate credit card numbers, attaching a prefix value to the token or characters in the original data to be left unencrypted (see Figure 7), date formats, and randomization.

The use of Random tokenization feature can be observed in figures 6 and 7 where a token template “Randomize” is created with Random format. This format is optimized for use with numbers from 9 to 19 digits (including the Luhn digit) such as credit card numbers or SSN.

Nevertheless, should the data be text-based, such as names and addresses, the FPE token format is advised.

Further, the Vormetric Tokenization install guide warns of the following issues when using token template randomization:

The Random data format uses a randomized lookup table in memory to tokenize input data consisting of numbers from 9 to 19 digits. The following issues affect the setup and use of this lookup table.

The lookup table generation process won’t start until:

• VTS is registered to DSM

• Database is configured by create or join command

Figure 5



Page | 5

Figure 6

• At least one token group is defined in Admin GUI

• Do not restart/reboot server before all the lookup tables are created. The process takes approximately one hour.

Memory Analysis

Unlike other token types, randomized tokens are stored in memory for faster access. The random tokens themselves were observed during completed lab-based testing as being encrypted by examining the files that memory was mapped to. The memory mapped files were examined to ensure that the resulting data was encrypted, as sample of which can be seen here:

0005b3c0 04 b7 24 1d 42 7c 19 06 61 c7 60 82 e2 92 af ae |..$.B|..a.`.....|

0005b3d0 23 85 be c7 e1 64 15 74 47 19 da d8 19 e9 56 68 |#....d.tG.....Vh|

0005b3e0 4e c6 b7 92 e1 59 23 83 38 51 2d 06 95 19 d7 ba |N....Y#.8Q-.....|

0005b3f0 0d 9b dd 9c 22 ac ea 5d a0 a6 90 67 58 1e ed 44 |....”..]...gX..D|

0005b400 05 48 24 ed aa e1 18 f6 07 91 61 72 fb 81 af 5e |.H$.......ar...^|

0005b410 89 83 bf 37 d0 77 14 84 7d 40 db 28 97 9c 56 98 |...7.w..}@.(..V.|

0005b420 00 53 b7 62 6c fc 22 73 87 32 2d f6 b7 2f d6 4a |.S.bl.”s.2-../.J|

0005b430 d2 fd dd 6c 1b 93 ea ad 20 70 91 97 a5 52 ed b4 |...l.... p...R..|

0005b440 2c fd 24 fd d5 84 19 e6 d7 2e 60 62 6f 38 af 4e |,.$.......`bo8.N|

0005b450 f7 2a be 27 0e 72 14 94 e4 e3 da 38 36 93 57 88 |.*.’.r.....86.W.|

0005b460 26 28 b7 72 be a9 22 63 4a ce 2c e6 bd 04 d7 5a |&(.r..”cJ.,....Z|



Page | 6

Tokenization Using RESTFUL API

Application server originating Application Programming Interface (API) commands specifying token group, template, and user access are utilized to tokenize sensitive data. Figure 8 illustrates an example tokenization call made using Token group T2, Token Template “Credit Card,” and user vtsuser1. The Postman API testing tool was used to issue a RESTful API-based tokenize request to the Token Server, resulting in the generation of token 7092-0723-7883-0569.

Restful APIs require authentication using an id and password, as well as encrypting the communication using SSL. These were tested and verified in the POSTMAN application.

Figure 7

Figure 8



Page | 7

Token Masks

An optional masking solution is also incorporated into the detokenizing process to permit a portion of the original sensitive data to be viewed. Figure 10 demonstrates the use of a mask which permits the last four digits of a credit card (R4) and the first three digits of an SSN (L3) to be viewed.

Figure 9

Figure 10

Detokenization Using RESTful API

Figure 11 reflects a RESTful API-based detokenization call made using Tokengroup T2, Token Template “Credit Card,” a generated token, and user vtsuser2. The Postman API testing tool was used to send a detokenize request to the Token Server. The result is a display of the last four digits of the tokenized credit card data in alignment with established masking policy.



Page | 8

Figure 11

Figure 12

Figure 12 also reveals the results of de-tokenizing data which was prior tokenized utilizing the Random template-based tokenization method.



Page | 9

Vormetric Server Operating within a Cardholder Data Environment

In order to maximize risk reduction benefits, the tokenization system should be logically isolated and segmented from the data-processing systems and applications that previously processed the sensitive data (cardholder data) that is being tokenized. Only the tokenization system should be permitted to perform tokenization or detokenization functions.

Network

It is recommended that the Vormetric Token Server and DSM be properly isolated through the use of network segmentation with a stateful firewall used to limit communications between the following:

• The token server and Active Directory/LDAP server(s)

• The token server and application server(s)

• The token server and DNS server(s)

• The token server and central logging server(s)

• Authorized administrators and the Vormetric DSM and/or Token Server

• Authorized administrators and applicable virtual machine(s)/hypervisor(s) created to virtualize the Vormetric DSM and or Token Server

• The Vormetric Data Security Manager and optional RSA SecurID two-factor authentication system(s) Applications requesting data tokenization and/or detokenization should further be isolated within another logical segment. In addition, such systems should not be logically available to any trusted networks or applications, with the exception of those specific client or server components required to access application and database servers.

Note: Servers or databases simply processing the tokens do not have to be part of the illustrated PCI DMZ.

Figure 13



Page | 10

Tokenization Authentication Controls

The Vormetric DSM-based cryptographic key management solution, a critical component of a Vormetric tokenization implementation, supports an optional RSA SecurID-based two-factor authentication solution for administrative access to its management console. It is recommended that this option be used to ensure secure administrative access.

Vormetric Token Server authentication via organizational Microsoft Active Directory or LDAP-based directory services is also strongly recommended.

Token Server Logging

The Vormetric Token Server supports the logging of all system access and administrative privilege use (see Figure 14).

It is recommended that this log data be configured to replicate log data to a centralized logging system, such as a security information and event management (SIEM) system or any other syslog monitoring server. Configuring the Token Server to point to a logging server is as simple as entering the destination IP address and TCP port. Audit and access logs can be redirected.

Figure 14



Page | 11

Summary and Scope Reduction

The Vormetric Token Server, properly implemented and configured within a secured cardholder environment (CDE), can reduce the scope of the systems included in the scope of a PCI DSS assessment. The system can also be leveraged to tokenize other sensitive data within a corporate environment.

Further, based on PCI DSS guidelines, the FF3 mode of FPE utilized by the Vormetric Token Server meets the PCI DSS requirements. The April 2015 SSC tokenization guidelines specify that FPE (FF3 mode) used as a reversible tokenization method complies with PCI DSS cryptographic requirements.

Randomization of tokens enhances the security of the tokenization solution by providing tables which are sufficiently random and unpredictable. Vormetric has placed the tokens in memory, increasing speed of access over disk i/o. By removing the database and practically eliminating disk I/O, performance is increased dramatically over conventional tokenization solutions. Tables in memory hold pre-generated encrypted tokens for every possible PAN. To access them, any intruder must also locate a decryption key. Even if this is possible, the data would be practically worthless. While not impossible, the colossal effort required to compromise PANs in this solution makes it extremely infeasible.

There is no PAN storage. Therefore, depending on the implementation of a tokenization solution, the resulting tokens used within systems may not need the same degree of protection as would be needed with a PAN. The overall security of the tokenization solution is enhanced.

Therefore, depending on the implementation of a tokenization solution, the resulting tokens used within systems may not need the same degree of protection as would be needed with a PAN.

The SSC’s August 2011 Information Supplement: PCI DSS Tokenization Guidelines www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf additionally notes the following:

“Tokenization solutions do not eliminate the need to maintain and validate PCI DSS compliance, but they may simplify a merchant’s validation efforts by reducing the number of system components for which PCI DSS requirements apply. Verifying the effectiveness of a tokenization implementation is necessary and includes confirming that the PAN is not retrievable from any system component removed from the scope of PCI DSS.”

As such, all elements of the tokenization system, including tokenization, detokenization, and PAN storage, are considered part of the cardholder data environment (CDE) and in scope of PCI DSS assessment. Additionally, any system component or process with access to the tokenization system or the tokenization/detokenization process is also considered in scope. However, systems which only handle tokens without access to cardholder data, the detokenization process, or detokenized data may be considered out of scope of the PCI DSS assessment, depending on the company’s tokenization system implementation, including but not limited to system segmentation (e.g., the system may not reside within CDE network segments).

Thus, before a system can be removed from the scope of a PCI DSS assessment, it must not be logically connected to the CDE and must not be able to retrieve or access PAN or other account data. If a tokenization solution can detokenize a ciphered token into the original PAN, the system itself remains in PCI scope. Also, the security of the entire system, including cardholder data capture and authorization, tokenization methodology, storage, use, and subsequent access, is dependent upon merchant and/or service provider tokenization implementation.

https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf

https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf



Page | 12

In Scope: PCI Out of Scope: PCI

Token Servers and supporting system components Application servers storing tokens without access to detokenize tokens

Application servers which can detokenize tokens Databases servers storing tokens without access to detokenize tokens

Administrators on systems who can detokenize tokens

Thus, before a system can be removed from the scope of a PCI DSS assessment, it must not be logically connected to the CDE and must not be able to retrieve or access PAN or other account data. If a tokenization solution can detokenize a ciphered token into the original PAN, the system itself remains in PCI scope. Also, the security of the entire system, including cardholder data capture and authorization, tokenization methodology, storage, use, and subsequent access, is dependent upon merchant and/or service provider tokenization implementation.



Page | 13

Copyright © 2017 Fortrex. All rights reserved. Fortrex is a registered trademark of Fortrex Technologies. All other trademarks are the property of their respective owners. No part of this publication may be reproduced, stored in a retrieval system or transmitted, in any form or by any means, photocopying, recording or otherwise, without prior written consent of Fortrex.

About Thales

Thales e-Security is the leader in advanced data security solutions and services that deliver trust wherever information is created, shared or stored. We ensure that the data belonging to companies and government entities is both secure and trusted in any environment – on-premise, in the cloud, in data centers or big data environments – without sacrificing business agility. Security doesn’t just reduce risk, it’s an enabler of the digital initiatives that now permeate our daily lives – digital money, e-identities, healthcare, connected cars and with the internet of things (IoT) even household devices. Thales provides everything an organization needs to protect and manage its data, identities and intellectual property and meet regulatory compliance – through encryption, advanced key management, tokenization, privileged user control and high assurance solutions. Security professionals around the globe rely on Thales to confidently accelerate their organization’s digital transformation. Thales e-Security is part of Thales Group.

About Fortrex Technologies, Inc.

Since 1997, Fortrex Technologies has served as a trusted security and risk management advisor to its clients throughout the world. Fortrex focuses exclusively on IT security, operational risk and regulatory compliance and helps organizations throughout the world identify, assess, remediate and manage their operational risks through consulting, audit, vendor management and human capital assistance. By providing expert technical assessments, Fortrex ensures the confidentiality, integrity and availability of data and systems through world-class, enterprise-wide information security services and solutions. Powered by a team of security and risk management experts and the industry’s leading technology, Fortrex’s in-depth risk assessments and solutions ensure that its clients’ information assets remain safe and secure.

Fortrex Media Contact:

Douglas Ochs President (240) 575-7700 [email protected]

evaluation of the vormetric token server

Documents