InstaMed Payments with Encryption Payment Card Industry (PCI) Technical Assessment White Paper

Transcription

1 InstaMed Payments with Encryption Payment Card Industry (PCI) Technical Assessment White Paper September 04 White Paper Author: Nick Trenc QSA, PA-QSA White Paper QA: Richard Fleeman CISSP, QSA, PA-QSA pg.

2 Table of Contents Executive Summary... 3 Overview... 5 About the Payment Card Industry Security Standards Council (PCI SSC)... 5 What happens if I don t comply with PCI standards?... 5 PCI in Healthcare... 6 What s New in Payment Card Technology?... 6 What is EMV?... 6 What about Mobile Payments?... 7 Point-to-Point Encryption... 8 InstaMed Healthcare Payment Solutions... 9 Cardholder Data Environment Summary... 9 About InstaMed Payments with Encryption... 9 Deployment Scenarios... 0 Network Diagram... Audience... Assessment Scope... Methodology... Merchant PCI Compliance Scope... Technical Security Assessment... Summary Findings... 4 Impact on Merchant s PCI DSS Audit Applicable Controls... 5 Summary Chart of Potential Impact on Merchant Audit Applicable Controls Table... 5 Key to Potential Impact on Applicable Controls Table... 6 Potential Impact on Applicable Controls Table... 6 Coalfire Assessment Information Assessment Environment Disk Analysis Network Traffic Assessment Tools and Techniques pg.

3 Executive Summary The healthcare industry has been evolving rapidly in recent years, especially with changes in healthcare reform and the increased focus on consumers, especially when it comes to payment. Healthcare providers and payers are becoming merchants who are focused on delivering consumer-friendly payment options in order to efficiently collect the co-pays, deductibles or premiums they are owed. As healthcare organizations accept electronic payments through more and more payment channels, they expose themselves to increased risks, and must be aware of the best practices and requirements in order to protect their businesses. InstaMed, the leading Healthcare Payments Network, connects to healthcare providers and payers for healthcare payment transactions. InstaMed s mission is to streamline payment processes in healthcare to promote efficiency and help businesses to thrive, by delivering new and innovative payment channels to the healthcare industry. InstaMed engaged Coalfire Systems Inc. (Coalfire), a respected Payment Card Industry (PCI) Payment Application Qualified Security Assessor (PA-QSA) company, to conduct an independent technical assessment of InstaMed Payments with Encryption to assess the security of its payment solutions for providers and payers. The following findings are relevant highlights from this assessment. InstaMed Payments with Encryption integrates securely with any web-based computer that has access to InstaMed Online without exposing cardholder data to other systems. In order to reduce the amount of applicable controls during a PCI DSS audit, the PTS-approved MagTek devices must be the only point where cardholder data is captured, either through swiped or keyed entry. InstaMed Payments with Encryption with secure point of interaction (POI) devices could alleviate any applicable controls involved with the PCI DSS compliance requirements for network firewall, network configuration, physical controls or administrative procedures for a merchant. When InstaMed Payments with Encryption is properly deployed, it can almost completely eliminate the risk of a data breach and is one of the most effective data security controls available to merchants today. The integration of the MagTek devices with InstaMed Online is quick, requires very little configuration and works effectively with all post-authorization, sales and refund transactions tested. To best mitigate security and compliance risk, a merchant s deployment architecture must: ) have all cardholder data captured by a MagTek device via InstaMed Online; and ) communicate directly with a PCI DSS-compliant service provider and/or processor that manages all decryption services for the merchant. A merchant can reduce the amount of applicable controls of PCI DSS compliance requirements pg. 3

4 required for the majority of its CDE if all cardholder data is captured by the MagTek devices and no decryption appliances or decryption keys exist in the merchant s CDE. pg. 4

5 Overview About the Payment Card Industry Security Standards Council (PCI SSC) The PCI Security Standards Council is a group founded by the five major payment card brands American Express, Discover, JCB, MasterCard and Visa tasked with developing and managing various standards, including the PCI Data Security Standard (PCI DSS), Payment Application Data Security Standard (PCI PA-DSS), Point-to-Point Encryption (PPE) Solution Requirements and Testing Procedures and PIN Transaction Security (PCI PTS). These security standards set the rules that must be followed by merchants, issuing banks, software developers, hardware manufacturers and all other entities involved in the processing, storage or other handling of credit card data. Merchants must ensure that they only do business with service providers who are compliant and certified with the PCI DSS. The PCI DSS process for certifying merchants and service providers is an in-depth audit of security policies, procedures, and environments against a specific set of requirements that provide a very baseline level of information security. This standard applies not only to merchants who accept credit card payments, but also to service providers (those entities that process, store or transmit cardholder data as part on behalf of merchants) such as InstaMed. The PCI PA-DSS standards apply to vendors wishing to develop software that accepts payments in the form of credit cards and ensures that these developers create a software product that will function within a PCI DSS compliant merchant environment. While merchants are not required to use software that has been PA-DSS validated, it is highly recommended to do so in order to help ensure that the PCI DSS requirements are able to be met. Some card brands mandate the use of a PA-DSS validated application for their merchants. Finally, the PCI SSC sets forth requirements for PIN Transaction Security (PTS) devices and PPE. The PTS is a set of requirements that PIN pad hardware manufacturers must abide by when creating these devices. While the SSC doesn t require the use of a PTS validated device, devices that have been validated typically offer better security and protection for cardholder data. PPE requires the use of PTS devices and is intended to shift the burden of compliance away from the merchant and to the service provider by protecting cardholder data with encryption at the point of swipe and decryption at a PPE service provider. What happens if I don t comply with PCI standards? Merchants who do not comply with applicable PCI standards expose themselves to the risk of data pg. 5

6 breaches. If you handle both cardholder data and personally identifiable information you greatly increase the likelihood of becoming a target for data breaches. A data breach could increase the chances for lawsuits, reputational damages, government fines and many other consequences. For example, in 03, a major retail corporation experienced a payment card breach that resulted in a 46 percent decline in profit. Another key benefit of following the PCI standards is that it could lead you to be better prepared for other regulatory audits such as HIPAA, SOX, etc. PCI in Healthcare As healthcare costs continue to increase, patient payment responsibility for healthcare bills has also increased. More and more patients are being forced to cover medical payments on credit card accounts. In addition to this, the healthcare industry has started moving toward electronic transactions to improve billing efficiency. For both of these reasons, the use of payment cards in healthcare is drastically increasing. Payment cards are becoming a common payment method for consumer-to-provider, consumer-to-payer and payer-to-provider payments. When providers and payers accept payment cards, they expose themselves to increased security risk, and at a minimum they must ensure that they maintain compliance with all applicable PCI standards. What s New in Payment Card Technology? With the recent breaches in the U.S., many merchants are trying to understand how to protect against these risks. No one solution provides a silver bullet but taken together, PPE, tokenization and EMV offer a strong defense against today s threats. What is EMV? EMV, often referred to as chip and PIN, is slowly gaining traction in the United States. Conceived in 994 and formalized in 999 by Europay, MasterCard and Visa, EMV is a framework that calls for integrating a microprocessor or chip into an otherwise normal credit card. This microprocessor allows for functionality that normal credit cards could not have. The benefits of EMV include: Fraud protection In the event of a breach, card-present fraud is likely to be eliminated. (Please note that card-not-present transactions are not made more secure by this technology. Card-notpresent includes online transactions.) Liability shift Details vary by merchant, but as of October 05, a merchant who has not implemented EMV may be financially liable for any card-present fraud that could have been prevented with the use of EMV at the point-of-sale (POS). pg. 6

7 An EMV transaction occurs a little differently than normal transactions. Instead of simply swiping a card, a consumer must dip or insert their card into a PIN device, and enter a PIN before a transaction is processed. It is important to note that using EMV does NOT secure credit card data; it simply provides assurances to the merchant and financial institutions that have it in place that the user of a credit card is the true owner of the card. While not currently required, many healthcare organizations are evaluating solutions that support EMV in order to ensure compatibility with these future requirements. What about Mobile Payments? Healthcare organizations are beginning to use mobile devices to accept payments in order to simplify the collection of consumer payments and to deliver consumer-friendly payment options. Healthcare organizations that recognize this are benefitting by delivering a smoother consumer experience and collecting payments faster. However, mobile payments create major risks to the healthcare industry from a security and compliance perspective. The most significant of these risks is a compromised device that has been taken over by malware that circumvents the security of the device and allows hackers access to the mobile device s data. A second important risk is the fact that mobile devices are portable, making it easy for these devices to be removed from a secured environment to a location where a malicious individual can work to gain access. Finally, mobile technology is still relatively new, and we are still learning about the potential vulnerabilities contained within mobile operating systems and applications. To combat these risks when it comes to accepting mobile payments, PCI has issued mobile guidance documentation for merchants seeking to accept payments on a mobile device within their environment, as well as guidance to developers who are designing mobile solutions. PCI s preferred solution for accepting payments via mobile devices is the use of a validated PPE solution. Furthermore, PCI recommends the following guidelines for merchants:. Prevent unauthorized physical device access (physically lock or tether the device). Prevent unauthorized logical access (restrict who can use the device, set a password or code to unlock the device, and implement encryption of the disk drive) 3. Protect the device from malware (use security software, install only trusted software) pg. 7

8 4. Ensure the mobile device is in a secure state (scan devices with security software, do not jailbreak or root the device) 5. Disable unnecessary device functions (turn off cell data, Bluetooth or NFC if not needed) 6. Detect loss or theft (mark the device with a unique identifier, set GPS boundaries for the device, set periodic reauthentication of the user) 7. Ensure secure disposal of old devices (remove any business identification, contract a vendor to securely dispose of the device) See Merchants_v.pdf for the full guidelines. Point-to-Point Encryption Almost all healthcare organizations now accept payment cards as a payment method. However, data breaches are a major risk when accepting payment cards, which result in monetary and reputational damages. A security solution that organizations should consider is the use of PPE to reduce applicable controls of the PCI DSS. PPE is a methodology for securing credit card data by encrypting it from the time a card is swiped until it reaches the payment processor where it is decrypted. When implemented properly, these types of solutions make payment card transactions more secure by preventing the theft of credit card data while unencrypted on a POS device, or in transit. Merchants large and small face the high risk of a data breach, most frequently caused by inadequate security controls or insecurely developed and deployed applications, which leak or allow access to sensitive cardholder data. Security professionals, service providers, application developers and hardware manufacturers are working across a number of security domains to address the data security needs of merchants. One of the leading solutions intended to address the security of cardholder data in the merchant network is point-to-point encryption. Point-to-point encryption is designed to encrypt cardholder data at the time of swipe point-of-interaction (POI) utilizing an encryption key that is built in to the POI. Once encrypted, sensitive cardholder data is not decrypted until it arrives at a secured end point, typically an acquirer, processor or gateway. In a welldesigned PPE workflow, the merchant has no access to cryptographic keys or the decryption process. By encrypting cardholder data at the POI, merchants can significantly reduce the risk of a data breach and the scope of PCI DSS compliance requirements. pg. 8

9 InstaMed Healthcare Payment Solutions InstaMed engaged Coalfire Systems Inc. (Coalfire), a respected Payment Card Industry (PCI) Payment Application Qualified Security Assessor (PA-QSA) company, to conduct an independent technical assessment of InstaMed Payments with Encryption. Coalfire conducted assessment activities including technical testing, architectural assessment and compliance assessment. In the following document, Coalfire will describe how InstaMed Payments with Encryption, integrated with the PCI PIN Transaction Security (PTS) approved MagTek secure payment card devices for PPE, can reduce a merchant s PCI Data Security Standard (DSS) requirements scope when properly configured using InstaMed s Implementation Guide. Cardholder Data Environment Summary The PCI DSS guidelines require compliance within a merchant s cardholder data environment (CDE), which includes all systems, connecting systems and devices that store, transmit or process cardholder data. To reduce the scope of PCI DSS compliance requirements, a merchant can segment its network in order to separate the systems that store, transmit or process cardholder data from those that do not. This method removes systems that are unrelated to payment card processing from PCI DSS scope. To further reduce scope, a merchant can implement PPE to isolate the CDE to the POI. Implementing PPE can have a significant impact on the scope of a merchant s CDE. PPE encrypts cardholder data when the card is swiped or keyed at the POI, then transmits it to an outside gateway processor (in this case, InstaMed) for decryption. When implemented correctly, PPE logically segments the encrypted data that passes across the network, since the merchant does not access this data. This process reduces the need to utilize network segmentation to remove systems from CDE scope. Finally, since the cardholder data must be decrypted, most PPE devices tie the merchant to the gateway processor (again, in this case, InstaMed) in order to complete the payment transaction. About InstaMed Payments with Encryption MagTek s devices can be configured for user authenticated login, and single sign on (SSO) to InstaMed Online. All cardholder data is captured by the MagTek devices and encrypted when the merchant swipes or keys in the card information at the POI. InstaMed decrypts and transmits the cardholder data to the appropriate payment network to authorize and complete the transaction. Components required for InstaMed Payments with Encryption are:. InstaMed Online. MagTek secure payment card POI devices: pg. 9

10 PCI PTS-approved MagTek DynaPro Debit/Credit MSR with MagneSafe PCI PTS-approved MagTek IPAD Debit/Credit MSR with MagneSafe MagTek Dynamag MSR USB Keyboard Emulator MagneSafe swipe MagTek Dynamag MSR USB HID MagneSafe swipe MagTek udynamo MSR headphone jack for mobile devices (also includes USB for Windows/Mac PCs) Device Features MagTek DynaPro Secure PIN-entry device MagneSafe secure card reader authenticator PCI PTS approved EMV L, L contact; EMV L contactless support (optional) Real-time electronic signature capture (optional) MagTek IPAD PCI PED approved USB powered Triple DES encryption Remote key injection USB HID/keyboard emulation options MagTek DynaMag Secure Card Reader Authenticator (SCRA) Up to three tracks USB HID/keyboard emulation options USB powered Triple DES encryption Tokenization MagTek udynamo SCRA Adjustable stabilizer for a variety of devices Triple DES encryption USB interface Headphone jack interface Deployment Scenarios There are two possible deployment scenarios for InstaMed Payments with Encryption: ) user authenticated login to InstaMed Online; and ) SSO to InstaMed Online. It is important to note that, between the two scenarios, there are no differences in how the cardholder data is captured and encrypted at the POI. pg. 0

11 The data flow diagrams below depict InstaMed Payments with Encryption workflow. Once the payment card is swiped or keyed into the MagTek devices, it is encrypted and transmitted to InstaMed Online. At this point, InstaMed decrypts the cardholder data using MagTek s Magensa Services, and then repackages it for transmission to the payment network. When a transaction occurs, cardholder data is only captured and transmitted by the MagTek Dynamag and IPAD terminals. As a result, InstaMed Payments narrow the scope of the PCI DSS compliance requirements, since no other systems capture and transmit cardholder data. Additionally, all cardholder data is encrypted when the payment card is swiped or keyed, and merchants have no access to this data. Network Diagram Figure : InstaMed Payments with Encryption workflow with cardholder data entry via MagTek s devices A typical transaction:. Merchant logs in to InstaMed Online.. Merchant creates a single or payment plan entry for client and indicates amount of payment. 3. Merchant swipes payment card (Dynamag, udynamo or IPAD) or keys in (IPAD or DynaPro) cardholder data. pg.

12 4. Cardholder data is encrypted at the POI and transmitted to InstaMed. 5. InstaMed decrypts the cardholder data using MagTek Magensa Services, then repackages the data. 6. InstaMed transmits the unencrypted cardholder data to the payment network via SSL. 7. The payment network transmits a response (approval or decline) back to InstaMed. 8. InstaMed forwards the response to the merchant through InstaMed Online. Audience This white paper has two target audiences:. Merchants and service providers interested in PPE to reduce PCI DSS compliance scope.. The QSA and Internal Audit community that is evaluating InstaMed Payments with Encryption or the impact on scope of PCI DSS compliance in general on behalf of merchant or service provider clients. Assessment Scope Coalfire assessed the critical elements that validate the security and effectiveness of InstaMed Payments with Encryption. As part of this assessment, Coalfire conducted in-depth analysis of essential compliance fundamentals for merchants, service providers and the QSA community. Methodology Coalfire uses industry best practices in its assessment and testing methodologies, including standard audit methods. Coalfire conducted technical lab testing on InstaMed s user acceptance testing (UAT) online environment with a remote Coalfire lab system, examination of the MagTek device integration with InstaMed Online, transactional testing, device assessment and forensic analysis. Merchant PCI Compliance Scope There will always be certain controls for PCI DSS compliance that must be independently assessed in any merchant s environment. PCI DSS compliance will always apply to a merchant that transmits, processes or stores cardholder data anywhere in its physical environment. By properly implementing the InstaMed Payments with Encryption, a merchant can potentially lower the amount of applicable controls during a PCI DSS compliance audit. Technical Security Assessment Coalfire s technical security assessment included a comprehensive set of administration, technical and physical control requirements for each deployment scenario (user authenticated login or SSO to InstaMed Online). During this assessment, Coalfire validated that InstaMed adheres to the applicable compliance control requirements for potentially reducing the applicable controls during a merchant s PCI DSS pg.

13 compliance audit. The assessment included the following components: InstaMed Payments with Encryption with InstaMed Online MagTek secure readers: o MagTek DynaPro Debit/Credit MSR with MagneSafe (PCI PTS 3.x approved, EMV Compatible) o MagTek IPAD Debit/Credit MSR with MagneSafe (PCI PTS.x approved) o MagTek Dynamag MSR USB Keyboard Emulator MagneSafe swipe o MagTek Dynamag MSR USB HID MagneSafe swipe o MagTek udynamo MSR headphone jack for mobile devices (also includes USB for Windows/Mac PCs) pg. 3

14 Summary Findings The following findings are relevant highlights from this assessment. InstaMed Payments with Encryption integrates securely with any web-based computer that has access to InstaMed Online without exposing cardholder data to other systems. In order to reduce the amount of applicable controls during a PCI DSS audit, the PTS-approved MagTek devices must be the only point where cardholder data is captured, either through swiped or keyed entry. InstaMed Payments with Encryption with secure POI devices could alleviate any applicable controls involved with the PCI DSS compliance requirements for network firewall, network configuration, physical controls or administrative procedures for a merchant. When InstaMed Payments with Encryption is properly deployed, it can almost completely eliminate the risk of a data breach and is one of the most effective data security controls available to merchants today. The integration of the MagTek devices with InstaMed Online is quick, requires very little configuration and works effectively with all post-authorization, sales and refund transactions tested. To best mitigate security and compliance risk, a merchant s deployment architecture must: ) have all cardholder data captured by a MagTek device via InstaMed Online; and ) communicate directly with a PCI DSS-compliant service provider and/or processor that manages all decryption services for the merchant. A merchant can reduce the amount of applicable controls of PCI DSS compliance requirements required for the majority of its CDE if all cardholder data is captured by the MagTek devices and no decryption appliances or decryption keys exist in the merchant s CDE. pg. 4

15 Impact on Merchant s PCI DSS Audit Applicable Controls PCI DSS compliance will always apply to a merchant that transmits, processes or stores cardholder data anywhere in its physical environment. However, by properly implementing InstaMed Payments with Encryption, a merchant may be able to reduce the amount of applicable controls during a PCI DSS compliance audit. NOTE: The reduction of applicable controls introduced in the table below only applies to PTS-approved (.0 or greater at a minimum) devices such as the MagTek ipad Debit/Credit MSR and MagTek DynaPro Debit/Credit MSR that are supported by InstaMed. Reduction of applicable controls for all other supported devices (Dynamag and udynamo) is entirely at the discretion of a merchant s acquiring bank during PCI DSS audits. Summary Chart of Potential Impact on Merchant Audit Applicable Controls Table NOTE: Any requirement with more than one impact box checked means that part of the controls fall under one category of impact while the rest of the controls fall under the other. Major Impact indicates the most reduction in applicable controls and the most risk reduction for the merchant. PCI DSS Requirement Section Major Impact Moderate Impact Low Impact No Impact X X 3 X X 4 X 5 X 6 X X 7 X 8 X 9 X X 0 X pg. 5

16 X Key to Potential Impact on Applicable Controls Table Applicable Control Level Description Properly implemented, this solution could greatly lower the amount of applicable controls during a PCI DSS audit. Depending on the merchant s CDE, some validation from the QSA may still be required. Properly implemented, this solution could somewhat lower the amount of applicable controls during a PCI DSS audit. Depending on the merchant s CDE, some validation from the QSA may still be required. Potential Impact on Applicable Controls Table NOTE If a specific requirement is not listed, then that requirement is either not or only slightly impacted by proper implementation of the InstaMed Payments with Encryption solution, and will probably still be applicable during a PCI DSS audit. PCI DSS Requirements Version 3.0 Key Comments Requirement : Install and maintain a firewall configuration to protect cardholder data..3.5 Do not allow unauthorized outbound traffic from the CDE to the Internet..3.7 Place system components that store cardholder data (such as a database) in an internal network zone, segregated from the DMZ and other untrusted networks. Managing all outbound traffic can be difficult in a large, distributed environment. While this control is still applicable, compliance can be simplified because the merchant can simplify the rule sets to ensure that encrypted traffic is passed directly to InstaMed. Since there is no cardholder database, segmentation is not required. However, separating any database from the DMZ so that it is not directly accessible is a best practice pg. 6

17 .4 Install personal firewall software on any mobile and/or employee-owned computers with direct connectivity to the Internet (for example, laptops used by employees), which are used to access the organization s network. Requirement : Do not use vendor-supplied defaults for system passwords and other security parameters.. Always change vendor-supplied defaults and remove or disable unnecessary default accounts before installing a system on the network.. Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards. Sources of industry-accepted system hardening standards may include, but are not limited to: Center for Internet Security (CIS) International Organization for Standardization (IOS) SysAdmin Audit Network Security (SANS) Institute National Institute of Standards and would still be recommended. This requirement can be significantly reduced since most mobile/employee computers should not have access to the limited components in the CDE. Only specific IT administrators should have access to critical components in the CDE, and their mobile devices should have personal firewalls installed. The applicable controls for this requirement can be significantly reduced because almost all merchant devices, servers and workstations can be removed from testing as they do not process or store cardholder data and this control does not apply to them. However, this requirement will still apply to perimeter firewalls/ids/routers/wireless in the merchant environment. See. pg. 7

18 Still applies to perimeter network systems only. Still applies to perimeter network systems only. Technology (NIST).. Enable only necessary and secure services, protocols, daemons, etc., as required for the function of the system...3 Implement additional security features for any required services, protocols, or daemons that are considered to be insecure for example, use secured technologies such as SSH, S-FTP, SSL, or IPSec VPN to protect insecure services such as NetBIOS, filesharing, Telnet, FTP, etc...4 Configure system security parameters to prevent misuse. Still applies to perimeter network systems only...5 Remove all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers..3 Encrypt all non-console administrative access using strong cryptography. Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other nonconsole administrative access. Requirement 3: Protect stored cardholder data. 3. Keep cardholder data storage to a minimum by implementing data-retention and disposal policies, procedures and processes that include at least the following for all CHD storage: Still applies to perimeter network systems only. Still applies to perimeter network systems only. No cardholder data is stored in the merchant s environment with this solution. Limiting data storage amount and retention time to that which is required for legal, regulatory, and business requirements. Processes for secure deletion of data when no longer needed. Specific retention requirements for pg. 8

19 cardholder data. A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention. 3. Do not store sensitive authentication data after authorization (even if encrypted). Sensitive authentication data includes the data as cited in the following Requirements 3.. through NOTE: It is permissible for issuers and companies that support issuing services to store sensitive authentication data if there is a business justification and the data is stored securely. 3.. Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere). This data is alternatively called full track, track, track, track, and magnetic-stripe data. NOTE: In the normal course of business, the following data elements from the magnetic stripe may need to be retained: Cardholder s name Primary account number (PAN) Expiration date Service code To minimize risk, store only these data elements as needed for business. 3.. 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. Sensitive authentication data is not stored at any time with this solution. Magnetic stripe data is not stored at any time with this solution. Card verification codes/values are not stored at any time with this solution. pg. 9

20 3..3 Do not store the personal identification number (PIN) or the encrypted PIN block. PIN codes are not stored at any time with this solution. 3.3 Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed), such that only personnel with a legitimate business need can see the full PAN. NOTE: This requirement does not supersede stricter requirements in place for displays of cardholder data for example, legal or payment card brand requirements for point-ofsale (POS) receipts. 3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media and in logs) by using any of the following approaches: One-way hashes based on strong cryptography (hash must be of the entire PAN) Truncation (hashing cannot be used to replace the truncated segment of PAN) Index tokens and pads (pads must be securely stored) Strong cryptography with associated key-management processes and procedures NOTE: It is a relatively trivial effort for a malicious individual to reconstruct original PAN data if they have access to both the truncated and hashed version of a PAN. Where hashed and truncated versions of the same PAN are present in an entity s environment, additional controls should be in place to ensure that the hashed and truncated PAN is not stored or displayed with this solution. PAN is rendered unreadable from the moment it is swiped and is never stored with this solution. pg. 0