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

21 versions cannot be correlated to reconstruct This solution addresses full compliance for this control in the merchant environment, however, it still requires QSA/merchant validation of the third party service provider (InstaMed). the original PAN. 3.5 Document and implement procedures to protect keys used to secure stored cardholder data against disclosure and misuse: Note: This requirement applies to keys used to encrypt stored cardholder data, and also applies to key-encrypting keys used to protect data-encrypting keys such key-encrypting keys must be at least as strong as the dataencrypting key Restrict access to cryptographic keys to the fewest number of custodians necessary. See Store secret and private keys used to encrypt/decrypt cardholder data in one (or more) of the following forms at all times: See 3.5 Encrypted with a key-encrypting key that is at least as strong as the dataencrypting key, and that is stored separately from the data-encrypting key. Within a secure cryptographic device (such as a host security module (HSM) or PTS-approved POI device). As at least two full-length key components or key shares, in accordance with an industryaccepted method. NOTE: It is not required that public keys be stored in one of these forms Store cryptographic keys securely and in the fewest possible locations and forms. See 3.5 pg.

22 3.6 Fully document and implement all keymanagement processes and procedures for cryptographic keys used for encryption of cardholder data, including the following: Note: Numerous industry standards for key management are available from various resources including NIST, which can be found at This solution addresses full compliance for this control in the merchant environment, however it still requires QSA/merchant validation of the third party service provider (InstaMed) Generation of strong cryptographic keys. See Secure cryptographic key distribution Secure cryptographic key storage Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed and/or after a certain amount of ciphertext has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication ). See 3.6 See 3.6 See Retirement or replacement (for example, archiving, destruction and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a clear-text key), or keys are suspected of being compromised. Note: If retired or replaced cryptographic keys need to be retained, these keys must be See 3.6 pg.

23 securely archived (for example, by using a key encryption key). Archived cryptographic keys should only be used for decryption/verification purposes If manual clear-text cryptographic key management operations are used, these operations must be managed using split knowledge and dual control (for example, requiring two or three people, each knowing only their own key component, to reconstruct the whole key). Note: Examples of manual key management operations include, but are not limited to: key generation, transmission, loading, storage and See 3.6 destruction Prevention of unauthorized substitution of cryptographic keys. See Requirement for cryptographic key custodians to formally acknowledge that they understand and accept their key-custodian responsibilities. See 3.6 Requirement 4: Encrypt transmission of cardholder data across open, public networks. 4. Use strong cryptography and security protocols (for example, SSL/TLS, IPSEC, SSH, etc.) to safeguard sensitive cardholder data during transmission over open, public networks, including the following: Hardware-based encryption encrypts data at the swipe terminal, so any data that is transmitted is already strongly encrypted. Only trusted keys and certificates are accepted The protocol in use only supports secure versions or configurations The encryption strength is pg. 3

24 appropriate for the encryption methodology in use Examples of open, public include but are not limited to: The Internet Wireless technologies, including 80. and Bluetooth Cellular technologies, for example, Global System for Mobile communications (GSM), Code division multiple access (CDMA) General Packet Radio Service (GPRS) Satellite communications 4.. Ensure wireless networks transmitting cardholder data or connected to the cde, use industry best practices (for example, IEEE 80.i) to implement strong encryption for authentication and transmission. NOTE: The use of WEP as a security control is prohibited. 4. Never send unprotected PANs by end-user messaging technologies (for example, , instant messaging, chat, etc.). Requirement 5: Use and regularly update anti-virus software or programs. 5. Deploy anti-virus software on all systems commonly affected by malicious software (particularly personal computers and servers). 5.. Ensure that all anti-virus programs are capable of detecting, removing and protecting against all known types of malicious software. See 4. PANs are not available to be sent by or other end-user messaging technologies with this solution, however, this control must be addressed within administrative policies. Only the perimeter firewalls and swipe terminals are in scope, however it is recommended to follow industry best practices and deploy anti-virus on all systems. See 5. pg. 4

25 5. Ensure that all anti-virus mechanisms are maintained as follows: Are kept current Perform periodic scans Generate audit logs which are retained per PCI DSS Requirement 0.7 Requirement 6: Develop and maintain secure systems and applications See Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as high, medium or low ) to newly discovered security vulnerabilities. NOTE: Risk rankings should be based on industry best practices as well as consideration of potential impact. For example, criteria for ranking vulnerabilities may include consideration of the CVSS base score, and/or the classification by the vendor, and/or type of systems affected. Methods for evaluating vulnerabilities and assigning risk ratings will vary based on an organization s environment and risk assessment strategy. Risk rankings should, at a minimum, identify all vulnerabilities considered to be a high risk to the environment. In addition to the risk ranking, vulnerabilities may be considered critical if they pose an imminent threat to the environment, impact critical systems, and/or would result in a potential compromise if not addressed. Examples of critical systems may include security systems, public-facing Controls apply to perimeter network systems only. pg. 5

26 devices and systems, databases, and other systems that store, process, or transmit cardholder data. 6. Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release. NOTE: Critical security patches should be identified according to the risk ranking process defined in Requirement Develop internal and external software applications (including web-based administrative access to applications) securely, as follows: In accordance with PCI DSS (for example, secure authentication and logging). Based on industry standards and/or best practices. Incorporate information security throughout the software development life cycle. NOTE: This applies to all software developed internally as well as bespoke or custom software developed by a third party Remove development, test and/or custom application accounts, user IDs, and passwords before applications become active or are released to customers Review custom code prior to release to production or customers in order to identify any potential coding vulnerability (using either manual or automated processes) to Controls apply to perimeter network systems only. Software applications are not part of the CDE, and are not needed to be tested as long as they are not payment aware and cannot be used as part of the payment process. This lessens the applicability of the control. See 6.3 See 6.3 pg. 6

27 include at least the following: Code changes are reviewed by individuals other than the originating code author, and by individuals knowledgeable about code review techniques and secure coding practices. Code reviews ensure code is developed according to secure coding guidelines. Appropriate corrections are implemented prior to release. Code review results are reviewed and approved by management prior to release. NOTE: This requirement for code reviews applies to all custom code (both internal and public-facing), as part of the system development life cycle. Code reviews can be conducted by knowledgeable internal personnel or third parties. Public-facing web applications are also subject to additional controls, to address ongoing threats and vulnerabilities after implementation, as defined at PCI DSS Requirement Follow change control processes and procedures for all changes to system components. The processes must include the following: 6.4. Separate development/test environments from production environments, and enforce the separation with access controls Separation of duties between development/test and production environments. Controls apply to perimeter network systems only. See 6.4 See 6.4 pg. 7

28 6.4.3 Production data (live PANs) are not used for testing or development. See Removal of test data and accounts before production systems become active. See Change control procedures for the implementation of security patches and software modifications must include the following: Documentation of impact. See 6.4 See Documented change approval by authorized parties. See Functionality testing to verify that the change does not adversely impact the security of the system Back-out procedures. 6.5 Address common coding vulnerabilities in software-development processes as follows: Train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory. Develop applications based on secure coding guidelines. NOTE: The vulnerabilities listed at 6.5. through were current with industry best practices when this version of PCI DSS was published. However, as industry best practices for vulnerability management are updated (for example, the OWASP Guide, SANS CWE Top 5, CERT Secure Coding, etc.), the See 6.4 See 6.4 The applicable controls will be lessened for merchants and mostly apply to components in the third party hosted systems. InstaMed is responsible for ensuring their web applications are developed in accordance to PCI PA-DSS requirements and secure coding best practices. pg. 8

29 current best practices must be used for these requirements Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws Buffer overflow Insecure cryptographic storage Insecure communications Improper error handling All high risk vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.) Cross-site scripting (XSS) Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions) Cross-site request forgery (CSRF). See 6.5 See 6.5 See 6.5 See 6.5 See 6.5 See 6.5 See 6.5 See 6.5 See Broken authentication and session management. See For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods: Reviewing public-facing web See 6.5 pg. 9

30 applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes. NOTE: This assessment is not the same as the vulnerability scans performed for Requirement.. Installing an automated technical solution that detects and prevents web-based attacks (for example, a web-application firewall) in front of public-facing web applications, to continually check all traffic. Requirement 7: Restrict access to cardholder data by business need to know 7. Limit access to system components and cardholder data to only those individuals whose job requires such access. 7.. Define access needs for each role, including: Because the CDE is encrypted at swipe the cardholder data environment is restricted to those systems managed by the third party service provider (InstaMed). See 7. System components and data resources that each role needs to access for their job function. Level of privilege required (for example, user, administrator, etc.) for accessing resources 7.. Restrict access to privileged user IDs to least privileges necessary to perform job See 7. responsibilities Assign access based on individual personnel s job classification and function. See Require documented approval by authorized parties specifying required privileges. See 7. pg. 30

31 7. Examine system settings and vendor documentation to verify that an access control system is implemented as follows: 7.. Coverage of all system components. See 7. See Assignment of privileges to individuals based on job classification and function. See Default deny-all setting. See 7. Requirement 8: Identify and authenticate access to system components. 8. Define and implement policies and procedures to ensure proper user identification management for non-consumer users and administrators on all system components as follows: 8.. Assign all users a unique ID before allowing them to access system components or cardholder data. 8.. Control addition, deletion, and modification of user IDs, credentials, and The applicable controls should apply to perimeter network systems only. However, it is recommended to follow industry best practices and the following requirements on all systems regardless. See 8. See 8. other identifier objects Immediately revoke access for any terminated users Remove/disable inactive user accounts at least every 90 days. See 8. See Manage IDs used by vendors to access, support, or maintain system components via remote access as follows: See 8. Enabled only during the time period needed and disabled when not in use. Monitored when in use. pg. 3

32 8. In addition to assigning a unique ID, ensure proper user-authentication management for non-consumer users and administrators on all system components by employing at least one of the following methods to authenticate all users: See 8. Something you know, such as a password or passphrase. Something you have, such as a token device or smart card. Something you are, such as a biometric. 8.. Using strong cryptography, render all authentication credentials (such as passwords/phrases) unreadable during transmission and storage on all system components. 8.. Verify user identity before modifying any authentication credential for example, performing password resets, provisioning new tokens, or generating new keys Passwords/phrases must meet the following: See 8. See 8. See 8. Require a minimum length of at least seven characters. Contain both numeric and alphabetic characters. Alternatively, the passwords/phrases must have complexity and strength at least equivalent to the parameters specified above Change user passwords/passphrases at least every 90 days. See Do not allow an individual to submit a new password/phrase that is the same as any of the last four passwords/phrases he or she See 8. pg. 3

33 has used Set passwords/phrases for first-time use and upon reset to a unique value for each user, and change immediately after the first use. 8.3 Incorporate two-factor authentication for remote network access originating from outside the network, by personnel (including users and administrators) and all third parties, (including vendor access for support or maintenance). NOTE: Two-factor authentication requires that two of the three authentication methods (see Requirement 8. for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered two-factor authentication. Examples of two-factor technologies include remote authentication and dial-in service (RADIUS) with tokens; terminal access controller access control system (TACACS) with tokens; and other technologies that facilitate two-factor authentication. 8.4 Document and communicate authentication procedures and policies to all users including: Guidance on selecting strong authentication credentials. Guidance for how users should protect their authentication credentials. Instructions not to reuse previously used passwords. Instructions to change passwords if there is any suspicion the password See 8. See 8. See 8. pg. 33

34 could be compromised. 8.5 Do not use group, shared, or generic IDs, passwords, or other authentication methods as follows: Generic user IDs are disabled or removed. Shared user IDs do not exist for system administration and other critical functions. Shared and generic user IDs are not used to administer any system components. 8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.), use of these mechanisms must be assigned as follows: Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts. Physical and/or logical controls must be in place to ensure only the intended account can use that mechanism to gain access. 8.7 All access to any database containing cardholder data (including access by applications, administrators, and all other users) is restricted as follows: All user access to, user queries of, and user actions on databases are through programmatic methods. Only database administrators have the ability to directly access or query databases. Application IDs for database See 8. See 8. See 8. pg. 34

35 applications can only be used by the applications (and not by individual users or other non-application processes). Requirement 9: Restrict physical access to cardholder data. 9. Use appropriate facility entry controls to limit and monitor physical access to systems in the CDE. 9.. Use video cameras and/or access control mechanisms to monitor individual physical access to sensitive areas. Review collected data and correlate with other entries. Store for at least three months, unless otherwise restricted by law. NOTE: Sensitive areas refers to any data center, server room, or any area that houses systems that store, process, or transmit cardholder data. This excludes public-facing areas where only point-of-sale terminals are present, such as the cashier areas in a retail store. 9. Develop procedures to easily distinguish between onsite personnel and visitors, to include: Identifying new onsite personnel or visitors (for example, assigning Applicable controls for facility requirements are significantly reduced, since physical access to the merchant locations cannot be used to gain access to cardholder data. However, merchants should not rely on the tamper-resistant swipe terminal alone, and should have appropriate controls to ensure that the terminals cannot be physically altered, that perimeter devices are properly protected, and that any paper receipts (such as EOD reports) are protected if they contain PANs. There are no sensitive areas at the merchant locations with this solution. Only cashier areas are present which are excluded from these controls. Cardholder data is not accessible in the merchant locations. Merchants should still ensure that there are basic training and procedures to ensure that unauthorized visitors cannot access perimeter systems or swipe pg. 35

36 badges). terminals. Changes to access requirements. Revoking or terminating onsite personnel and expired visitor identification (such as ID badges). 9.3 Control physical access for onsite personnel to the sensitive areas as follows: See 9. Access must be authorized and based on individual job function. Access is revoked immediately upon termination, and all physical access mechanisms, such as keys, access cards, etc., are returned or disabled. 9.4 Verify that visitor authorization and access controls are in place as follows: See Visitors are authorized before entering, and escorted at all times within areas where cardholder data is processed or maintained Visitors are identified and given a badge or other identification that expires and that visibly distinguishes the visitors from onsite personnel Visitors are asked to surrender the badge or identification before leaving the facility or at the date of expiration A visitor log is used to maintain a physical audit trail of visitor activity to the facility as well as for computer rooms and data centers where cardholder data is stored or transmitted. Document the visitor s name, the firm represented, and the onsite personnel authorizing physical access on the log. Retain this log for a minimum of three months, unless otherwise restricted by law. See 9. See 9. See 9. See 9. pg. 36

37 9.5 Physically secure all media Store media backups in a secure location, preferably an off-site facility, such as an alternate or back-up site, or a commercial storage facility. Review the location s security at least annually. 9.6 Maintain strict control over the internal or external distribution of any kind of media, Electronic media does not include PANs. Paper media that contains full PANs should be physically secured at the merchant and corporate locations. PANs are not stored on merchant systems, therefore backups are not required to be monitored and secured. See 9.5 including the following: 9.6. Classify media so the sensitivity of the data can be determined. See Send the media by secured courier or other delivery method that can be accurately tracked Ensure management approves any and all media that is moved from a secured area (including when media is distributed to See 9.5 See 9.5 individuals). 9.7 Maintain strict control over the storage and accessibility of media. 9.7 Maintain strict control over the storage and accessibility of media. See 9.5 See Properly maintain inventory logs of all media and conduct media inventories at least annually. 9.8 Destroy media when it is no longer needed for business or legal reasons as follows: 9.8. Render cardholder data on electronic media unrecoverable so that cardholder data cannot be reconstructed. See 9.5 Since there is no electronic media containing cardholder data, the only applicable controls are those that pertain to hardcopy materials. See 9.8 pg. 37

38 Requirement 0: Track and monitor all access to network resources and cardholder data. 0. Implement audit trails to link all access to system components to each individual user. 0. Implement automated audit trails for all system components to reconstruct the Controls apply to perimeter network systems and terminals running hardware-based encryption only. See 0. following events: 0.. All individual user access to cardholder data. 0.. All actions taken by any individual with root or administrative privileges. See 0. See Access to all audit trails Invalid logical access attempts Use of and changes to identification and authentication mechanisms including but not limited to creation of new accounts and elevation of privileges and all changes, additions, or deletions to accounts with root or See 0. See 0. See 0. administrative privileges Initialization, stopping, or pausing of the audit logs Creation and deletion of system-level objects. See 0. See Record at least the following audit trail entries for all system components for each event: 0.3. User identification. See 0. See 0. pg. 38

39 0.3. Type of event Date and time Success or failure indication Origination of event. See 0. See 0. See 0. See Identity or name of affected data, system component, or resource. See Using time-synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time. NOTE: One example of time synchronization Controls apply to perimeter network systems and terminals running hardware-based encryption only. technology is Network Time Protocol (NTP) Critical systems have the correct and consistent time. See Time data is protected. See Time settings are received from industry-accepted time sources. See Secure audit trails so they cannot be altered. Controls apply to perimeter network systems and terminals running hardware-based 0.5. Limit viewing of audit trails to those with a job-related need Protect audit trail files from unauthorized modifications. encryption only. See 0.5 See 0.5 pg. 39

40 0.5.3 Promptly back up audit trail files to a centralized log server or media that is difficult to alter Write logs for external-facing technologies onto a secure, centralized, internal log server or media device Use file-integrity monitoring or change-detection software on logs to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert). 0.6 Review logs and security events for all system components to identify anomalies or suspicious activity. NOTE: Log harvesting, parsing, and alerting tools may be used to meet this requirement. 0.6 Perform the following: See 0.5 See 0.5 See 0.5 Controls apply to perimeter network systems and terminals running hardware-based encryption only Review the following at least daily: All security events. Logs of all system components that store, process, or transmit CHD and/or SAD, or that could impact the security of CHD and/or SAD. Logs of all critical system components. Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems/intrusion-prevention systems (IDS/IPS), authentication servers, e- commerce redirection servers, etc.) Review logs of all other system components periodically based on the organization s policies and risk management See 0.6 See 0.6 pg. 40

41 strategy, as determined by the organization s annual risk assessment Follow-up exceptions and anomalies identified during the review process. See Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup). Requirement : Regularly test security systems and processes.. Implement processes to test for the presence of wireless access points (80.), and detect and identify all authorized and unauthorized wireless access points on a quarterly basis. NOTE: Methods that may be used in the process include, but are not limited, to wireless network scans, physical/logical inspections of system components and infrastructure, network access control (NAC), or wireless IDS/IPS. Whichever methods are used, they must be sufficient to detect and identify both authorized and unauthorized devices.. Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades). NOTE: Multiple scan reports can be combined for the quarterly scan process to show that all systems were scanned and all Controls apply to perimeter network systems and terminals running hardware-based encryption only. Wireless AP detection is a control to reduce the risk of capturing unencrypted card data or credentials to card networks sent in the clear over trusted network connections. Only encrypted card data is sent over internal networks thus removing the risk. Internal vulnerability scans no longer need to be performed, and therefore there are less controls applicable for this requirement. pg. 4

42 applicable vulnerabilities have been addressed. Additional documentation may be required to verify non-remediated vulnerabilities are in the process of being addressed. For initial PCI DSS compliance, it is not required that four quarters of passing scans be completed if the assessor verifies ) the most recent scan result was a passing scan, ) the entity has documented policies and procedures requiring quarterly scanning, and 3) vulnerabilities noted in the scan results have been corrected as shown in a rescan(s). For subsequent years after the initial PCI DSS review, four quarters of passing scans must have occurred... Perform quarterly internal vulnerability scans, and rescans as needed, until all highrisk vulnerabilities (as identified in Requirement 6.) are resolved. Scans must be performed by qualified personnel...3 Perform internal and external scans, and rescans as needed, after any significant change. Scans must be performed by qualified personnel..3 Implement a methodology for penetration testing that includes at least the following: Is based on industry-accepted penetration testing approaches (for example, NIST SP800-5). Includes coverage for the entire CDE perimeter and critical systems. Includes testing from both inside and outside of the network. See. See. Yearly external penetration tests are required; however, internal penetration testing is no longer required as those controls no longer apply. pg. 4

43 Includes testing to validate any segmentation and scope reduction controls. Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5. Defines network-layer penetration tests to include components that support network functions as well as operating systems. Includes review and consideration of threats and vulnerabilities experienced in the last months. Specifies retention of penetration testing results and remediation activities results..3. Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment)..4 Use intrusion-detection systems and/or intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the CDE as well as at critical points in the CDE, and alert personnel to suspected compromises. Keep all intrusion-detection and prevention engines, baselines, and signatures up-to-date..5 Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized See.3 External connections to the merchant environment should implement intrusion detection systems to monitor all network traffic to the hardware-based encryption platforms. No host systems or applications are within the merchant CDE where file integrity monitoring would be required to monitor and alert to pg. 43

44 modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly. NOTE: For change-detection purposes, critical files are usually those that do not regularly change, but the modification of which could indicate a system compromise or risk of compromise. Change-detection mechanisms such as file-integrity monitoring products usually come pre-configured with critical files for the related operating system. Other critical files, such as those for custom applications, must be evaluated and defined by the entity(that is, the merchant or service provider). critical system and data files. This control should not apply. pg. 44

45 Coalfire Assessment Information Assessment Environment InstaMed Payments with Encryption was installed in InstaMed s UAT environment for the duration of the Coalfire assessment. The assessment included a remote lab system configured with the three different MagTek devices. During the assessment, Coalfire tested transactions, monitored interfaces for transmitted data and scanned the disk for any cardholder and sensitive authentication data. The test equipment and software consisted of:. Wireshark Ethernet port sniffer to monitor traffic on the CDE, which contained ) MagTek DynaPro Debit/Credit MSR device ) MagTek IPAD Debit/Credit MSR device; 3) MagTek Dynamag USB keyboard emulated MSR device; 4) MagTek Dynamag USB HID emulated MSR device; 5) MagTek udynamo headphone-jack MSR device.. FTK for forensics analysis. 3. SysInternals Process Explorer to analyze running services. Disk Analysis The technical assessment included a forensic examination of the hard drive of the lab system with the MagTek devices installed. The process for examining the hard drives was as follows:. Created a forensic image of the systems hard drives, using FTK Imager and FTK MPE.. Searched the disk images for key criteria, including cardholder and sensitive authentication data, using FTK. During this assessment, Coalfire did not identify any cardholder or sensitive authentication data. From this forensic analysis, Coalfire concludes that:. There is no residual cardholder or sensitive authentication data on the system that runs the MagTek devices integrated with InstaMed Online. pg. 45

46 Network Traffic Assessment Coalfire used a Wireshark Ethernet sniffer to monitor traffic from the lab system interface and MagTek devices integrated with InstaMed Online. This assessment showed that no unencrypted cardholder data is transmitted over the network from the lab system with MSR to InstaMed Online. Tools and Techniques Standard tools Coalfire utilizes for its application security reviews can include: Tool Name Description FTK *Forensic tool for digital data and media analysis. FTK Mobile Phone Examiner Additional tools *Forensic tool for mobile phone digital data & media analysis Various Search Engines, Whois and DNS Enumeration, Usenet, Google Hacking Database, Wikto, Wayback Machine, Sam Spade, Cain & Able, NMAP Nessus, Netcat, Dsniff, Wireshark, THC Hydra, THC SSL Check, SslScan, Nikto, MiB Browser, soapui, NIST CVSS Archive List., Rapid 7 Community, Process Explorer *Forensic tool: A tool or method for uncovering, analyzing and presenting forensic data, which provides a robust way to authenticate, search, and recover computer evidence rapidly and thoroughly. pg. 46