PCI DSS practical guide for Travel Agents

Transcription

1 PCI DSS practical guide for Travel Agents Guidance for achieving PCI DSS compliance PCI DSS demystified for Travel Agents PCI Program Office_ Marc. A. HENRY_ISA_ May 25th, 2017 Revision 5.3

2 Dear customer, Why is PCI DSS important to your business? The PCI DSS standard was established as a payment industry-wide set of requirements and processes to ensure that payment cardholders can make purchases confidently in the knowledge that the sensitive information on their card will be protected from fraudsters. The PCI DSS therefore offers a comprehensive approach to safeguarding sensitive data for all card brands. The PCI Security Standards Council owns, maintains and distributes the PCI DSS, as well as Payment Application standard, PIN Transaction Security standard, and many valuable recommendation documents. PCI DSS applies to all payment channels, including retail (brick-and-mortar), e-commerce and mail or telephone order. This guide adapted for Travel Agents will allow you to understand the certification process you will have to go through, as per IATA mandate (see next page) and practical steps you will have to implement, allowing achieving and maintaining compliance. THE INFORMATION CONTAINED IN THIS GUIDE IS BELIEVED TO BE ACCURATE AT THE TIME OF PRINT- ING, BUT NO REPRESENTATION OR WARRANTY IS GIVEN (EXPRESS OR IMPLIED) AS TO ITS ACCURACY, COMPLETENESS OR CORRECTNESS. NEITHER AMADEUS IT GROUP, S.A. NOR ANY OF ITS AFFILIATES OR SUBSIDIARIES ACCEPTS ANY LIABILITY WHATSOEVER FOR ANY DIRECT, INDIRECT OR CONSEQUEN- TIAL LOSS OR DAMAGE ARISING IN ANY WAY FROM ANY USE OF OR RELIANCE PLACED ON THE IN- FORMATION CONTAINED IN THIS GUIDE FOR ANY PURPOSE. Page 2 of 30

3 Introduction- General Information The Payment Card Industry Data Security Standard (PCI DSS) was elaborated for merchants and processors handling sensitive payment card information. The PCI DSS provides common data security standards to protect confidential payment card information against theft. All entities that store, process and transmit payment card data are required to adhere to the PCI DSS. The Payment Card Industry (PCI) Security Standards Council is responsible for managing the security standards for the payment card industry. There are 5 main payment card brands which took part in the creation of this Council: American Express, Discover Financial Services, JCB International, MasterCard, and Visa Inc. The PCI DSS has been in force since 2005 and are part of Resolution 818g since PaConf/39 added a provision to Resolution introducing a sanction in case of non-compliance. The compliance procedure will vary according to the type of payment system adopted by the agent, the number of credit card transactions, as well as the manner in which the credit card data is processed and stored. There are two main PCI DSS Compliance Reports attesting that the compliance procedure has been successfully accomplished: 1. Self-Assessment Questionnaire (SAQs of different types according to type of business) and 2. PCI DSS Attestation of Compliance (AOC). For an extract from the IATA second communication, reference publication paragraph. New PCI DSS compliance deadline for Travel Agents: link to IATA communication on date enforcement. Page 3 of 30

4 Index o Introduction- General Information... 3 o Index... 4 o Certification process summary... 6 o Compliance Validation Levels... 8 o Select your Self-Assessment Questionnaire (SAQ)... 9 o IATA guidelines o PCI DSS Rules applied to Travel Agents Ensure any software/application used is PCI certified Ensure all systems you are using, when processing cards, are PCI certified Ensure all your payment related service providers and fulfilment providers, are PCI certified (PSP) Ensure your IT environment and infrastructure has security best practices in place Implement secured authentication rules Implement secured remark handling Implement the right card display parameters Identify, inventory all payment processes and systems in your agency and related businesses Do you currently host, or have you hosted in the past, physical or virtual servers, with customer cards on? Ensure PCI DSS security rules are observed: Build your own road map/action list towards compliance o Support Documentation Amadeus 2017 PCI DSS certificate Reference Publications Support On line Training from card brands Services Page 4 of 30

5 Amadeus Contacts: Terms and conditions upon which this guide is supplied Glossary Page 5 of 30

6 Certification process summary Travel Agents need to ensure that at any step during their payment activities, PCI DSS requirements are applied, for the safeguarding of payment card information data, and related systems, this means as practical steps: 1- Identify Payment Card systems, displays, payment steps or storage; any card Sensitive Authentication Data such as Card Verification Values or Codes (CVV, CVC..) magnetic readers; any Point of Sale, or call centre, back office activities involving payment cards or card refund activities; all your software application processing cards, PNRs, Profiles, AIRs or IMRs. Output: inventory of all your payment systems, booking engines, any system containing or processing card payment information. Objective: you will have to demonstrate that PCI DSS payment security rules apply to all identified systems. 2- Minimize the number of systems identified above. This phase is named scope reduction phase, including masking cards on software, printed documents, sale reports and customer payment receipts. Each time a card storage or transmission is not related to a payment need, or a business need, it has to be eliminated, erased and the card numbers need to be truncated (see term definition paragraph). Output: minimize the card system scope. Objective: reduce your compliance effort. 3- Apply PCI DSS best practices to all remaining card payment systems, e.g. reduced scope: apply PCI DSS rules listed in this guide, including Do s and Don ts. (see in next paragraphs) Objective: action list to meet PCI DSS compliance. Depending on the type of findings, isolate any card process and payment systems. If applicable, refer to Guidance for PCI DSS scoping and network segmentation from the PCI DSS document library. This will allow you to better breakdown remediation areas and actions that need to take place. 4- Once scope reduction and segmentation step is achieved, identify the number of transactions and authorizations you process per year. Objective: determine in which category of merchant agent level or service provider level you belong to, leading to the set of assessment processes and questionnaire type you have to complete. Small travel agents with less than 20,000* payment authorizations a year (* volumes may vary between card brands) can conduct a self-assessment, as described in the sections below. Page 6 of 30

7 5- Depending on your level and type of card processing systems and processes, please complete the appropriate Self-Assessment Questionnaire - SAQ or Report On Compliance- ROC. (Report On Compliance document applies to large merchants and processors only) Output: SAQ gives you a list of not in place rules you have to implement, which should be reflected in your action plan. Objective: have all requirements in place before you can submit your SAQ Example of rule in paragraph Is the PAN masked 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 more than the first six/last four digits of the 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-of-sale (POS) receipts. Review policies and procedures Review roles that need access to displays of full PAN Examine system configurations Observe displays of PAN 6- Implement security requirements, according to the list of payment security gaps identified, this means you should build an action plan, with estimated dates. Important note: you can claim compliance only once all actions are in place; this means you have suppressed all non-conformances. 7- Last step: SAQ and the Attestation Of Compliance (AOC), should be submitted to your acquirer or card brand. A Power Point presentation of this document, for an overview only is also available, please refer to the contacts paragraph See more details in the next pages. Page 7 of 30

8 Compliance Validation Levels Determining your compliance validation level is key for the type of assessment you will have to conduct. Please contact your acquirer, or the credit card brand you are working with, to identify your type of business, and your compliance validation level. Visa Compliance Validation Levels: Visa Europe Merchant Levels : MasterCard Compliance Validation Levels: Each credit card brand has its own PCI DSS guidance and support pages, including on-line education pages. Take away: in most of cases, you will have to complete a self-assessment questionnaire, (SAQ). Please refer below to the dedicated SAQ section below, helping you to select the right questionnaire to be completed. Qualified Security Assessor: if your level is 2, 3 or 4, a QSA (external security auditor) is not required, you can complete the SAQ and AOC documents by yourself. However, if you operate servers, or at the discretion of your card brand/acquirer, an Approved Scanning Vendor may have to perform regular additional tests, quarterly, targeting your range of publicly exposed IP addresses. In a nutshell, if below 1Million e-commerce transactions a year, all card brand added, you should comply with levels 3 or 4, meaning SAQ completion to apply plus possible ASV scan if applies. The SAQ and AOC documents must be submitted to your card brand or your acquirer. PCI DSS standard web site: Page 8 of 30

9 Select your Self-Assessment Questionnaire (SAQ) The next table will allow guiding you for the selection of the applicable questionnaire (SAQ) to your situation, type of card processing and/or storage you handle. The High level principle is simple: independently of your number of transactions, e.g. level 4, the more type of card access, systems, or processes you have, the more controls you have to put in place and, the more complex the questionnaire. From a dozen of controls, it can end up to the full PCI DSS standard applicable, e.g. if you host a server that contains credit cards. SAQ type A A-EP B Description Card-not-present merchants (e-commerce or mail/telephone-order), that have fully outsourced all cardholder data functions to PCI DSS compliant third-party service providers, with no electronic storage, processing, or transmission of any cardholder data on the merchant s systems or premises. Not applicable to face-to-face channels. SAQ A is available In SAQs category E-commerce merchants who outsource all payment processing to PCI DSS validated third parties, and who have a website(s) that doesn t directly receive cardholder data but that can impact the security of the payment transaction. No electronic storage, processing, or transmission of cardholder data on merchant s systems or premises. Applicable only to e-commerce channels. SAQ A-EP is available In SAQs category Merchants using only: - Imprint machines with no electronic cardholder data storage, and/or - Standalone, dial-out terminals with no electronic cardholder data storage. Not applicable to e-commerce channels. SAQ B is available In SAQs category B-IP Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor with no electronic cardholder data storage. Not applicable to e-commerce channels. SAQ B-IP is available In SAQs category C-VT C P2PE Merchants who manually enter a single transaction at a time via a keyboard into an Internet-based, virtual payment terminal solution that is provided and hosted by a PCI DSS validated third-party service provider. No electronic cardholder data storage. Not applicable to e-commerce channels. SAQ C- VT is available In SAQs category Merchants with payment application systems connected to the Internet, no electronic cardholder data storage. Not applicable to e-commerce channels. SAQ C is available In SAQs category Merchants using only hardware payment terminals included in and managed via a validated, PCI SSC-listed P2PE solution, with no electronic cardholder data storage. Not applicable to e-commerce merchants. SAQ P2PE is available In SAQs category Page 9 of 30

10 D SAQ D for Merchants: All merchants not included in descriptions for the above SAQ types. SAQ D for Merchants is available In SAQs category SAQ D for Service Providers: All service providers defined by a payment brand as eligible to complete an SAQ. SAQ D for Service Providers is available In SAQs category Link to PCI SSC documentation portal, public and free documentation. IATA guidelines To support current and future IATA Accredited Agents to learn more about how to become PCI DSS compliant, obtain evidence or re-validate compliance, please visit: Please contact IATA's Customer Service through IATA customer Portal for further information. PCI DSS Rules applied to Travel Agents I. Ensure any booking, profile, payment related application used is PCI certified II. Ensure the systems they are using, when processing cards, are also PCI certified III. Ensure any of your payment related service providers, fulfilment systems, are PCI certified IV. Ensure Travel Agent IT environment and infrastructure has security best practices in place, such as supported OS, updated browsers, updated software applications and maintained anti-viruses. This point covers a large set of requirements. V. Implement secured authentication rules, detailed in this guide (covering PCI requirement 8) VI. Implement secured remark handling (covers partially PCI requirements 3 and 7) VII. Implement the right card display/masking parameters (covering PCI requirement 7) VIII. Identify and inventory all payment processes in your agency, IX. For each card present, e-commerce, POS, payment terminal or Call Centre payment transaction, ensure PCI DSS security rules are observed X. Build your own action plan and action list towards compliance This guide will support you in your journey towards achieving and maintaining PCI DSS compliance. Page 10 of 30

11 Ensure any software/application used is PCI certified. If you are an Amadeus user, then you can visit the VISA Europe portal, where Amadeus is included in the Merchant Agent list (in a PDF file that you can access from below link) as a payment processor (Amadeus not being a financial institution).this means that as of the date hereof any PCI DSS relevant products produced by Amadeus are certified and all payment flows, and cardholder data processing are operated in a PCI DSS certified Data Centre. VISA Europe VISA inc. Link MasterCard list of service provider (end of web page) Should you need more Amadeus product details, please contact your Amadeus account manager. Ensure all systems you are using, when processing cards, are PCI certified. As a travel agent, you may use some non-gds tools and applications, where you may find payment related data. Typical examples are: Mid-Back Office system Payment terminal (contact your bank or terminal support contact ) Call centre IVR: Interactive Voice Recording system, Tour product, leisure booking engine, Rail, Bus ticket sales etc. Any non GDS e-commerce B to C product For each identified application and system, please check its compliance and certification, from the Vendor web site and public Visa list. Page 11 of 30

12 Ensure all your payment related service providers and fulfilment providers, are PCI certified (PSP). If you have an agreement in place with a payment related service provider (PSP), please ensure your PSP is in compliance with PCI DSS. Again, most PSPs compliance is listed on Card brand web sites: Visa listed compliant service providers: MasterCard listed compliant service providers: Ensure your IT environment and infrastructure has security best practices in place. IT end user infrastructure is often a point of weakness as many different attack vectors are possible. This is why it is essential Travel Agents to apply minimum-security protection, safeguarding their assets. Typical critical malwares are ransomwares, where you will discover your data has been accessed and encrypted, and a ransom (money) will be requested in order to recover all your customer and business data. The following security best practices are therefore essential. 1-Protection from malware Objective: To ensure that information and information processing facilities are protected against malware. Minimum Anti-Virus and Anti Spyware must be installed and maintained up to date. o protect against malware must be implemented and combined with appropriate user awareness. 2-Backup Objective: To protect against loss of data. and tested regularly in accordance with an agreed backup policy. 3-Logging and monitoring Objective: To record events and generate evidence. - Event logging: Event logs recording user activities, exceptions, faults and information security events should be produced, kept and regularly reviewed. Page 12 of 30

13 - Protection of log information: Logging facilities and log information should be protected against tampering and unauthorized access. - Administrator and operator logs: System administrator and system operator activities should be logged and the logs protected and regularly reviewed. Clock synchronisation: The clocks of all relevant information processing systems within an organization or security domain should be synchronised to a single reference time source. 4-Wifi should be deactivated whenever possible Never activate Wi-Fi on a server or e-ticket printer server. Do not use WEP type or weak connection key, but WPA or better, WPA2 should be used. If willing to serve customers with public type of Wi-Fi, have it installed on a dedicated network, not allowing intrusion on your business network. 5-Control of operational software Objective: To ensure the integrity of operational systems. the installation of software on operational systems. 6-Technical vulnerability management Objective: To prevent exploitation of technical vulnerabilities. mation systems being used should be obtained in a timely fashion, the organization's exposure to such vulnerabilities evaluated and appropriate measures taken to address the associated risks. be established and implemented. s should 7 Information systems audit considerations Objective: To minimise the impact of audit activities on operational systems. tion of operational systems should be carefully planned and agreed to minimize disruptions to business processes. 8-Communications security 8.1 Network security management Objective: To ensure the protection of information in networks and its supporting information processing facilities. Network controls: Networks should be managed and controlled to protect information in systems and applications. Security of network services: Security mechanisms, service levels and management requirements of all networks services should be identified and included in network services agreements, whether these services are provided in-house or outsourced. Insure your firewall security settings are maintained, public ISPs, Internet Service Providers can be vulnerable. Contact you IT support. Segregation in networks: Groups of information services, users and information systems should be segregated on networks. Never expose a back office system directly on the public internet. Page 13 of 30

14 8.2 Information transfer Objective: To maintain the security of information transferred within an organization and with any external entity. Information transfer policies and procedures: Formal transfer policies, procedures and controls should be in place to protect the transfer of information with all types of communication facilities. Agreements on information transfer: Agreements should address the secure transfer of business information between the organization and external parties. Electronic messaging: Information involved in electronic messaging should be appropriately protected. Confidentiality or non-disclosure agreements: Requirements for confidentiality or non-disclosure agreements reflecting the organization's needs for the protection of information should be identified, regularly reviewed and documented. 9-Remote Access Ensure that no remote access client software is installed by any third party. Remote access software security should be proven, authorized and deactivated at any connection. If any doubt, please contact your IT department. Any remote connection must be logged and identified and for specific short purpose. Always log off, switch off equipment when no activity required. 10-Minimum desktop client versions secured browser connections. Please note that when accessing a web server, a secured connection need to be established. For the purpose, minimum browser versions must be used, as per listed in the support documentation, end of this document. PCI standard requires strong ciphers (e.g. encryption keys) to be used for a secured communication to be established client to servers. SSL shall not be used anymore, is not accepted by Amadeus. As from JUNE18, PCI standard requires all connections to be TLS 1.2 minimum, or TLS 1.1 with a strong Ciphers. Amadeus will establish specific communications. for the move to TLS 1.2 only secured connections. Page 14 of 30

15 Implement secured authentication rules If you lock your car doors, shouldn t you also lock your front-office? It s time to use the same security measures for your front-office as you use when accessing your online bank statements, viewing & sending s or accessing your social networking site. After all, wouldn t you want to protect your business with the same care that you protect your personal information? We are therefore proposing the following 7 easy measures to better protect your business so you can have the same peace of mind when it comes to protecting your business as with your personal life. Session time out to 15min, up to 30min with screen lock should be activated. More detailed rules apply, as listed in the table below. Page 15 of 30

16 Please contact us and have a ticket or Work Order opened in Amadeus should you need to change the default setting of your administrative accounts. Page 16 of 30

17 Implement secured remark handling Where should you enter payment card information? In order to secure your business, you must use the below fields in the PNR and profile to store the payment card information of your customers. By entering your customer s payment card information in any field other than the ones indicated below, you are assuming the associated risks of exposing your customer s cardholder data, which includes possible fraud, misuse or data breaches. Page 17 of 30

18 Implement the right card display parameters Travel agencies can play an important role in protecting cardholder data by limiting access to the minimum strictly necessary. By safeguarding stored cardholder data and masking displayed account numbers, complying with PCI DSS protects consumers and increases customer loyalty, which limits the exposure of your business to fraud and customer disputes. An example of how you can limit the access to the minimum strictly necessary is by looking at the A.I.R. files which contain cardholder data. By setting your office profile credit card concealment to Y, your customers cardholder data will be hidden and protected from products of Amadeus and 3rd party providers that access A.I.R. files. Please check with your mid of back office, or billing specialist the need for full card details to be processed in A.I.R messages or files. All travel agencies should only request their customer s cardholder data for legitimate business reasons and provide access to this sensitive information on a need-to-know basis. Travel agents with appropriate authorisation rights to view cardholder data should set these rights in credit card display at the agent sign-in level. By setting your agent sign-in to N for credit card display and profile card display, credit card information will be masked in the PNR based on PCI DSS recommended settings for those travel agents that should not have the rights to see the credit card information within your agency. For this reason, Amadeus hereby notifies you that you must set your office profile and agent sign-in to the following PCI DSS recommended settings in order to comply with the PCI DSS: Control level Control Abbreviation PCI DSS Amadeus strongly recommends that you immediately set your office profile and agent sign-in to these PCI DSS recommended settings. If you decide not to set your office profile and agent sign-in to these PCI DSS recommended settings, please be aware that you assume the associated risks of exposing your customer s cardholder data, including possible fraud, misuse or data breaches. Page 18 of 30

19 Keeping your customers payment card information safe There are dedicated fields in the PNR and profile for you to enter payment card information and ensure that cardholder data stored in the PNR and profile is concealed by Amadeus. See dedicated previous section Implement secured remark handling. Amadeus strongly recommends that you immediately use these fields to store the payment card information of your customers and secure your business from fraud. More information is also available in the profile (CSX) & PNR user guides accessible in the AMADEUS e-support centre Identify, inventory all payment processes and systems in your agency and related businesses. 2 major category of payment processes and transactions should be identified: A- Card present transactions; where your customers have to enter their card into a payment terminal, you must not have access to the details of your customer card, including with selfservice terminal, kiosk types. If using the swipe type of readers, please replace them with a PIN code entry type of EMV payment terminal, or a secured/certified swipe POS where the customer will swipe himself his/her card. Again, you should not handle any physical payment card. If you have to test terminal or swipe devices, then please contact your POS or Kiosk provider. B- Card not present transactions; to be identified with performing a comprehensive inventory of all your e-commerce products and associated payment, profile pages and sales reports. For third party web sites, again, please check the security pages or data protection pages of those web sites. Ensure all your web sites and e-commerce payment pages are PCI DSS certified. If all payments are outsourced to payment service providers, again, ensure your PSPs are certified. Print any screen and report you may have access to, and check you NEVER print, or can print, any full credit card. Same applies to security codes, or card verification codes (CVV, CVC...), which can never be stored. Security code processing is not authorized after payment authorization. Page 19 of 30

20 Do you currently host, or have you hosted in the past, physical or virtual servers, with customer cards on? Please complete the SAQ D, where all PCI control must be reviewed, including a specific security test an ASV scan, insuring your public IPs are free of any vulnerabilities, preventing hackers to export cards from your web server or database. The effort and complexity of this questionnaire requires you to contact your IT department, or security consultants. About Approved Scanning Vendors: Ensure PCI DSS security rules are observed: A- What you can NEVER store or print, including in log files, any file system: Security code or CVV/CVV2/CVC2/CID various naming depending on card brand Magnetic swipe or track data PIN block, solely cardholder known data B- What you can securely store, but never print: Full card number, to include strong encryption If storing full card numbers (and this should be only a few, whatever format) then the SAQ D questionnaire must be completed, including 100% of PCI controls to be in place. You will need to request support from your IT department or a security consultant. Therefore, it is highly recommended to store card numbers for the bare minimum (i.e., strictly business needs), and outsource any cardholder data processing and storage. Page 20 of 30

21 Page 21 of 30

22 Build your own road map/action list towards compliance. If, following the review of the above paragraphs and the list of SAQ not in place requirements, you have identified actions or non-conformances, please list them and implement those actions, one after the other, including checks and associated evidences, such as a screen copy for card masking in place: (123456XXXXXX1234 or XXXXXXXXXXXX1234 formats) Once all remediation actions are in place and checked, then you can complete the: Attestation on Compliance, AOC. Depending on your status as a merchant or service provider (please contact IATA ), the relevant template is available on line: Select: reporting documents and forms Last step: submit your SAQ and AOC to your acquirer or card brand, however, they may require an ASV scan test, performed by approved security consultants. The Payment Card Industry Security Standards Council The PCI SSC provides a wide array of documentation on its website as well as a micro-site dedicated to small merchants. PCI Security Standards Council Site: PCI SSC Small Merchants Site: Qualified Security Assessors (QSAs) The PCI SSC manages a program for Qualified Security Assessors (QSAs) that qualifies security assessors as being properly trained in evaluating merchant compliance with PCI DSS requirements. QSAs are thoroughly educated on PCI DSS requirements, have solid experience regarding information security, and are regularly subject to a vigorous Quality Assurance program. A QSA can act as both a consultant and an auditor specifically focused on PCI DSS requirements. A list of validated QSAs are located on the PCI Council s website: Approved Scanning Vendors The PCI Council manages Approved Scanning Vendors (ASVs). ASVs are organizations that validate merchant and service provider adherence to certain PCI DSS requirements by performing vulnerability scans of their online environments. For those merchants using Internet technologies for their business processes in tandem with their payment card systems, use of an ASV is needed to help ensure that hackers are not taking advantage of open access through the Internet to any of the merchant s systems containing cardholder data. The PCI SSC has approved more than 130 ASVs; however, small merchants should check with their acquirer or processor for recommended ASVs. A list of currently validated ASVs is available on the PCI Council s website: Page 22 of 30

23 Support Documentation Amadeus 2017 PCI DSS certificate Page 23 of 30

24 Reference Publications Page 24 of 30

25 Browsers supporting TLS 1.2 Please note as from 31 March2018, Amadeus will not support lower than TLS 1.2 protocols. Browser TLS 1.2 Compatibility Notes Microsoft Edge Compatible by default Desktop and mobile versions Compatible by default Microsoft Internet Explorer (IE) Desktop and mobile IE version 11 Desktop IE versions 9 and 10 Desktop IE versions 8 and below Mozilla Firefox Firefox 27 and higher Firefox 23 to 26 Firefox 22 and below Google Chrome Google Chrome 38 and higher Google Chrome 22 to 37 Google Chrome 21 and below Compatible with the most recent and stable version. Compatible by default Capable when run in Windows 7 or newer, but not by default. Review the Web browsers section of Wikipedia article for detailed information. Windows Vista and older operating systems, such as Windows XP, are not compatible with TLS 1.2 encryption. Not compatible or stable with TLS 1.2 encryption. Compatible with the most recent, stable version, regardless of operating system Compatible by default Capable, but not by default. Not compatible with TLS 1.2 or higher encryption. Compatible with the most recent, stable version, regardless of operating system Compatible by default Capable when run in Windows XP SP3, Vista, or newer (desktop), OS X 10.6 (Snow Leopard) or newer (desktop), or Android 2.3 (Gingerbread) or newer (mobile) Not compatible with TLS 1.2 encryption. Google Android OS Browser Android 6.0 (Marshmellow) and higher Android 5.0 (Lollipop) and higher Compatible by default Compatible by default Android 4.4 (KitKat) to Android 4.3 (Jelly Bean) and below Apple Safari Desktop Safari versions 7 and higher for OS X 10.9 (Mavericks) and higher Desktop Safari versions 6 and below for OS X 10.8 (Mountain Lion) and below Mobile Safari versions 5 and higher for ios 5 and higher Mobile Safari for ios 4 and below Capable, but not by default. Not compatible with TLS 1.2 encryption. Compatible by default Not compatible with TLS 1.2 encryption. Compatible by default Not compatible with TLS 1.2 encryption. Page 25 of 30

26 Support MasterCard PCI support pages VISA Europe resource documentation IATA ACTA What is an QIR- Qualified Integrator and Reseller: For most agents, no cash desk registers, with payment application, self-running transactions, installed by a QIR are involved. On line Training from card brands This section should list any relevant training required. MasterCard security and training program Visa training resources Page 26 of 30

27 Services Should you require specific services, solution updates, please contact your Amadeus account manager of our local customer organization. Amadeus Contacts: If you have any questions, please contact us through the Amadeus helpdesk, your account manager, or your support point of contact in your Amadeus Commercial Organization. Online help: Amadeus e-support centre. Complete the SAQs and AOCs: Tips only SAQ_A page 3 Part 2f. Third-Party Service Providers Does your company use a Qualified Integrator & Reseller (QIR)? Does your company share cardholder data with any third-party service providers (for example, Qualified Integrator & Resellers (QIR), gateways, payment processors, payment service providers (PSP), web-hosting companies, airline booking agents, loyalty program agents, etc.)? Yes No Amadeus do not develop or install payment applications, therefore QIR is not applicable in Amadeus platform context. However, you may have Payment Service Providers and other hosting contacted facility to be reported. EMVs rented payment terminals, any stand-alone Point Of Sales_ payment terminal accepting cards to be mentioned. Page 27 of 30

28 Terms and conditions upon which this guide is supplied. The information and data contained in this guide (the Material ) has been compiled by Amadeus IT Group, S.A. and its affiliates and subsidiaries ( Amadeus ) from sources believed to be reliable but Amadeus makes no representation or warranty express or implied as to the accuracy or completeness of the Material. The Material is provided for the assistance of the reader in his own research or analysis but is not to be relied upon as authoritative or taken in substitution for the exercise of the reader s own skill and judgment. Amadeus accepts no liability whatsoever for any direct, indirect or consequential loss arising from any use of the Material or any information, data and graphs contained therein. In the event that Amadeus is held liable for any reason, such liability is limited to the fee paid (if any) by the reader for the Material. Unless specifically permitted by Amadeus in writing, the reader may not reproduce, distribute or publish the Material for any purpose, nor load it onto a computer in such a manner as to be available to persons other than the reader. Copyright in the Material and information, data and/or graphs provided herewith remain the sole property of Amadeus unless otherwise specified therein or thereon. The reader shall faithfully reproduce the copyright logo(s) which appear on the Material or, if omitted, shall add the following: Source: to all copies of the Material made in whole or in part and whether made in printed form or any other material. Page 28 of 30

29 Glossary Please refer to the PCI DSS document library, category supporting documents Please find below an extract only from this glossary, allowing you to go through initial compliance steps only, it is strongly advised to read: PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms v3.2 April PCI Security Standards Council, LLC. All Rights Reserved Acquirer Also referred to as merchant bank, acquiring bank, or acquiring financial institution. Entity, typically a financial institution, that processes payment card transactions for merchants and is defined by a payment brand as an acquirer. Acquirers are subject to payment brand rules and procedures regarding merchant compliance. See also Payment Processor. AOC Acronym for attestation of compliance. The AOC is a form for merchants and service providers to attest to the results of a PCI DSS assessment, as documented in the Self-Assessment Questionnaire or Report on Compliance. Cardholder Data At a minimum, cardholder data consists of the full PAN. Cardholder data may also appear in the form of the full PAN plus any of the following: cardholder name, expiration date and/or service code See Sensitive Authentication Data for additional data elements that may be transmitted or processed (but not stored) as part of a payment transaction. Card Verification Code or Value Also known as Card Validation Code or Value, or Card Security Code. Refers to either: (1) magnetic-stripe data, or (2) printed security features. (1) Data element on a card's magnetic stripe that uses secure cryptographic processes to protect data integrity on the stripe, and reveals any alteration or counterfeiting. Referred to as CAV, CVC, CVV, or CSC depending on payment card brand. The following list provides the terms for each card brand: CAV Card Authentication Value (JCB payment cards) PAN CVC Card Validation Code (MasterCard payment cards) CVV Card Verification Value (Visa and Discover payment cards) CSC Card Security Code (American Express) (2) For Discover, JCB, MasterCard, and Visa payment cards, the second type of card verification value or code is the rightmost three-digit value printed in the signature panel area on the back of the card. For American Express payment cards, the code is a four-digit un-embossed number printed above the PAN on the face of the payment cards. The code is uniquely associated with each individual piece of plastic and ties the PAN to the plastic. The following list provides the terms for each card brand: CID Card Identification Number (American Express and Discover payment cards) CAV2 Card Authentication Value 2 (JCB payment cards) PAN CVC2 Card Validation Code 2 (MasterCard payment cards) CVV2 Card Verification Value 2 (Visa payment cards) Merchant For the purposes of the PCI DSS, a merchant is defined as any entity that accepts payment cards bearing the logos of any of the five members of PCI SSC (American Express, Discover, JCB, MasterCard or Visa) as payment for goods and/or services. Note that a merchant that accepts payment cards as payment for goods and/or services can also be a service provider, if the services sold result in storing, processing, or transmitting cardholder data on behalf of other merchants or service providers. For example, an ISP is a merchant that accepts payment cards for monthly billing, but also is a service provider if it hosts merchants as customers. Page 29 of 30

30 Sensitive Authentication Data Security-related information (including but not limited to card validation codes/values, full track data (from the magnetic stripe or equivalent on a chip), PINs, and PIN blocks) used to authenticate cardholders and/or authorize payment card transactions. Secure Wipe Also called secure delete, a method of overwriting data residing on a hard disk drive or other digital media, rendering the data irretrievable. Track Data Also referred to as full track data or magnetic-stripe data. Data encoded in the magnetic stripe or chip used for authentication and/or authorization during payment transactions. Can be the magnetic-stripe image on a chip or the data on the track 1 and/or track 2 portion of the magnetic stripe. Truncation Method of rendering the full PAN unreadable by permanently removing a segment of PAN data. Truncation relates to protection of PAN when stored in files, databases, etc. See Masking for protection of PAN when displayed on screens, paper receipts, etc Page 30 of 30