Introduction to Token Service Provider (TSP) Certification
0 likes828 views
The document provides an introduction to Token Service Providers (TSPs) and tokenization, which replaces sensitive card data with secure surrogate values to minimize fraud risks in payment processing. It outlines the requirements, benefits, and process of becoming a TSP, including certification, maintaining security controls, and managing payment tokens. Key topics also include the token payment flow, token data environment, and compliance with industry standards such as PCI DSS.
Introduction to Token Service Provider (TSP) Certification
- 1. Token Service Provider (TSP) An Introduction to Certification Biju John, PCI QSA, PA-QSA, PCI P2PE, PCI PA-QSA(P2PE), P2PE, 3DS VP ControlCase
- 2. Agenda 1 What is Tokenization? What is a Token Service Provider or TSP? Who can become a TSP Benefits of being TSP Business Flow for Payment tokens Scope – Token Data Environment TSP Requirements Assessment and Certification
- 3. 2 The process of replacing sensitive data (Card Data) with surrogate values that remove risk but preserve value to the business. What is Tokenization The tokenization is an added layer of protection in payment processing ecosystem Minimize the fraud exposure of data compromise No changes to existing payment ecosystem
- 4. 3 Different type of Tokens Acquiring Tokens Acquiring tokens are created by the acquirer, merchant, or a merchant’s service provider after the cardholder presents their PAN and/or other payment credentials. It is not based on an industry-standard and cannot be used for new authorizations. Issuer Tokens Issuer tokens, also known as virtual card numbers, are created by issuers and provide the means to reduce risk in specific use cases, including commercial card applications, as well as consumer-oriented services. Payment Tokens Payment tokens are created by TSPs that are registered with EMVCo. Payment Tokens are issued to a cardholder in lieu of a PAN, and the cardholder presents the Payment Token to the merchant when making a purchase. During a Payment Token transaction, the merchant and acquirer do not receive or have access to the corresponding PAN.
- 5. 4 Sample Payment Token 6203011150123456789 ▪ 620301 - BIN ▪ 11 - Card identifier ▪ 5 - Token identifier (0 - production physical card identifier; 99 - test physical card identifier) ▪ 012345678 - random numbers ▪ 9 - Luhn digit Complies with PAN format supporting interoperability within the existing payment processes 13 – 19 Digits Supports ISO 8583 message format
- 6. 5 Any Service provider within the payments ecosystem that is able to provide token requestors for ‘Card Data’ with ‘Surrogate' PAN values… What is a Token Service Provider or TSP? Generates and Manages Payment Token A wholly independent party from the payment network or payment processor. Can be integrated with a payment network or payment processor.
- 7. 6 Token Payment Flow – High-level
- 8. 7 Sample Steps - Registration
- 9. 8 Who can become a TSP? Generate and issue EMV ‘Payment Tokens’ Must be a valid PCI DSS certified entity Must have registered with EMVCo as Token Service Provider Any Service provider within the payments ecosystem such as Issuers, Acquirers and Merchants that wish to offer mobile and/or digital payments to customers can become a TSP.
- 10. 9 Enables them to reduce long term costs, maintain independence and increase flexibility to establish an edge over their competitors. Benefits of being a TSP – Self Assist Provides full control over the tokenization process: creation, storage, issuance and management Full control of digital payments by issuing tokens directly without third party intervention. Reduce long term costs: no additional TSP fees from the payment schemes. Save on transaction fees On-us transactions when you are the issuing as well as the acquiring bank. Banks retain their privacy because data and roadmaps do not have to be shared with the schemes. Keep track of customer payment behavior to gain valuable insight and be able to offer personalized services.
- 11. 10 Comply with set of controls defined based on EMVCo Payment Tokenization Specification Technical Framework and are additional to those in PCI DSS. How to become a TSP Defined as physical and logical security requirements and assessment procedures Requirements developed by PCI SSC and managed by Payment brands Any queries about validating compliance should be directed to the appropriate Payment Brand(s) Not listed by PCI SSC
- 12. 11 Scope: Token Data Environment (TDE) The TDE is a dedicated, secure area within the TSP, where one or more of the following services are performed: ❑Token generation, issuing, and mapping processes (Eg: Token vault) ❑Assignment of token usage parameters (Eg: APIs) ❑Token lifecycle management (Eg: Token vault) ❑Processes to map or re-map tokens, or perform de-tokenization (Eg: Token vault) ❑Cryptographic processes to support tokenization functions (Eg: HSM) ❑Maintenance of underlying token security and related processing controls, such as domain restrictions during transaction processing.
- 13. 12 Token Data Environment (TDE) Example of TDE Implementation TDE as a subnet of CDE Combined CDE and TDE
- 14. 13 TSP Requirements 8 Requirements spread across 12 PCI DSS Requirements These are in addition to PCI Requirements ❑TSP 1 – Document and validate PCI DSS scope ❑TSP 2 – Secure TDE Systems and Network ❑TSP 3 – Protect and manage cryptographic keys ❑TSP 4 – Restrict access to TDE by business need to know ❑TSP 5 – Identify and authenticate all access to TDE systems ❑TSP 6 – Restrict physical access to the TDE ❑TSP 7 – Monitor all access to TDE ❑TSP 8 – Maintain an Information Security Policy
- 15. 14 TSP – PCI Mapping PCI DSS Requirement Additional Applicability for TSPs 1. Install and maintain a firewall configurationto protect cardholder data ▪ Firewall controls in PCI DSS Requirement 1 also apply to internal firewalls usedto separate TDE from non-TDE networks. ▪ The current network and data flow diagrams (PCI DSS Requirements 11.2 and 1.1.3) must also include all connections between the TDE and other networks,and all flows of Payment Tokens across systems and networks in the TDE. 2. Do not use vendor-supplied defaults forsystem passwords and other security parameters ▪ PCI DSS Requirement 2 applies to all system components in the TDE. ▪ Wireless environments are not permitted to be connected to the TDE. 3. Protect stored cardholder data ▪ Data retention and disposal policies, procedures and processes (PCI DSS Requirement 3.1) also apply to Payment Token Data. ▪ Payment Tokens must also be masked when displayed such that only personnel with a legitimate business need can see the full Payment Token (PCI DSS Requirement 3.3), and rendered unreadable wherever they are stored (PCI DSS Requirement 3.4) in the TDE. ▪ The key-management requirements in this document are in addition to thosein PCI DSS Requirements 3.5 – 3.6
- 16. 15 TSP – PCI Mapping PCI DSS Requirement Additional Applicability for TSPs 4. Encrypt transmission of cardholder data across open, public networks ▪ Wireless environments are not permitted to be connected to the TDE. 5. Protect all systems against malware and regularly update anti-virus software or programs ▪ PCI DSS Requirement 5 applies to all system components in the TDE. 6. Develop and maintain secure systems and applications ▪ PCI DSS Requirement 6 applies to all system components in the TDE. ▪ All changes made to system components in the TDE must be in accordancewith PCI DSS Requirement 6.4.5. 7. Restrict access to cardholder data bybusiness need to know ▪ Access to Payment Token Data in the TDE must also be restricted according to principles of need- to-know and least privilege. 8. Identify and authenticate access to system components ▪ Strong authentication controls are required for all accounts used to access Payment Tokens or to access systems in the TDE. 9. Restrict physical access to cardholder data ▪ Physical security controls also apply to secure access to Payment Token Datain the TDE. 10. Track and monitor all access to network resources and cardholder data ▪ Audit log requirements include all individual user access to Payment Token Datain the TDE (PCI DSS Requirement 10.2.1). 11. Regularly test security systems and processes ▪ Internal vulnerability scans, penetration tests (for example, to verifysegmentation controls), intrusion detection, and change detection apply to the TDE. 12. Maintain a policy that addresses information security for all personnel ▪ PCI DSS Requirement 12 also applies to personnel with access to the TDE. TSP PCI TSP1 Scope TSP2 1, 2 TSP3 3 TSP4 7 TSP5 8 TSP6 9 TSP7 10 TSP8 12
- 17. 16 TSP – Encryption All Key-management process must be conducted within HSM which is FIPS 140-2 Level 3 certified or PCI PTS HSM approved Approved algorithms
- 18. 17 Assessment and Certification Assessment must be performed by P2PE QSA TDE must be PCI DSS certified ▪ PCI DSS requirements not applied may be assessed along with TSP engagement and issue a partial ROC All applicable TSP controls must be applied to TDE ▪ Compensating controls can be considered if necessary TSP ROC or T-ROC must be completed as per Reporting Template for PCI DSS v3 Submit T-ROC and T-AOC to brands ▪ Client may do it directly with applicable payment brand
- 19. 18 Why ControlCase? Global Reach ▪ Serving more than 400 clients in 40 countries and rapidly growing Certified Resources ▪ PCI DSS Qualified Security Assessor (QSA) ▪ PA DSS (PA DSS) ▪ QSA for Point-to-Point Encryption (QSA P2PE) ▪ QSA for TSP ▪ QSA for 3DS ▪ Certified ASV vendor
- 20. www.controlcase.com + +1.703.483.6383 (US) +91.9820293399 (India) sales@controlcase.com 19 To Learn More About PCI TSP Compliance
- 22. Thank You for Your Time 21