How To Reduce Pci Dss Scope

Transcription

1 WHITE PAPER Intel Expressway Tokenization Broker PCI DSS Reducing PCI DSS Scope: The Gateway Approach Challenge: Payment applications that handle credit card numbers pull connected systems into PCI DSS scope resulting in increased assessment costs of $500K+/yr. Solution: Gateway generated tokens replace card numbers with surrogates-removing systems from scope. Introduction The goal of the Payment Card Industry Data Security Standard (PCI DSS) is to ensure the safeguarding of payment card data among retailers, e-commerce merchants, banks and other businesses that directly handle card data. To accomplish this, PCI DSS specifies increased controls and protection for information systems that store, process or transmit credit card account numbers and related data such as expiration dates, card-not-present (CNP) verification codes, and customer names. Highervolume merchants or other card-handling Figure 1 PCI Tokenization Value Proposition organizations are required to complete annual on-site compliance assessments by independent Qualified Security Assessors (QSAs). If organizations don t take appropriate action, fines imposed by the credit card brands for PCI non-compliance can amount to $500,000 per incident (and include other potential liabilities), particularly when organizations are found to be non-compliant at the time of significant data breach incidents. Payment Processors Authorization Request Authorization Code Secure Token Vault Authorization Request Token ( ) Authors: Blake Dournaee Intel SOA Products Group Brad Corrion Intel Retail & Banking Security- Embedded & Communications Group Merchant Middleware On-Premise Infrastructure Original PCI Scope Reduced PCI Scope

2 Intel PCI DSS White Paper Table of Contents Introduction Why Choose Intel Expressway Tokenization Broker? Tokenization Broker as Tokenization Engine Tokenization Broker as Tokenization Service Tokenization with Encrypted Storage Tokenization Broker for Credit Card Tokenization Tokenization Broker Addresses PCI DSS Requirements Introduction (continued...) Organizations that process credit card information are confronted with the issue of PCI DSS scope, which refers to all of the components of a computing network directly or indirectly handling card data. These network components are a primary focus of PCI DSS regulation, compliance and assessment. Any information system such as a database, web server, or application server that handles a credit card number can immediately be pulled into PCI scope and become the focus of an assessment. Other systems and servers interacting with systems in scope can then be pulled into scope. One of the primary ways to counter the cost and organizational burden of PCI DSS compliance is to reduce overall scope within the enterprise, and the only way to reduce scope is to eliminate accessibility to sensitive card data in the first place. Otherwise, the organization needs to bring all related systems up to specification. In both cases, retrofitting existing code, managing database encryption, and re-architecting applications to securely handle credit card information can be both costly and risky in terms of engineering investment and the impact to organizational structure and changes to business operating practices. A viable alternative to this costly retrofitting is to introduce an application-level security gateway into the architecture that offers end-to-end data protection, session security, physical security, and credit card tokenization capabilities. If credit card processing capabilities are centralized in a single place, the rest of the application architecture can benefit from reduced PCI scope, with minimal or no impact to existing business practices. This shifts the PCI scope from your enterprise application suite to a hardened security device, centralizing and limiting the attention and investment your organization devotes to managing compliance. A viable alternative to costly PCI retrofitting is to introduce an application-level security gateway into your architecture that offers end-to-end data protection, session security, physical security, and credit card tokenization. 2

3 Why Choose Intel Expressway Tokenization Broker? Intel Expressway Tokenization Broker (Tokenization Broker) is a software product delivered in a secure hardware appliance form-factor that can be used to help reduce PCI compliance scope. It can act as a token transformation engine or tokenization service for payment applications or other enterprise information systems tasked with handling clear-text primary account number (PAN) data. The appliance product is specially designed for merchants, e-tailers and enterprises across different vertical markets who have a need to maintain and control primary account number data on-premise, or are forced to handle clear-text card numbers as part of a billing system, data warehouse or supply-chain application. Tokenization Broker can handle simple transformation cases to replace credit card numbers with tokens, or act as a secure proxy involved in authorization requests to credit card processors using standardsbased interfaces, such as HTTP, SOAP, and WSDL. In addition to standard protocols, Tokenization Broker can be flexibly tailored to a wide variety of legacy installations and data formats, such as print and document formats. Figure 2 demonstrates how Expressway can be deployed to solve a basic token transformation use case. In Figure 3, Tokenization Broker is shown as a transformation engine used to cleanse input data, replacing PAN information with tokens. This usage model applies in cases where organizations possess billing data or other customer information containing PAN data and need immediate relief from compliance scope for legacy applications. It also shows the reverse process, called de-tokenization, which is used when the PAN data are required by a recipient or application. This is the reverse transformation, where Tokenization Broker replaces tokens with PANs. In addition to shielding the downstream infrastructure from PCI scope, the gateway provides comprehensive logging and audit for all inbound and outbound requests, acts a secure point of entry and exit between internal and external card processing networks, and protects the infrastructure against malicious traffic, denial of service attacks, and other content-borne threats. Moreover, the gateway is based on a simple, configuration-based editor that reduces integration efforts and provides a useful abstraction layer from the various payment processors and their array of HTTP, SOAP or XML interfaces. It encrypts clear-text PAN data in a security vault and provides secure interfaces for PAN data access through authenticated API calls. The basic transformation case can be extended to a payment processing application displayed in the following figure. Figure 2 Tokenization Broker as Tokenization Engine Tokenization Process Customer-Managed Secure Token Vault Step #1: Input documents or messages contain clear-text primary account number (PAN data). IN PCI SCOPE Step #2: Expressway generates secure, fixed-length tokens in place of PAN data. Step #3: Downstream applications receive tokens-instead of PANs-and are out of compliance scope. REMOVED FROM PCI SCOPE De-Tokenization Process Customer-Managed Secure Token Vault Step #1: Output documents containing tokens are generated by legacy applications. Step #2: Expressway replaces tokens with PAN data. Step #3: Output documents containing PAN data are delivered to end-recipient(s). REMOVED FROM PCI SCOPE IN PCI SCOPE 3

4 Figure 3 Tokenization Broker as Tokenization Service Step #1: A credit card PAN is captured during an e-commerce transaction. Step #2: Authorization request containing the PAN is sent to the transaction server. Step #3: Authorization request containing the PAN is sent to the payment processor. Transaction Server Step #4: A response is returned from the payment processor. Step #5: Upon success, the transaction server requests a token for this transaction and provides the transaction ID as a key. Payment Processor In PCI Scope Removed from PCI Scope Customer-managed Secure Token Vault Step #6: Fixed-length token is returned from the Tokenization Broker to transaction server. PCI Scope: Legacy applications that may need PANs can retrieve them from the Tokenization Broker with a secure API based on a transaction ID or token. Step #7 (Removed from PCI Scope): The transaction server pushes tokens - rather than PANs - to legacy applications for tracking purposes. Removed from PCI Scope: Legacy applications receive tokens rather than PANs and are out of compliance scope. In Figure 3 above, credit card authorization requests flow normally to a transaction server. Upon receiving a response, the server requests a token for this transaction and provides a transaction ID to Tokenization Broker as a key. Tokenization Broker encrypts the PAN data, stores it in a secure vault, and then generates a secure token that is made available to the transaction server through a Java API or web service call. The token, in place of the original PAN, can be used throughout the legacy network without regard to PCI DSS scope as long as the systems handling the tokens have no means to redeem the token in exchange for the original PAN data. Tokenization Broker provides the access controls and authorizations required to control the de-tokenization process, and thus permit the administrator to explicitly determine what systems are in- or out-of- scope. The token can be used to manage additional transactions such as returns or recurring charges, and the use of the token protects the downstream middleware from additional PCI scope. By concentrating the storage of PAN data in a secure token vault the original PCI scope can be reduced to the gateway and other authenticated applications that require the original PAN data. Moreover, the gateway can also connect to existing merchant security and identity management systems to apply additional access control, threat scanning, authentication, or authorization checks as needed. 4

5 Tokenization with Encrypted Storage Most merchants and payment application providers are rallying around either end-to-end encryption or tokenization as methodologies to protect card data and/or reduce PCI DSS scope within their organizations. While both methods are considered acceptable (when deployed correctly) for PCI DSS scope reduction purposes and both methods appear to be rooted in different motivations, more similarities exist than differences. Both have the intent of removing sensitive PAN data from non-payment-related corporate networks, both typically prescribe a PAN compatible substitution for use by legacy systems expecting PAN data, both utilize practical and modern encryption technologies to protect the PAN data, and finally, both strive to allow access to the original clear text PAN data only to parties that require it, namely card processors. The differences are more subtle, and typically involve the decision to either encrypt the data at collection, or encrypt the data in flight until the data are encrypted for storage further upstream. Another key difference is how the substitute PAN can be redeemed for the original PAN: Does the requester need authenticated, authorized access to a redemption service, or does the requestor need to have access to a private key which can provide the decryption? Either way, both require well thought-out access controls and restrictions, and/or key management policies. Tokenization Broker can play an important part in either methodology, but is particularly well-suited as a tokenization solution. Tokenization Broker combines all of the required technologies for encrypting data at rest, encrypting data in-transit, integrating with databases and communicating with legacy systems, along with the benefits associated with a secure appliance form factor. Downstream systems provide, via an encrypted connection, the original PAN data to Tokenization Broker. Tokenization Broker uses hardware-generated cryptographic keys to protect credit card data. The encrypted number is then paired with a randomly assigned token and stored for future reference in a database local to the appliance. The token is made available to the out-of-scope enterprise applications to be used with legacy systems or when future transactions are required. Figure 4 shows the underlying tokenization engine provided by Tokenization Broker and explains how it works. Tokenization Broker combines the required technologies for encrypting data at rest and data in transit, integrating with databases and communicating with legacy systems, along with the traditional benefits associated with a secure appliance form factor. 5

6 Figure 4 Tokenization Broker for Credit Card Tokenization Intel Expressway Tokenization Broker (Optional FIPS Level 3, Common Criteria EAL 4+) Input Document or Message Output Document or Message Input documents containing clear-text credit card numbers may arrive in any format, XML or non-xml. Tokenization Broker Workflow Engine Secure Token Generation Service Secure Data Access Layer Hardware-based Random # Generation Secure Token Management API Output documents contain format-preserving tokens rather than PAN data. Encrypted Card # Token NTU2Nzg2NzQxMjM0Njc4Mw== YTG2Nzg5NzQxfrM0NiowMr== Customer-Managed Secure Token Vault In Figure 4, Tokenization Broker receives input documents in any format, either in XML or in non-xml formats such as print, document or text data. The data are classified to a policy that replaces credit card data in specific fields or segments with format-preserving tokens through a data transformation step. The data transformation step accesses the secure token generation service, to generate the necessary amount of random data and create a format preserving token for the PAN. The original PAN is encrypted by Tokenization Broker and the pair is stored in a secure token vault, which is a database accessible via JDBC over SSL. While the secure token vault is owned and managed by the customer, Tokenization Broker provides the necessary schemas for the secure vault. Once the format- preserving token is generated, the original PAN data is replaced with the token and the message is sent to downstream systems. Tokenization Broker also provides a secure token management API that enables common functions including token retrieval, PAN retrieval, token deletion and re-tokenization. This secure API only allows authenticated user access and can be integrated with existing enterprise identity management systems such as LDAP, Active Directory, SiteMinder, and others. In addition to tokenization and encryption, Tokenization Broker has a number of features that can be used by merchant applications to help meet the diverse requirements of PCI DSS. 6

7 Tokenization Broker Addresses PCI DSS Requirements 2 PCI REQUIREMENT PCI SUB-REQUIREMENT TOKENIZATION BROKER S CAPABILITIES Build and Maintain a Secure Network Protect Cardholder Data Maintain a Vulnerability Management Program Implement Strong Access Control Measures Install and maintain a firewall configuration to protect cardholder data. Do not use vendor-supplied defaults for system passwords and other security parameters. Protect stored cardholder data. Encrypt transmission of cardholder data across open, public networks. Use and regularly update anti-virus software or programs. Develop and maintain secure systems and applications. Restrict access to cardholder data by business need to know. Assign a unique ID to each person with computer access. Restrict physical access to cardholder data. Tokenization Broker provides full application-level security proxy and firewalling capabilities. Tokenization Broker protects credit card data stored at rest in a database or in transit between applications and can support tokenization schemes for reducing PCI scope. Tokenization Broker can facilitate secure applications by integrating with on-premise virusscanning servers to reduce the threat of malicious attachments. Tokenization Broker supports strong access control policies by integrating with existing identity management investments and improving the physical security for credit card tokenization through its tamper-resistant form-factor. Regularly Monitor and Test Networks Maintain an Information Security Policy Track and monitor all access to network resources and cardholder data. Regularly test security systems and processes. Maintain a policy that addresses information security for employees and contractors. Tokenization Broker tracks, monitors and logs authorization requests from the merchant to the card processor with regular testing and alerts in the event of server failures. Tokenization Broker maintains auditable security policies in a single, hardened form-factor allowing for convenient review and change control for cardholder protection. For more product information: For product comparison information and to register for Webinars: Contact us by phone: Americas: All other Geographies: Contact us by intelsoainfo@intel.com 1 Original PAN data are generally tokenized by replacing the first 12 digits, leaving the last four in the clear. Some usage models may require leaving the first six digits in the clear. 2 For further details about PCI DSS, consult the PCI Security Standards Council s Web site, at the following link: INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked reserved or undefined. Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice.do not finalize a design with this information. The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order. Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling , or by visiting Intel s Web site at Copyright 2011 Intel Corporation. All rights reserved. Intel, the Intel logo, and Xeon are trademarks of Intel Corporation in the U.S. and other countries. *Other names and brands may be claimed as the property of others. Printed in USA Please Recycle US 7

8