What To Do If Compromised

What To Do If Compromised Visa Europe Data Compromise Procedures March 2011 Version 5.0 (Europe)

Change Log Version Date Description 1.0 June 2009 Initial Version 2.0 March 2010 Reviewed 3.0 May 2010 Appendix B date for completion added 4.0 December 2010 References changed to Data Compromise team and Appendices A & B updated 5.0 March 2011 Updated with information on PCI SSC PCI Forensic Investigator (PFI) programme

Table of Contents Introduction... 3 Identifying and Detecting Security Breaches... 5 Attack Vectors...6 Steps and Requirements for Compromised Entities... 10 Steps and Requirements for Visa Members (Acquirers and Issuers)... 12 Requirements for Account Data Requests... 16 Visa Account Bulletin... 16 Appendix A: Compromised Entity Details Report Template... 17 Appendix B: Acquirer Investigation Report Template... 19 Appendix C: Forensic Investigation Guideline... 21 Appendix D: Preliminary Incident Report Template... 26 Appendix E: Final Incident Report Template...27 Appendix F: Request for Information - External Compromise...33 Appendix G : List of Supporting Documents... 34 Appendix H : Glossary of Terms...35 Appendix I: Investigation Definitions...40 WHAT TO DO IF COMPROMISED 3 Visa Europe Version 5.0 ----March 2011

Introduction What constitutes a security incident? The answer to this question is crucial to any organisation looking to minimise the impact an incident might have on its business operations. In general, incidents may be defined as deliberate electronic attacks on communications or information processing systems. Whether initiated by a disgruntled employee, a malicious competitor, or a misguided hacker, deliberate attacks often cause damage and disruption to the payment system. How you respond to and handle an attack on your company s information systems will determine how well you will be able to control the costs and consequences that could result. For these reasons, the extent to which you prepare for security incidents, and work with Visa Europe, will be vitally important to the protection of your company s key information. In the event of a security incident, Visa Europe members and their agents must take immediate action to investigate the incident, limit the exposure of cardholder data, notify Visa Europe, and report investigation findings to Visa Europe. * The What To Do If Compromised guide is intended for Visa Europe members (i.e., acquirers and issuers), merchants, agents, and third-party service providers. It contains step-by-step instructions on how to respond to a security incident and provides specific time frames for the delivery of information or reports outlining actions taken by Visa Europe, its members, and its agents. In addition to the general instructions provided here, Visa Europe may also require an investigation that includes, but is not limited to, access to premises and all pertinent records including copies of analysis. * Visa Europe Operating Regulations---- Section 2.1, General Security Requirements, Section 2.1.E.3, Loss or Theft of Account or Transaction Information, Section 2.1.E.4, Investigations and Section 2.1.E.5, Member Co-operation. WHAT TO DO IF COMPROMISED 4 Visa Europe Version 5.0 ----March 2011

Identifying and Detecting Security Breaches It is often difficult to detect when a system has been attacked or an intrusion has taken place. Distinguishing normal events from those that are related to an attack or intrusion is a critical part of maintaining a secure payment processing environment. Security breaches come in many different forms and, while detecting them may be challenging, there are certain signs that tend to appear when a security breach has occurred: Unknown or unexpected outgoing internet network traffic from the payment card environment Presence of unexpected IP addresses on store and wireless networks Unknown or unexpected network traffic from store to headquarter locations Unknown or unexpected services and applications configured to launch automatically on system boot Unknown files, software and devices installed on systems Anti-virus programs malfunctioning or becoming disabled for unknown reasons Failed login attempts in system authentication and event logs Vendor or third-party connections made to the cardholder environment without prior consent and/or a trouble ticket SQL Injection attempts in web server event logs Authentication event log modifications (i.e., unexplained event logs are being deleted) Suspicious after-hours file system activity (i.e., user login or after-hours activity to Point-of-Sale ( POS ) server) Presence of.zip,.rar,.tar, and other types of unidentified compressed files containing cardholder data Presence of a rootkit, which hides certain files and processes in, for example, Explorer, the Task Manager, and other tools or commands Systems rebooting or shutting down for unknown reasons If you are running Microsoft, check Windows registry settings for hidden malicious code. (Note: Make sure you back up your registry keys before making any changes and consult with Microsoft Help and Support). WHAT TO DO IF COMPROMISED 5 Visa Europe Version 5.0 ----March 2011

Attack Vectors The following are examples of attack vectors that hackers use to gain unauthorised access to organisation s systems and steal sensitive information, such as payment card data and passwords. SQL Injection Attacks Improperly Segmented Network Environment Malicious Code Attacks SQL injection is a technique used to exploit Web-based applications that use member-supplied data in SQL queries. SQL injection attacks can occur as a result of unpatched Web servers, improperly designed applications (i.e, incorrectly filtered escape characters or error-type handling) or poorly configured Web and database servers. The SQL attack methods most recently detected were targeted against Websites and Web applications that were improperly designed or resided on unpatched systems, making them susceptible to attack. These latest SQL injection attacks pose serious additional risks to cardholder data stored or transmitted within systems (e.g., Microsoft and UNIX-based) and networks connected to the affected environment. Payment card account information has been compromised at organisations that lack proper network segmentation. This attack method originates on the Internet, resulting in penetration to the organisation s payment card environment and often leading to costly remediation efforts and increased fraud attacks. Such compromises can often be prevented if the organisation s networks are properly segmented, limiting intruders to non-sensitive parts of the network that do not contain payment card information. Network segmentation is a concept that refers to the practice of splitting a network into functional segments and implementing an access control mechanism between each of the boundaries. The most common example of network segmentation is the separation between the internet and an internal network using a firewall/router. Malicious codes or malware can be programs such as viruses, worms, Trojan applications, and scripts used by intruders to gain privileged access and capture passwords or other confidential information (e.g., user account information). Malicious code attacks are usually difficult to detect because certain viruses can be designed to modify their own signatures after inflicting a system and before spreading to another. Some malicious codes can also modify audit logs to hide unauthorised activities. WHAT TO DO IF COMPROMISED 6 Visa Europe Version 5.0 ----March 2011

In recent investigations, Visa Europe has identified malicious codes designed to capture payment card data. These are examples of malicious code attacks: Malware that allows interactive command shell or backdoor. This type of malware allows an intruder to run commands to the compromised system. In some cases, the malware is hard-coded with the intruder s Internet Protocol ( IP ) address. Packet sniffers. Packet sniffing is the practice of using computer software or hardware to intercept and log traffic passing over a computer network. A packet sniffer, also known as a network analyser or protocol analyser, captures and interprets a stream or block of data (referred to as a packet ) travelling over a network. Packet sniffers are typically used in conjunction with malicious software or malware. Once intruders gain entry into a critical system using backdoor programs or deploying rootkits, the sniffer programs are installed, making the malware more difficult to detect. Intruders can then sniff packets between network users and collect sensitive information such as usernames, passwords, payment card data or Social Security numbers. Once a critical system or network is compromised, sniffers are used to eavesdrop or spy on network users and activity. This combination of tools makes this attack scheme effective in compromising systems and networks. Key logger malware. Key logging is a method of capturing and recording keystrokes. There are key logger applications that are commercially available and are used by organisations to troubleshoot problems within computer systems. Visa Europe investigations reveal that there are key logger applications that are developed by intruders to capture payment card data and/or users credentials, such as passwords. The key logger captures information in real time and sends it directly to the intruder over the Internet. Additionally, newer advances provide the ability to intermittently capture screenshots from the key logged computer. Key logger malware are widely available via the Internet and can be installed on virtually any operating system. Key loggers, like most malware, are distributed as part of a Trojan horse or virus, sent via e-mail (as an attachment or by clicking to an infected web link or site) or, in the worst case, installed by a hacker with direct access to a victim s computer. WHAT TO DO IF COMPROMISED 7 Visa Europe Version 5.0 ----March 2011

Insecure Remote Access Many Point-of Sale ( POS ) vendors, resellers and integrators have introduced remote access management products into the environments of organisations that they support. A variety of remote access solutions exists, ranging from command-line based (e.g., SSH, Telnet) to visually-driven packages (e.g., pcanywhere, Virtual Network Computing, Remote Desktop). The use of remote management products comes with an inherent level of risk that may create a virtual backdoor on your system. The exploitation of improperly configured and unpatched remote management software tools is the method of attack most frequently used by hackers against POS payment systems. An improperly configured system can be vulnerable in the following ways: Failure to regularly update or patch a system can render the system vulnerable to exploits that defeat the security mechanisms built into the product. Lack of encryption or weak encryption algorithms can lead to the disclosure of access credentials. Use of default passwords can provide easy access to unauthorised individuals. Disabled logging mechanisms eliminate insight into system access activity and signs of intrusion. Insecure Wireless The adoption of wireless technology is on the rise among participants in the payment industry; particularly merchant retailers, many of whom use wireless technology for inventory systems or check-out efficiency (e.g., line busting, ringing up customers while they are in line). Wireless technologies have unique vulnerabilities; organisations must carefully evaluate the need for such technology and understand the risks, as well as the security requirements, before deploying wireless systems. Following are some of the common methods used to attack wireless networks. These methods are widely documented on the Internet, complete with downloadable software and instructions. Eavesdropping ---- An attacker can gain access to a wireless network just by listening to traffic. Radio transmissions can be freely and easily intercepted by nearby devices or laptops. The sender or intended receiver has no means of knowing whether the transmission has been intercepted. WHAT TO DO IF COMPROMISED 8 Visa Europe Version 5.0 ----March 2011

Rogue Access ---- If a wireless Local Area Network (LAN) is part of an enterprise network, a compromise of the LAN may lead to the compromise of the enterprise network. An attacker with a rogue access point can fool a mobile station into authenticating with the rogue access point, thereby gaining access to the mobile station. This is known as a trust problem, and the only protection against it is an efficient access-authentication mechanism. Denial of Service (DOS) ---- Due to the nature of radio transmission, wireless LANs are vulnerable to denial-of-service attacks and radio interference. Such attacks can be used to disrupt business operations or to gather additional information for use in initiating another type of attack. Man-in-the-Middle (MITM) ---- Packet spoofing and impersonation, whereby traffic is intercepted midstream then redirected by an unauthorised individual for malicious purposes, are also valid threats. WHAT TO DO IF COMPROMISED 9 Visa Europe Version 5.0 ----March 2011

Steps and Requirements for Compromised Entities Entities that have experienced a suspected or confirmed security breach must take prompt action to help prevent additional exposure of cardholder data and ensure compliance with the Payment Card Industry Data Security Standard (PCI DSS) and PCI Payment Application Data Security Standard (PA-DSS). 1. Immediately contain and limit the exposure. Minimise data loss. Prevent the further loss of data by conducting a thorough investigation of the suspected or confirmed compromise of information. Compromised entities should consult with their internal incident response team. To preserve evidence and facilitate the investigation: o o o o o o Do not access or alter compromised system(s) (i.e., don t log on at all to the compromised system(s) and change passwords; do not log in as ROOT). Do not turn the compromised system(s) off. Instead, isolate compromised systems(s) from the network (i.e., unplug network cable). Preserve logs (i.e., security events, web, database, firewall, etc.). Log all actions taken. If using a wireless network, change the Service Set Identifier (SSID) on the wireless access point (WAP) and other systems that may be using this connection (with the exception of any systems believed to be compromised). Be on high alert and monitor traffic on all systems with cardholder data. Visa Europe Operating Regulations---- Section 2.1, General Security Requirements; Section 2.1.E.3, Loss or Theft of Account or Transaction Information; Section 2.1.E.4, Investigations; and Section 2.1.E.5 Member Co-operation. WHAT TO DO IF COMPROMISED 10 Visa Europe Version 5.0 ----March 2011

2. Alert all necessary parties immediately: o Your internal incident response team and information security group. o If you are a merchant, contact your merchant bank. o If you do not know the name and/or contact information for your merchant bank, notify Visa Europe Data Compromise Team Manager immediately: - +44 (0) 20 7795 5453 or datacompromise@visa.com If you are a financial institution, contact Visa Europe at the number provided above. 3. Notify the appropriate law enforcement agency. 4. Provide all compromised Visa, Interlink, and Plus accounts to the Visa Europe acquiring bank or to Visa Europe within seven (7) business days. All potentially compromised accounts must be provided and transmitted as instructed by the Visa Europe acquiring bank and Visa Europe. Visa Europe will distribute the compromised Visa account numbers to issuers and ensure the confidentiality of entity and non-public information. 5. Within three (3) business days of the reported compromise, provide a Compromised Entity Details Report to the Visa Europe member or to Visa Europe. (See Appendix A, on page 16, for the Compromised Entity Details Report template.) If you are a financial institution, provide the Compromised Entity Details Report to Visa Europe. WHAT TO DO IF COMPROMISED 11 Visa Europe Version 5.0 ----March 2011

Steps and Requirements for Visa Europe Members (Acquirers and Issuers) Notification 1. Immediately report to Visa Europe the suspected or confirmed loss or theft of Visa cardholder data. Members must contact Visa Europe Data Compromise Management at the secure email address datacomp@visaonline.com. 2. Advise Visa Europe whether the entity was in compliance with PCI DSS and, if applicable, PCI PA-DSS at the time of the incident. If so, provide appropriate proof. 3. Ensure that the compromise has been contained to prevent future loss or theft of account information. 4. Ensure that the law enforcement agencies are informed, if appropriate, to comply with national law. Preliminary Investigation 5. Within three (3) business days perform an initial investigation and provide Visa Europe with a completed Compromised Entity Details Report (Appendix A ) that should be sent to the secure email address datacomp@visaonline.com. 6. The information provided will help Visa Europe understand the potential exposure and assist entities in containing the incident. Documentation must include the steps taken to contain the incident. FOR MORE INFORMATION To find out more about conducting an initial investigation, see Appendix A: Initial Investigation Request on page 16. Account Numbers 7. Within 7 (seven) business days from the initial notification provide at risk account numbers to Visa Europe, these should be sent to the secure email address datacomp@visaonline.com. If entity compromised is a direct connect to Visa, please complete Appendix F. WHAT TO DO IF COMPROMISED 12 Visa Europe Version 5.0 ----March 2011

Forensic Investigation Determine if a forensic investigation is required or not. 8. If the incident involves more that 10,000 accounts at risk, based on the exposure period defined by the issuers fraud reporting, it is required that a forensic investigation is completed. 9. If less than 10,000 accounts at risk, acquirer must complete an Acquirer Investigation Report (Appendix B) and send it to Visa Europe within 21 days from initial notification at the secure email address datacomp@visaonline.com. 10. This must include a detailed reason why it has been determined that a forensic investigation is not required and how the compromise has been contained. If an entity has a public IP address, the acquirer must initiate a remote vulnerability scan by a PCI SSC approved scan vendor. A list of approved scan vendors is available on www.pcisecuritystandards.org The acquirer must ensure that compromised entity has passed the scan. 11. If a forensic investigation is required the acquirer must ensure that a PCI Forensic Investigator (PFI) is engaged to perform the forensic investigation. List of PCI Forensic Investigators (PFIs) - https://www.pcisecuritystandards.org/approved_companies_providers/pfi_compa nies.php For more information on the PCI SSC s PFI programme please use the link below: PFI Supplementary Requirements - https://www.pcisecuritystandards.org/security_standards/documents.php?d ocument=pfi_supplemental_requirements#pfi_supplemental_requirements 12. Visa Europe reserves the right to insist upon a forensic investigation if deemed necessary, irrespective of the number of accounts at risk. 13. If an independent forensic investigation is required, members must: o Identify the PFI within seven (7) business days of initial notification of a suspected compromise. o Ensure that the PFI is engaged (or the contract is signed) within ten (10) business days initial notification of a suspected compromise. o The PFI must be onsite to conduct a forensic investigation within five (5) business days from the date the contract agreement is signed. WHAT TO DO IF COMPROMISED 13 Visa Europe Version 5.0 ----March 2011

14. The Visa Europe member must ensure that there is no conflict of interest for the PFI and must ensure that the PFI did not certify any of the Payment Applications being used by the compromised entity or having undertaken the PCI DSS audit for the compromised entity. The Visa Europe member should engage the PFI directly. However, Visa Europe, has the right to engage a PFI to perform a forensic investigation as it deems appropriate, and will assess all investigative costs to the member in addition to any fine that may be applicable. 15. Within five (5) business days from the onset of the forensic investigation provide a Preliminary Incident report (Appendix C) to Visa Europe. This report should be sent to secure email address datacomp@visaonline.com.the report should contain identification of any further account numbers that are at risk, details of how the compromise has been contained, estimated time to complete the full investigation. If further account numbers have been identified they should be sent to the secure email address datacomp@visaonline.com. 16. Within ten (10) business days from the completion of the forensic investigation provide a Final Forensic report to Visa Europe. This report should be sent to secure email address datacomp@visaonline.com. Containment/ Remediation 17. Ensure that the compromised entity has contained the incident and has implemented security recommendations provided by the PFI, including any non-compliance with the PCI PIN Security Requirements. 18. Within 30 days from notification by Visa Europe, if the entity is retaining full-track data, CVV2, and/or PIN blocks, submit confirmation that the entity has removed the data (this includes any historical data). This should be sent to datasecuritystandards@visa.com. 19. Validate that full-track data, CVV2, and/or PIN blocks are no longer being stored on any systems. Even though this is the member s responsibility, Visa Europe requires that the validation be performed by the PFI. 20. Within 90 days of the notification from Visa Europe, confirm that sufficient remediation has been completed. This should be sent to datasecuritystandards@visa.com. If required by Visa Europe, members must provide a remediation plan with implementation dates related to findings identified by the PFI. ** Visa Europe Operating Regulations---- Section 1.6 Regulation Enforcement, Section 1.6.D.24.f Account Information Security Program. ** Visa Europe Operating Regulations---- Section 1.6 Regulation Enforcement, Section 1.6.D.24.e Sufficient remediation WHAT TO DO IF COMPROMISED 14 Visa Europe Version 5.0 ----March 2011

21. A revised remediation plan must be provided to Visa Europe, if requested. 22. Monitor and confirm that the compromised entity has implemented the action plan. PCI DSS Compliance 23. Ensure that the compromised entity achieves full PCI compliance by adhering to the PCI DSS and, if applicable, PCI PA-DSS. Compliance validation is required per Visa Europe Operating Regulations (Section 2.1.E). KEY POINT TO REMEMBER Please visit www.pcisecuritystandards.org for more information on PCI DSS and the PCI PIN Entry Device Testing Program. WHAT TO DO IF COMPROMISED 15 Visa Europe Version 5.0 ----March 2011

Requirements for Account Data Requests In the event of a compromise, Visa Europe requires that at risk accounts be provided to Visa Europe through the secure email address datacomp@visaonline.com. In some cases, Visa Europe may require the entity to provide accounts via a CD using encryption software such as PGP or Winzip with 256-AES encryption and strong password. The following guidelines must be followed when providing accounts to Visa Europe. Account Data Format File submitted must be a plain-text, comma delimited file containing account numbers and expiration dates. For example: -- The card number, followed by a comma, followed by the expiration date in YYMM format: 4xxxxxxxxxxx1234,0801 KEY POINT TO REMEMBER Visa Europe may require additional data for further fraud analysis and will inform the compromised entity and the Visa Europe member if additional data is required. 1. Submitted data should be limited to one file. In cases where one file isn t possible, make every effort to minimize total file counts. If multiple files are provided, all of them MUST be consistent (i.e., they MUST contain the same formatting and transaction details). 2. The windows of exposure or period of compromise must be indicated with the file containing the accounts at risk. KEY POINT TO REMEMBER Visa accounts copied to a CD or other removable media must be encrypted using PGP or Winzip with 256-AES encryption with strong password. PGP (Pretty Good Privacy) is a computer program that provides cryptographic privacy and authentication. For more information on PGP, go to www.pgp.com. WinZip is a data compression utility with the ability to compress using 256-AES encryption. For more information on WinZip, go to www.winzip.com. WHAT TO DO IF COMPROMISED 16 Visa Europe Version 5.0 ----March 2011

Visa Account Bulletin (VAB) The Visa Account Bulletin (VAB) service offers a secure and efficient way for Visa Europe issuers to view compromised and recovered account data received by Visa from acquirers, processors, PFIs and law enforcement agencies. Each member organisation will receive an alert if they have accounts affected in order to implement their own initiatives for fraud reduction. On receipt of a VAB alert, issuers should analyse the card accounts reported. Based on the results of this analysis, issuers can either block and re-issue, or flag the accounts (either manually or through an automated facility) so that future authorisations are viewed with more scrutiny and a more strict set of approval parameters is applied. The VAB service can be located in the Fraud, Security & Risk section in Visa Online and the Visa Account Bulletin subsection. To register for VAB alerts issuers will need to contact their Visa Online Access Manager (VAM). To find out whom your VAM is please contact Customersupport@visa.com. To receive e-mail notifications advising you when VAB alerts are published which include your card ranges please add your details in the Fraud Contact List within VAB. For further information regarding VAB Visa Europe members can access the VAB Best Practices document published on Visa on Line under the Global Fraud Information Service/ Latest News. Member can also obtain a copy of the VAB User Guide. Please contact our customer support team on Customersupport@visa.com. WHAT TO DO IF COMPROMISED 17 Visa Europe Version 5.0 ----March 2011

Appendix A: Compromised Entity Details Template Upon notification of a suspected account data compromise, Visa Europe will request that the Visa Europe member initiate a preliminary investigation of any entity involved in a potential cardholder data compromise. To comply with Visa Europe s initial investigation request, the Visa Europe member must provide the following information. KEY POINT TO REMEMBER The information required below is applicable to suspected/confirmed compromised entities such as Visa Europe members, merchants, processors, or third-party service providers. Compromise Entity Details Compromise Entity Details Information to be provided by the Acquirer within 3 business days. Entity Details DESCRIPTION RESPONSE Acquirer name: Visa Europe Case Reference: Entity name: Entity Address: If a merchant, MCC: Acquiring BIN: E-commerce merchant: Yes/No POS transactions: Yes/No Entity PCI DSS Validation Level: 1/2/3/4 (before the compromise) Is entity a direct connect to Visa: Yes/No * Entity PCI DSS Compliance status: Name of Service Provider or Hosting Provider: If merchant, date entity began processing with acquirer: If merchant, date entity stopped processing with acquirer (if applicable): Approximate number of transactions/accounts handled per year 1) ATM: 2) POS: 3) e-commerce:

* If Yes, please complete Appendix F Request for Information-External Compromise Compromised Entity Details Data Elements at Risk: DESCRIPTION Account Number: Yes/No Expiration Date: Yes/No CVV2: Yes/No Track 1: Yes/No Track 2: Yes/No PIN: Yes/No Cardholder name/address: Yes/No Number of Visa Cards affected: Window of Exposure or Period of Compromise: RESPONSE Steps taken to contain the compromise:

Appendix B: Acquirer Investigation Report Template If the incident has less than 10,000 accounts at risk a forensic investigation may not be required. However, the acquirer must complete an Acquirer Investigation Report and include a detailed reason why it has been determined that a forensic investigation is not required and how the compromise has been contained. Acquirer must complete this report within 3 weeks from initial notification.

Acquirer Investigation Report Further information that must be provided by the acquirer if no forensic examination is to be conducted. DESCRIPTION RESPONSE Acquirer name: Visa Europe Case Reference: Entity name: How did the compromise take place? Has the compromise been contained? If so how? How many Visa cards were compromised? Was the entity storing track2 data? Was the entity storing CVV2? Was the entity storing PAN and expiry date? What data elements were compromised? Was the entity PCI DSS compliant? If not what were the major non compliances? Has the entity completed a PCI DSS gap analysis? Has the entity a remediation Plan? Is the entity having its public IP addresses scanned by a ASV? Are they passing those scans? Has the entity engaged a PFI? When will the entity be PCI DSS compliant? Network/Host Information DESCRIPTION RESPONSE Is there Internet connectivity? Is there wireless connectivity Does entity utilise a high-speed connection (e.g., cable modem, DSL)? Is there remote access connectivity? If so, who has remote access? Is remote access always on or is it enabled upon request? What type of remote access software is used? Is the terminal PC-based or is it connected to a PCbased environment? Has entity noticed any abnormal activity on its systems? Acquirer Investigation Report Is the entity retaining full track data, CVV2 or encrypted PIN blocks? How long is the data stored on the system(s)? Have there been any recent changes to the network and host such as: Upgrade to the payment application Installation of a firewall Installation of anti-virus program

Changes to remote access connectivity Provide a transaction flow for credit and debit, as well as remote access to the network. The data flow must include: Cardholder data sent to a central corporate server or data centre Upstream connection to third-party service providers Connection to entity bank/acquirer Remote access connection by third-party service providers or internal staff Third-Party Connectivity DESCRIPTION RESPONSE Does the entity send transactions to a processor(s)? If so, who is the processor(s)? Name of payment application vendor Name of reseller, if applicable Is the entity hosted? If so, who is the hosting provider? List of Payment Applications and PIN Entry Device (PED) in Use DESCRIPTION RESPONSE Payment application and version information Is this a corporate-mandated payment application and version? PIN Entry Device (PED) information, if applicable. Include the name of the PED firm ware version. Visit www.pcisecuritystandards.org/pin for a list of PCIapproved PIN entry devices. Shopping cart and version information Are the payment applications in use PCI PA-DSS compliant? Visit www.pcisecuritystandards.org/security_standards/vpa for a list of PA-DSS compliant payment applications. Is entity using a compliant PED? Visit www.pcisecuritystandards.org/pin for a list of compliant PEDs. Potential Skimming/PED Tampering DESCRIPTION RESPONSE Can entity trace legitimate transactions to a single employee, device, or lane(s)? Did entity have any employees who were employed for a short period of time? Did other employees notice suspicious behaviour of the new employee (e.g., eager to handle all credit card transactions)? Is there any video surveillance and has it been reviewed? Can all PEDs be accounted for at all times?

Are any of the POS PEDs in use listed on the November 2007 Security Alert available at www.visa.com/cisp? Steps taken to contain the compromise DESCRIPTION Provide full details of remediation steps taken to date What date did the e-commerce merchant pass a remote vulnerability scan? Which ASV or QSA company conducted the vulnerability scan? Other Information DESCRIPTION Has entity received complaints regarding fraudulent transactions from their customers? Has entity been contacted by law enforcement regarding fraudulent transactions? Can law enforcement provide intelligence that skimming groups are active in the area? RESPONSE RESPONSE

Appendix C: Forensic Investigation Guidelines A Visa Europe member or compromised entity must ensure that only a Visa Europe approved Qualified Forensic Investigator (PFI) is engaged to perform a forensic investigation. All PFIs are required to adhere to the following forensic investigation guidelines. Visa Europe members can also use these guidelines to monitor the work by the PFI. Visa Europe will NOT accept forensic reports from non-approved forensic companies. PFIs are required to release forensic reports and findings to Visa Europe. php Note: List of PCI Forensic Investigators:- https://www.pcisecuritystandards.org/approved_companies_providers/pfi_companies. Forensic investigations must be conducted using the following scope and methodology: 1. PFI will assess compromised entity s computing environment to determine the scope of the forensic investigation and relevant sources of electronic evidence. This includes, but is not limited to: o Assessment of all external and internal connectivity points within each location involved. o Assessment of network access controls between compromised system(s) and adjacent and surrounding networks. KEY POINT TO REMEMBER Visa Europe reserves the right to engage a PFI directly if an investigation is not carried out expediently. 2. PFI will acquire electronic evidence from the compromised entity s host and network-based systems. o Forensic evidence acquisition must be conducted onsite at the compromised entity s premises. o If circumstances do not permit onsite evidence acquisition, PFI must notify Visa Europe. o Preservation of all potential electronic evidence on a platform suitable for review and analysis by a court of law, if applicable. 3. Forensically examine electronic evidence to find cardholder data and establish an understanding of how a compromise may have occurred.

4. Verify that cardholder data is no longer at risk and/or has been removed from the environment. 5. Verify that the compromised entity has contained the incident. 6. Within five (5) business days from the onset of the onsite forensic investigation, the PFI must use Visa Europe s Preliminary Incident Report Template (see appendix D, page 27) and provide a preliminary forensic report to all parties involved in the incident. 7. Perform external and internal vulnerability scans, including network and application scans. 8. The following actions must be included as part of the forensic investigation: o Determine and describe the type of processing environment: - Organisation description (check all that apply): - VisaNet processor - Issuer only - Acquirer only - Both issuer and acquirer - Pre-paid issuer - Third-party processor - Merchant - Other: o Estimated annual number of credit and or debit transactions for Visabranded products (based on interview; exact numbers are not required): - Visa credit - Visa debit (Visa Signature only) - Visa with PIN (ATM with PIN) - Interlink (POS with PIN) - Plus (ATM with PIN) - Visa Prepaid (include list of Prepaid products) - Other:

9. Check and determine cardholder information that is at risk. This includes: o Number of and types of Visa/Plus/Interlink/Prepaid accounts at risk. Identity those stored and captured by malware (e.g., packet sniffer, key logger). o List of associated account information at risk: - Full magnetic-stripe data (e.g., Track 1 and 2) - PIN blocks and clear-text PINs. To identify potential presence of PIN blocks, also look for the PIN block format code field. - CVV2 - Account number - Expiration date - Other sensitive data elements (e.g., SSN, DOB) - Cardholder name - Cardholder address - Cardholder e-mail address o o o o o PFI to examine all potential locations, including payment applications, to determine if full magnetic-stripe data, CVV2, and/or PIN blocks are stored (whether encrypted or unencrypted) on production, backups, tables, development, test, software engineer, and administrator s machines. PFI should also check volatile memory for cardholder data. If malware was used to capture cardholder data, PFI must review any malware output logs and validate whether cardholder data was captured and stored. Other logs that must be reviewed include the following: - Server - Application - Transaction - Troubleshooting - Debug - Exception or error files PFI must provide account information to Visa Europe (see Requirements for Account Data Request, page 15).

10. Determine time frame of accounts at risk. For example: o Determine how long accounts were stored on the system(s). o Determine the transaction date(s) of accounts stored on the system(s). 11. Perform incident validation and assessment. This includes: o o o Establishing how a compromise occurred. Identifying the source of the compromise. Window of system vulnerability. This is defined as the frame of time in which a weakness(s) in an operating system, application or network could be exploited by a threat to the time that weakness(s) is properly remediated. o Determining if any cryptographic keys have been exposed or compromised. o Reviewing the entire debit and/or credit processing environment to identify all compromised or affected systems; considering the e- commerce, corporate, test, development, production systems, VPN, modem, DSL, cable modem connections, and any third-party connections. o If applicable, review VisaNet endpoint security and determine risk. o Identifying the date(s) that account data was transferred out of the network by the intruder or malware. o Date(s) when the entity began using the payment application and version number. Determine if the payment application is PA-DSS compliant. o If available, identify the date(s) when the entity installed a patch or an upgrade to no longer retain prohibited data. o The date(s) that malware was installed on the system, if applicable. o Date(s) when malicious code, such as packet sniffer and/or key logger, was activated to capture payment card data on the network and system. PFI must include date(s) of when malware was de-activated. o Determine the window of intrusion. This is the first confirmed date that the intruder or malware entered the system to the date of containment 12. Determine what applicable PCI security requirements apply: o PCI DSS o PCI PIN Security Requirements o PCI POS PIN Entry Device Security Requirements o PCI Encrypting PIN PAD (EPP) Security Requirements o PCI PA-DSS 13. If malware and bad IPs are identified in the compromise, the PFI must submit the malware code and bad IPs via a secure distribution to the secure email address datacomp@visaonline.com.

14. Within ten (10) business days from the completion of the forensic investigation, PFIs must utilize Visa Europe s Final Incident Report template (see Appendix: E), and provide a forensic report to all parties involved in the incident. Table of Entities and Requirements Applicability REQUIREMENTS TYPES OF ENTITIES Issuer Processo r Acquirer Processor Credit Only Merchan t Debit Acceptin g Merchant Issuer and Acquirer Processo r ATM Processo r Third- Party Servicer PCI DSS Applies Applies Applies Applies Applies Applies Applies PCI PIN Security Requirements Applies if driving their own ATMs Applies if processin g debit N/A Applies Applies Applies Applies if processin g debit PCI POS and PCI EPP PIN Entry Device Security Requirements N/A Applies if processin g debit N/A Applies Applies Applies Applies if processin g debit PCI PA-DSS Applies Applies Applies Applies Applies Applies Applies

Appendix D: PCI SSC Preliminary Incident Response Report Template Report Templates and Aids for PFI Investigations Question Name of Compromised Entity Date arrived onsite Preliminary Incident Response Report Response Evidence of a breach? Yes No First confirmed date that the intruder or malware entered the network: Scope of forensic investigation (e.g., single vs. numerous locations; how systems/network were determined for acquisition) Type of data impacted (e.g., full track, CID, CAV2, CVC2, CVV2, encrypted or clear-text PINs) Window of system vulnerability Initial thoughts on attack vector Is the security breach ongoing or has it been contained? If contained, how has it been contained? Estimated date of investigation completion:

Other comments WHAT TO DO IF COMPROMISED

Appendix E: PCI SSC Final Incident Report Template Report Templates and Aids for PFI Investigations Final Incident Report Guidance Notes included in the body of template below are informational only and aimed at providing direction to the PFI on how to complete the Final Incident Report. As such, the Guidance Notes are not required to be included in the submitted report. Definitions for certain terms in this template are provided below in Appendix B I. Executive Summary (include the following information) Date of PFI engagement Date forensic investigation began Locations(s) visited or forensically reviewed Summary of environment reviewed Details must be documented under Findings section. Conclusive evidence of a breach (Y/N) If no, please provide reasons why inconclusive. Date(s) of intrusion Cause of the intrusion (List applicable attack vectors as per Appendix A.) Breach: Yes No Not contained Contained (specify how): II. Background Type of business entity Merchant (brick and mortar, e-commerce, or both) Prepaid issuer Issuer Acquirer Acquirer processor Issuer processor ATM processor Third-party service provider (web hosting; co-location) Encryption Support Organization (ESO) Payment application vendor Payment application reseller

Other information Number of locations Parent company (if applicable) Franchise or corporate-owned III. Incident Dashboard Date when entity identified compromise Method of identification Self-detection Common point of purchase Other (describe below) Window of system vulnerability Window of intrusion Malware installation date(s), if applicable Date(s) of real time capture, if applicable Date(s) that data was transferred out of the network, if applicable Window of payment card data storage Transaction date(s) of stored accounts Payment application information: 1. Name, version, and install date of application at the time of the breach 2. Name, version, and install date of current application 3. Reseller/IT support that manages payment application/network 4. Payment application vendor Name, version, and vendor of software that stored the CID, CAV2, CVC2, CVV2, or track data This information must be supplied if CID, CAV2, CVC2, CVV2, or track data has been stored. Type of data exposed Check applicable data elements. Brand exposure Name of software: Version number: Vendor name (or state in-house ): Cardholder name Cardholder address PAN Expiry date Visa MasterCard Discover CID, CAV2, CVC2, CVV2 Track data (track 1, 2, or both) Encrypted or clear-text PINs or PIN Blocks American Express JCB Other:

Number of cards exposed (both live system space and unallocated space) a. Breakdown by Payment Card Brand: American Express Discover JCB MasterCard Visa b. Breakdown of the following: Signature Logs that provided evidence: File creation/access date PIN-based transactions Issuer-only data Non-issuer data Prepaid data Firewall logs Transaction logs Database queries FTP server logs System login records File-integrity monitoring output Intrusion-detection systems Remote-access logs Wireless connection logs Anti-virus logs Web server logs Security event logs Hardware Security Module (HSM) logs Suspected cause summary and list of attack vectors (See attached List of Attack Vectors.) Insert (or attach) brief case summary. Detailed findings should be included in the Findings section of the report. Assessment of residual risk Is card data still at risk? Yes No If yes, please describe the residual risk: Date and case number from law enforcement report: If the case has not been reported to law enforcement, please explain why. If applicable, document the type of cryptographic keys at risk. Issuer Side Cryptographic Keys Acquirer Side Cryptographic Keys Issuer working keys (IWK) Acquirer working keys (AWK) PIN verification keys (PVK) POS, ATM, EPP PIN encryption keys PIN generation keys POS, ATM, EPP key-encrypting keys (KEKs) Master derivation keys (MDK) Remote initialization keys Host-to-host working keys Host-to-host working keys

Issuer Side Cryptographic Keys Key-encrypting keys (KEKs) Switch working keys Other (describe) Acquirer Side Cryptographic Keys Key-encrypting keys (KEKs) Switch working keys Other (describe) If applicable, document the type of Card Validation Codes or Values at risk. Magnetic Stripe-Based Security Features Printed Security Features CAV Card Authentication Value CID Card Identification Number (JCB payment cards) (American Express and Discover payment CVC Card Validation Code cards) (MasterCard payment cards) CAV2 Card Authentication Value 2 CVV Card Verification Value (JCB payment cards) (Visa and Discover payment cards) CVC2 Card Validation Code 2 CSC Card Security Code (MasterCard payment cards) (American Express) CVV2 Card Verification Value 2 (Visa payment cards) IV. Network Infrastructure Overview Guidance Note When completing this section: 1. Provide a diagram of the network that includes the following: Cardholder data sent to central corporate server or data center Upstream connections to third-party processors Connections to acquiring payment card brand networks Remote access connections by third-party vendors or internal staff Include remote access application(s) and version number Inbound/outbound network connectivity Network security controls and components (network security zones, firewalls, hardware security modules, etc.) 2. Clearly identify all infrastructure components implemented or modified after the timeframe of the compromise.

V. Findings Guidance Note When completing this section: Provide specifics on firewall, infrastructure, host, and personnel findings. Identify any and all changes made to the Compromised Entity s computing environment after the identification of a compromise. Provide specific dates of network, system, or payment application changes. Include any and all forensic evidence supporting changes made to networks, systems, and POS components. Identify any data accessed by unauthorized user(s). Identify any data transferred out of the network by unauthorized user(s). Identify any evidence of data-deletion from systems involved in a compromise. If applicable, identify any deleted data recovered through forensic file recovery methods. Identify any third-party payment applications, including version number. Identify remote access application(s) and version(s) used. Identify third-party service provider (i.e., web-hosting, reseller/integrator, POS vendor). Identify any upgrades/patches to the payment application that address removal of magnetic-stripe data, Card Validation Codes or Values, and/or encrypted PIN blocks. Provide an attack timeline of events. Include relevant date(s) and activities (e.g., date/time created, system/file evidence, description of evidence). Include a list of compromised systems/hosts (e.g., operating system, service pack/hotfix, application), and their functionality. Include a list of malicious IPs. Include any information related to malicious IPs (e.g., part of hacker group, TOR, or anonymous relay addresses). Include a list of all malware identified. Include the following information on malware: Name of malware MD5/SHA/Fuzzy Hash Registry settings File size System path Provide description of malware based on PFI s malware analysis. Provide detailed analysis and feedback regarding all inconclusive cases and the PFI s opinion as to the reason for the forensic investigation being inconclusive. VI. Compromised Entity Containment Plan Guidance Note When completing this section, document what the entity has done to contain the incident. Include date(s) of containment.

VII. Recommendation(s) Guidance Note When completing this section, list recommendations by priority level. VIII. PCI DSS Compliance Status Based on findings identified in the forensic investigation, indicate the compliance status for each of the 12 basic requirements under the PCI DSS. Document the specific PCI DSS requirements and sub-requirements that contributed to the security breach. PCI DSS Requirement Build and Maintain a Secure Network Requirement 1: Install and maintain a firewall configuration to protect cardholder data Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters Protect Cardholder Data Requirement 3: Protect stored cardholder data Requirement 4: Encrypt transmission of cardholder data across open, public networks Maintain a Vulnerability Management Program Requirement 5: Use and regularly update antivirus software Requirement 6: Develop and maintain secure systems and applications Implement Strong Access Control Measures Requirement 7: Restrict access to cardholder data by business need-to-know Requirement 8: Assign a unique ID to each person with computer access Requirement 9: Restrict physical access to cardholder data Regularly Monitor and Test Networks Requirement 10: Track and monitor all access to network resources and cardholder data Requirement 11: Regularly test security systems and processes Maintain an Information Security Policy In Place Cause of breach? Yes/No Yes/No Yes/No Yes/No Yes/No Yes/No Yes/No Yes/No Yes/No Yes/No Yes/No Yes/No Yes/No Yes/No Yes/No Yes/No Yes/No Yes/No Yes/No Yes/No Yes/No Yes/No Include specific forensic findings

PCI DSS Requirement Build and Maintain a Secure Network Requirement 12: Maintain a policy that addresses information security In Place Cause of breach? Yes/No Yes/No Include specific forensic findings

List of Attack Vectors This appendix is informational, and it need not be included with the submitted report. One or more of the attack vector types listed below are to be used in completing the Cause of the intrusion item in Section I above. Vector Type Host Network Remote Access Specifics Host Auto login enabled Host Local accounts are default/unsecured Host Local accounts have weak passwords Host No/limited system hardening Host No/limited system logging Host System allows insecure remote access Host System contains PAI/track data Host System has unrestricted network/internet access Host System interfaces with POS environment Host System lacks anti-virus/anti-malware/hips Host System not inventoried/accounted Host System not patched/maintained Host System runs high-risk/insecure applications Host System runs non-standard/proprietary software Host System used for personal reasons Network Default configurations in use Network Default passwords in use Network Default/common ports allowed or in use Network Network accounts have weak passwords Network No ACLS present/in use Network No anti-virus/anti-malware Network No encryption Network No firewall present Network No ingress/egress filtering Network No network segmentation Network No secured remote access Network No security monitoring Network No separate POS environment Network No/insufficient logging Network Use of insecure protocols Remote Access No monitoring/logging of remote access Remote Access Out-dated/known vulnerable hardware/software in use Remote Access Remote access forwarding allowed Remote Access Remote access left permanently enabled Remote Access Unrestricted remote access allowed Remote Access Use of blackbox/proprietary hardware/software Remote Access Use of default passwords/accounts

Vector Type Web Attack Specifics Remote Access Use of default/out-of-box configuration Remote Access Use of insecure remote software (e.g., VNC) Remote Access Use of known POS vendor defaults Remote Access Use of weak passwords Web Attack Allocation of Resources Without Limits or Throttling Web Attack Buffer Access with Incorrect Length Value Web Attack Buffer Copy without Checking Size of Input (Classic Buffer Overflow) Web Attack Cross-Site Request Forgery (CSRF) Web Attack Download of Code Without Integrity Check Web Attack Improper Access Control (Authorization) Web Attack Improper Check for Unusual or Exceptional Conditions Web Attack Improper Control of Filename for Include/Require Statement in PHP Program (PHP File Inclusion) Web Attack Improper Limitation of a Pathname to a Restricted Directory (Path Traversal) Web Attack Improper Sanitization of Special Elements used in an OS Command (OS Command Injection) Web Attack Improper Sanitization of Special Elements used in an SQL Command (SQL Injection) Web Attack Improper Validation of Array Index Web Attack Incorrect Calculation of Buffer Size Web Attack Incorrect Permission Assignment for Critical Resource Web Attack Information Exposure Through an Error Message Web Attack Integer Overflow or Wraparound Web Attack Missing Authentication for Critical Function Web Attack Missing Encryption of Sensitive Data Web Attack Race Condition Web Attack Reliance on Untrusted Inputs in a Security Decision Web Attack Unrestricted Upload of File with Dangerous Type Web Attack URL Redirection to Untrusted Site (Open Redirect) Web Attack Use of a Broken or Risky Cryptographic Algorithm Web Attack Use of Hard-coded Credentials Web Attack Failure to Preserve Web Page Structure (Cross-site Scripting)

List of Investigation Definitions for Final Incident Reports This appendix is informational and it need not be included with the submitted report. Terminology Date(s) that data was transferred out of the network Date and version of POS installation(s) Malware installation date(s) Date(s) of real-time capture Window of intrusion Transaction date(s) of stored accounts Window of system vulnerability Description The confirmed date(s) that data was transferred out of the network by the intruder or malware. Date(s) when the entity began using the POS application and version number. If available, include date(s) when entity installed a patch or an upgrade to no longer retain prohibited data. The date(s) that malware was installed on the system, if applicable. Date(s) that malicious code/malware, such as packet sniffer and/or key logger, was activated to capture payment card data on the network and system. Should also include date(s) that malware was de-activated. First confirmed date that intruder or malware entered the system to the date of containment. Examples of containment include, but are not limited to: Removal of malware or rebuilt of compromised systems Compromised system removed from the network Blocking of malicious IPs on the firewall Rotation of compromised passwords The date(s) of the transactions stored on the system. a) The timeframe in which a weakness in an operating system, application, or network could be exploited by a threat to the time that weakness is properly remediated. It answers the question, "How long was the system at risk to a given compromise?" b) Overall time period that a system was vulnerable to attack due to system weaknesses for example, lack of or poorly configured firewall, missing security patches, insecure remote access configuration, default passwords to POS systems, insecure wireless configuration.

Appendix F: Request for Information -- External Compromise The below assumes the external entity in question has a confirmed connection to Visa. Please validate the type of connection from your organisation to Visa. (e.g., Visanet connection, Visa Debit connection, EA/Edge connection, etc.) Please verify the current state of your connection to Visa. (e.g., active, disconnected, stand-in, etc.) Please confirm if your organisation has initiated any plans to disconnect your network(s) from Visa while pursuing this incident. Please furnish a detailed network diagram depicting connectivity to Visa. Please include all relevant internal addressing, inclusive of any NAT/PAT, for directly connected systems or devices. Please clearly delineate those portions of the network that have been directly affected or impacted, particularly if your organisation maintains network operations and/or access in multiple locales through logical or physical segmentation. Please describe your organisation s post-breach security monitoring and alerting activities with particular regard to those systems and devices connected to Visa. Please supply a list of known compromised systems by hostname, IP address, function and OS type. Please supply a list of known compromised technologies by function, type and system declaration. Please supply a list of known compromised user id and system id accounts. Please indicate which accounts were utilized on which compromised systems. Please deliver a detailed accounting of all confirmed attack vectors and patterns utilized by the intruder. Wherever possible, please provide exact log detail. When providing log detail, please be sure to note current time zone settings if not readily deduced from the detail. Please declare all ingress and egress points for your network(s) if not already identified in the requested network diagram detail. Please note if any connections are shared. Please furnish a list of suspect/malicious IP addresses and corresponding port numbers utilized by the intruder/attacker by source and destination. Please provide a list of malware installed on compromised systems by name, system declaration, malware description, hash value and installation date (where known). Please furnish the malware binaries where possible. Please supply a copy of your organisation s current breach containment procedures. Please be sure to outline any pending or partial containment measures.

Appendix G: List of Supporting Documents The following document can be downloaded from: https://www.pcisecuritystandards.org/approved_companies_providers/pfi_companies.php PCI Forensic Investigator (PFI) List -- List of forensic companies qualified to perform a PCI forensic investigation on compromised entities. The following documents can be downloaded from: www.pcisecuritystandards.org Qualified PCI Assessor (QSA) - List of assessors qualified to perform PCI assessments for those entities requiring onsite validation of PCI compliance. PCI Data Security Standard (PCI DSS) -- Detailed security requirements to which Visa Europe members, merchants, and service providers must adhere to ensure the protection of cardholder data. PCI Security Audit Procedures -- Detailed security requirements, guidelines, and testing procedures to assist a PCI QSA in verifying that an entity is in compliance with the PCI DSS. PCI Self-Assessment Questionnaire (SAQ) - The PCI SAQ is an important validation tool primarily used by smaller merchants and service providers to demonstrate compliance to the PCI DSS. Responses must address any system(s) or system component(s) involved in processing, storing, or transmitting Visa cardholder data. Note: For any answers where N/A is marked, a brief explanation should be attached. PCI Security Scanning Procedures - Procedures and guidelines for conducting network security scans for entities and third-party service providers who are scanning their infrastructures to demonstrate compliance to the PCI DSS.

Appendix H: Glossary of Terms 802.11 IEEE 802.11 is a set of standards for wireless local area network (WLAN) computer communication, developed by the IEEE LAN/MAN Standards Committee (IEEE 802) in the 5 GHz and 2.4 GHz public spectrum bands. Acquirer Agent At Risk Accounts Financial institution that enters into agreements with merchants to accept Visa cards as payment for goods and services. Commonly referred to as the merchant bank. Any contractor, including third-party processors and servicers, whether a member or nonmember, engaged by a member or a merchant to provide services or act on its behalf in connection with Visa payment services. Refers to accounts that were included in a VAB Alert of a suspected or confirmed compromised event. Authentication The process of verifying the true origin or nature of the sender and/or the integrity of the text of a message. Authorisation Backdoor Bank Identification Number (BIN) Card Authorization Acceptor ID Card Not Present Card Present A process by which an issuer approves a transaction for a specified amount with a merchant. A method of bypassing normal authentication and obtaining access to plaintext information while attempting to remain undetected. The backdoor may take the form of an installed program (e.g., Back Orifice), or could be a modification to an existing program or hardware device. A unique number assigned by the bankcard association to its members. On a cardholder s account number, the BIN appears as the first six digits. Visa BINs begin with the number 4. Information found in the authorization message (Field 42) from a legitimate transaction at the Acceptor ID CPP-identified merchant. A merchant, market, or sales environment where transactions occur without a valid Visa card being present. Card not present is used to refer to mail order/telephone order merchants and sales environments, as well as the Internet. A merchant, market, or sales environment in which a transaction can be completed only if both a valid Visa card and the cardholder are present and the sale is processed by an individual representing the merchant or the acquirer. Card present transactions include face-to-face retail sales and cash disbursements.

Common Point of Purchase (CPP) Card Verification Value (CVV) Refers to the location of a legitimate transaction (usually a purchase or cash advance transaction) common to a number of accounts involved in a fraud scheme of similar character. The common point of purchase is assumed to be the point of compromise. A unique three-digit check number encoded on the magnetic stripe of all valid cards. The number is calculated by applying an algorithm (a mathematical formula) to the stripe-encoded account information, and is verified online at the same time that a transaction is authorised. Card Verification Value 2 (CVV2) Cardholder Cardholder Data Member Compromise A Visa fraud prevention system used in card-not-present transactions to ensure that the card is valid. The CVV2 is the three-digit value that is printed on the back of all Visa cards. Card-not-present merchants ask the customer for the CVV2 and submit it as part of their authorization request. For information security purposes, merchants are prohibited from storing CVV2 data. The person or entity whose name is embossed on the face of a card or encoded on the magnetic stripe. All identifiable personal data about the cardholder and the relationship to the member (e.g., account number, expiration date, data provided by the member, other electronic data gathered by the merchant/agent). This term also applies to other personal insights gathered about the cardholder such as address, telephone number, etc. An organisation that is a member of Visa Europe and issues cards and/or signs merchants. Process that exposes cardholder account information to third parties, placing cardholders at risk of fraudulent use. Compromised Account Accounts downloaded by an intruder or found in criminal possession. Cryptographic Key A parameter used in conjunction with a cryptographic algorithm that determines: The transformation of plaintext data into ciphertext data The transformation of ciphertext data into plaintext data A digital signature computed from data The verification of a digital signature computed from data An authentication code computed from data or An exchange agreement of a shared secret Denial of Service (DoS) Electronic Commerce (e-commerce) Denial of Service (DoS) is a tool or program used by intruders to cause networks and/or computers to cease operating effectively or to erase critical programs running on the system. The purchase of goods and services over the Internet without a paper transaction between buyer and seller.

Entity Encryption Event Full-Track Data An organisation that stores, processes or transmits account information. Typically the victim in a compromise. Also refers to any payment industry organisation that must be PCI DSS compliant. An online data security method that scrambles data so that it is difficult to interpret without a corresponding decryption key. Refers to a single event of a known or suspected data compromise. It is used interchangeably with the term incident. There are two tracks of data on a bankcard s magnetic stripe: Track 1 is 79 characters in length. It is alphanumeric and contains the account number, the cardholder name, and the additional data listed on Track 2.. Track 2 is the most widely read. It is 40 characters in length and is strictly numeric. This track contains the account number, expiration date, secure code, and discretionary institution data. Hacker IEEE (Institute of Electrical and Electronics Engineers, Europe) A person who deliberately logs on to other computers by circumventing the log-on security system. This is sometimes done to steal valuable information or to cause damage that might be irreparable. The Institute of Electrical and Electronics Engineers, Europe, is an international non-profit, professional organisation for the advancement of technology. More info at www.ieee.org. Incident Incident Response Managers Refers to each single occurrence of known or suspected data compromise. It is used interchangeably with the term event. Visa Europe staff designated by a regional office to coordinate response to incidents. Issuer Magnetic Stripe (Mag Stripe) Man-in-the- Middle (MITM) MD5 Hash A financial institution that issues Visa products. A strip of magnetic tape located on the back of all bankcards. The magnetic stripe is encoded with identifying account information as specified in the Visa Operating Regulations. On a valid card, the account information on the magnetic stripe matches similar embossed information located on the front of the card. A form of eavesdropping in which an attacker makes independent connections with the victims and relays messages between them, making the victims believe that they are talking directly to each other over a private connection when in fact the entire conversation is controlled by the attacker. The MD5 hash (also known as checksum) for a file is a 128-bit value, similar to taking a fingerprint of a file.

Member Merchant Merchant Bank Merchant Level PAN Payment Card Industry Data Security Standard (PCI DSS) PCI Security Standards Council ( PCI SSC ) PCI Forensic Investigator (PFI) An organisation that is a member of Visa Europe and issues Visa cards and/or acquires merchant transactions. An entity that enters into a card acceptance agreement with a Visa Europe acquirer or processor. See Acquirer. All merchants fall into one of four merchant levels based on Visa transaction volume over a 12-month period. Primary Account Number. A set of requirements established by the payment card industry to protect cardholder data. These requirements apply to all members, merchants, and service providers that store, process, or transmit cardholder data. The PCI Security Standards Council is an open global forum, launched in 2006, that is responsible for the development, management, education, and awareness of the PCI Security Standards, including: the Data Security Standard (DSS), Payment Application Data Security Standard (PA-DSS), and Pin-Entry Device (PED) Requirements.. For more information on PCI SSC, visit www.pcisecuritystandards.org/. PCI SSC-approved security vendors who perform forensic investigations in the event of a security incident. A list of PFIs can be obtained at https://www.pcisecuritystandards.org/approved_companies_providers/pfi_companies.php Personal Identification Number (PIN) Point of Compromise (POC) Qualified Security Assessor (QSA) Company Rootkit Secure Shell (SSH) An alphabetic and/or numeric code which may be used as a means of cardholder identification Refers to the location where account number data was obtained by unauthorised third parties. A security company qualified by the PCI SSC to perform a PCI Data Security Assessment according to the PCI Security Audit Procedures. Please visit the PCI Security Standards Council website (www.pcisecuritystandards.org) for details on the PCI program requirements. A program designed to take administrative control of a computer system without authorization from the system s owners. Secure Shell is a network protocol that allows data to be exchanged using a secure channel.

Service Set Identifier (SSID) Telnet (Telecommunic ations Network) Third-Party Processor Third-Party Servicer Visa Account Bulletin (VAB) Visa Account Information Security (AIS) Programme Service Set Identifier is the name used to identify the particular 802.11 wireless LAN to which a user wants to attach. A network protocol used on the Internet or on Local Area Network (LAN) connections. A service provider organisation acting as the member s agent to provide authorization, clearing, or settlement services for merchants and members. A service provider organisation that is not a member of Visa Europe and is not directly connected to VisaNet, but provides the following services to the member or merchants: Response processing for Visa program solicitations Transaction processing (including gateways) Data capture Other administrative functions such as chargeback processing, risk/security reporting, and customer service The Visa Account Bulletin is a Visa Europe to member contact tool for the distribution of accounts at risk. As this information is loaded into VAB, e-mail alert messages are automatically sent to registered issuer users to notify them of the compromised and stolen/recovered accounts. A Visa Europe program that establishes data security standards, procedures, and tools for all entities (merchants, service providers, issuers, and merchant banks) that store Visa cardholder account information. AIS compliance is mandatory. AIS requirements prohibit merchants and service providers from storing the full contents of any magnetic stripe, CVV2, or PIN-block data. For more information regarding AIS, visit www.visaeurope.com/aboutvisa/security/main.jsp. VisaNet The data processing systems, networks and operations used to support and deliver authorization services, exception file services, clearing and settlement services and any other services. WAP (Wireless Application Protocol) An open international standard for application layer network communications in a wireless communication environment. WAP or AP (Wireless Access Point) WEP (Wired Equivalent Privacy) A computer networking device that allows wireless communication devices to connect to a wireless network using Wi-Fi and related standards. The WAP usually connects to a wired network and can relay data between both wireless and wired devices (such as computers or printers) on the network. An algorithm to secure IEEE 802.11 wireless networks. Wireless networks broadcast messages using radio and are more susceptible to eavesdropping than wired networks.

Appendix I: Investigation Definitions TERMINOLOGY DESCRIPTION Date(s) that data was transferred out of the network Date and Version of POS Installation (s) The confirmed date(s) that data was transferred out of the network by the intruder or malware. Date(s) of when the entity began using the POS application and version number. If available, include date(s) of when entity installed a patch or an upgrade to no longer retain prohibited data. Malware Installation Date(s) Date(s) of Real- Time Capture Window of Intrusion The date(s) that malware was installed on the system, if applicable. Date(s) of when malicious code/malware, such as packet sniffer and/or key logger, was activated to capture payment card data on the network and system. Should also include date(s) of when malware was de-activated. First confirmed date that intruder or malware entered the system to the date of containment. Examples of containment include, but not limited to: Removal of malware or rebuilt of compromised systems Compromised system removed from the network Blocking of malicious IPs on the firewall Rotation of compromised passwords Window of Storage "Window of Storage" is defined as the frame of time in which a given set of prohibited data is initially placed on a system to the time that same data was removed. It answers the question, "how long was the given set of data stored?" Transaction date(s) of stored accounts Window of System Vulnerability Transaction date(s) is defined as the date of the transactions stored on the system. "Window of Vulnerability" is defined as the frame of time in which a weakness in an operating system, application or network could be exploited by a threat to the time that weakness is properly remediated. It answers the question, "how long was the system at risk to a given compromise?" Overall time period that a system was vulnerable to attack due to system weaknesses. For example, lack of/or poorly configured firewall, missing security patches, insecure remote access configuration, default passwords to POS systems, insecure wireless configuration.