Payment Card Industry Data Security Standard (PCI-DSS)

Transcription

1 Payment Card Industry Data Security Standard (PCI-DSS) Incident Management Standard Version March 2018 University of Leeds 2018 The intellectual property contained within this publication is the property of the University of Leeds. This publication (including its text and illustrations) is protected by copyright. Any unauthorised projection, editing, copying, reselling, rental or distribution of the whole or part of this publication in whatever form (including electronic and magnetic forms) is prohibited. [Any breach of this prohibition may render you liable to both civil proceedings and criminal penalties].

2 Document Ownership and Management Standard Authors Kevin Darley and Dave Neild (PCI-DSS Internal Security Assessors [ISA]) Standard Owner PCI-DSS Working Group The audience of this document should be aware that a physical copy may not be the latest version. Those to whom this Standard applies are responsible for familiarising themselves periodically with the latest version and for complying with these requirements at all times. Version Number Date Circulation Changes September First formal issue, signed off by Design Authority on 25 th August August Update of referenced personnel and addition of new detail following exercise at MasterCard Mock Retail Cyber Hack March Minor updates to job titles and addresses March PCI-DSS stakeholders and staff Annual review and update PCI-DSS Incident Management Standard Version Page 2 of 21

3 For information in alternative formats (for example, in Braille or large print), please or call on telephone number PCI-DSS Incident Management Standard Version Page 3 of 21

4 Introduction This document is one of a number of documents which support the University s Payment Card Industry Data Security Standard (PCI-DSS) Security Policy ( It delivers the mandatory criteria for University staff who have an incident management role within the University s cardholder data environment (CDE). This document will be reviewed annually, as a minimum, and updated as required in accordance with the Standard. It is the personal responsibility of all those to whom this document applies to ascertain and meet the precise requirements of the Standard in respect of all requirements which are applicable to them. General Principles The University s approach to PCI-DSS Incident Management comprises of six steps: 1. Preparation; 2. Monitoring and Detection; 3. Initial Investigation & Control; 4. Reporting & Formal Investigation; 5. Recovery; and, 6. Post Incident Review and Actions. The Six PCI-DSS Incident Management Steps 1 Preparation 1.1 Incident Investigations Team The University will maintain a PCI-DSS Incident Investigations Team. The team will be familiar with the University s CDE, its components and network, and will be capable of being convened at short notice. Incident Investigations will be led by a member of the IT Assurance Team who will act as the Incident Controller. PCI-DSS Incident Management Standard Version Page 4 of 21

5 A complete membership of the PCI-DSS Incident Investigations Team can be found at Annex A, although only those required or available at the time of an incident will be convened for any given event. 1.2 Documentation The IT Assurance Team are responsible for maintaining up to date documentation and evidence of PCI-DSS compliance. This documentation can be found in two places: The PCI-DSS SharePoint site; and The Assurance Team PCI-DSS Compliance network folder 1.3 Staff Associated with the CDE Management of staff with responsibility for the maintenance of CDE components or the performance of operations are to maintain a current list of those personnel in accordance with the PCI-DSS Information Security Policy. 1.4 System Security Logs and FIM Alerts System Security Logs for e-commerce servers are available within the University logging service and are retained for one year. FIM alerts will be received in real time and must be investigated on receipt. Any alerts which are generated out of hours must be investigated at the first opportunity. All such alerts are to be raised as Critical Incident with ServiceNow. 1.5 Infrastructure Build Standards and Firewall Rules The IT Server Teams will have Infrastructure Build Standards for e-commerce servers and the IT Network Team will have current and historical firewall rules. 1.6 Network Diagrams, Card Data Flow Diagrams Firewall Rules and Logs The above resources will be used by the PCI-DSS Incident Investigations Team to: Provide a quick and clear picture of the CDE to external incident handlers, external forensic investigators, and law enforcement personnel; Determine the points of entry to the CDE; Establish how far the attacker may have been able to infiltrate; PCI-DSS Incident Management Standard Version Page 5 of 21

6 Determine which assets may have been exposed or compromised; and Establish if cardholder data was protected during transmission. Any non-approved / non-business-justified firewall rules and ACLs must be easily identified by matching the rules to previous configuration backups. This will help to establish whether Poor firewall and router configuration could be attributed to the compromise; Firewall and/or router configuration changes followed proper change management procedures; and, The attacker was able to compromise firewalls / routers. 1.7 CCTV Recordings If available, CCTV recordings will be examined by the PCI-DSS Incident Investigations Team to determine whether physical security has been a factor as this may assist in deciding the direction of the forensic investigation. 2 Detection 2.1 Reporting Security breaches will either be reported to the University by one of the card brands, via the University s acquirer, discovered internally, such as through event logging alerts or system administration or through customer experience. In the event of an e-commerce server being compromised, the University may receive details of the incident from the organisation hosting that service. 3 Initial Investigation & Control 3.1 Investigation Initiation Appropriate members of the PCI-DSS Incident Investigations Team will be convened by the Incident Controller at the first opportunity following report of a security incident or suspected security incident concerning any CDE component. An initial assessment will be carried out and standards and diagrams will be collated relevant to the CDE components which are associated with the incident. PCI-DSS Incident Management Standard Version Page 6 of 21

7 As part of the assessment it will be decided whether to place some or all members of staff associated with the CDE on high alert to look out for other possible signs of tampering or security breach. Applicable CDE components will also be subject to increased monitoring of logs or configuration inspection based upon the assessment of the incident. Unless the suspected breach has been reported by the University s Acquirer, and depending on the type of incident, the PCI- DSS Incident Investigations Team will decide whether it is appropriate to report the matter to the University s Acquirer. Contact details can be found in Annex B. Depending on the nature of the actual or suspected compromise, and, if appropriate with guidance from the University s Acquirer, a decision will be made by the Incident Controller as to whether an initial forensic investigation will be undertaken by members of the University s PCI-DSS Incident Investigations Team. Where an internal forensics investigation is carried out full details of all actions taken will be maintained and original evidence will be preserved so as to be available to a specialized Payment Forensics Investigation (PFI) team and the National Crime Agency (NCA) should that prove to be necessary. 3.2 Network Connected Devices Subject to instruction from the University s Acquirer, where appropriate, any network connected device which is believed to be compromised, or associated with a compromise, will be disconnected from the network at the earliest opportunity. The device must not be altered or accessed using either privileged or non-privileged accounts and must not be switched off or powered down until a full assessment has been carried out, and if applicable, specialist advice has been obtained. 3.3 Preservation of Evidence & Action Logs All logs and electronic evidence must be preserved and a full record must be maintained of all actions taken. 3.4 Global Payments PEDS and VeriFone PEDs Subject to instruction from the University s Acquirer, in the event of a PED being identified as having been tampered with, or suspected of being tampered with, the terminal must be immediately unplugged from its telephone socket or till, but neither the terminal nor the external PIN pad must be switched off. All lead connections between the terminal and external PIN pad must remain connected. PCI-DSS Incident Management Standard Version Page 7 of 21

8 A label is to be attached to each PED which is under investigation stating that it is out of use and must not be used or turned off. Each suspected compromised PED is to be safeguarded until such time as it can be examined by appropriately qualified investigator. Any available CCTV recordings relating to the building(s) or area(s) in which the PED(s) were located must to be preserved as potential evidence, but no further action is to be taken in respect of the incident investigation other than as directed by the University s Acquirer. A record must be maintained of all actions taken. 3.5 Action Logs Action logs will be maintained by the Incident Controller for each incident investigated. These will comprise: A list of CDE component(s) involved or suspected of being involved; A description of the type of incident; The date and time of initial report; A description of the connectivity of the associated component(s) within CDE / payment card data transaction mechanism; and, Notes from the initial and follow-up conversations with the University s Acquirer and any other external parties. It is the responsibility of each member of the PCI-DSS Incident Investigations Team to update the Incident Controller with the following details as they happen or at the earliest opportunity thereafter: Date and time of each action taken; Full details of each action taken; Who took the action and who else was present; and, Any other comments. All incident records will be retained by the PCI-DSS Incident Investigations Team for a period of three years. PCI-DSS Incident Management Standard Version Page 8 of 21

9 4 Reporting & Formal Investigation 4.1 Internal Reporting As soon as the PCI-DSS Incident Investigations Team has sufficient evidence of a security breach, or suspected security breach, the details must be reported to the: Secretary to the University or the Deputy Secretary in his absence; University Chief Financial Officer or the Director of Finance in their absence; University Legal Advisor; and University IT Director or a member of the IT Executive Leadership Team in their absence; The Secretary to the University, or in his absence, the Deputy Secretary, will convene a Crisis Management Team to direct the University s response to the breach or suspected breach in terms of: Media handling (see 4.8); Further reporting, for example to the police (see 4.5) and the Information Commissioners Office (ICO) through liaison with and in conjunction with any such action taken by Global Payments, where applicable; and, Setting up a customer helpline, if required. 4.2 External & Additional Internal Reporting In addition to informing the University Treasury Team and the University s Acquirer in the event of any actual or suspected breach the external reporting lines varies subject to the specific component involved, as follows: Global Payments PEDs: o None Till & PED: o Catering Systems Manager; o VeriFone; and, PCI-DSS Incident Management Standard Version Page 9 of 21

10 o MCR Systems Limited. E-commerce Server: o Car Park: Respective Payment Service Provider. o Facilities Management, o Respective Payment Service: Creditcall KeyIVR Sage Pay. Reporting details for third parties can be found at Annex B. 4.3 Onward Reporting to Card Brands The University will be guided by its Acquirer in terms of onward reporting of actual and suspected security breaches involving payment card data to the card brands. In the first instance, the Acquirer may wish to make the onward reports. In the event of a breach or suspected breach being discovered out of office hours when the University s Acquirer is unable to assist, the Incident Controller in consultation with the University s Crisis Management Team will decide whether to report the matter directly to Visa Europe 1 and MasterCard 2 depending on the seriousness or scale of the incident. Reporting details for Visa Europe and MasterCard can be found at Annex B and the timeline for reporting activities can be found at Annex C. 1 Visa Europe requires to be notified of a loss of payment card data as soon as the loss is confirmed. 2 MasterCard require to be informed of a breach with 24 hours of the event being discovered. PCI-DSS Incident Management Standard Version Page 10 of 21

11 4.4 Use of Specialised Incident Response Teams PFI Companies Subject to the scale and nature of a security breach, and the advice received from the University s Acquirer or the card brands, it may be appropriate or necessary to engage the services of a specialized PFI Team. A list of companies which are registered as PFIs with the PCI SSC and qualified to perform such investigations can be found on the PCI SSC website at A list of PFIs that serve the UK can also be found at Annex B. 4.5 Reporting to the Police National Crime Agency The NCA is the police body which is responsible for the investigation of payment card data breach crime within the UK and they must be notified within 24 hours of such a breach coming to light. They will work with the appointed PFI Company who will supply them with a forensically acquired image of the respective compromised system components which are associated with the breach. NCA reporting details can be found at Annex B. 4.6 Reporting to the Police Action Fraud Action Fraud is the national police agency for reporting fraud and they must be notified of all payment card data breaches. However, the first line of police reporting is the NCA as described above. When reporting payment card data breaches to Action Fraud they must be informed that the NCA have already been notified. 4.7 Reporting to the Financial Fraud Action UK (FFA UK) The FFA is a trading association of the banks which working with the police handles breach disclosure activities on the banks behalf in order to help to protect organisations and members of the public. They work closely with the National Fraud Intelligence Unit (NFIU) and act as a conduit between the banks customers and the cardholders. They will work with the Press Office to manage exposure-related communications to ensure that fraudsters cannot capitalize on communications. The FFA is an official investigating body as defined with the Data Protection Act 1998 and as such can be handed personal data in accordance with Section 29 (3) of the Act. In a card data breach situation they will require additional details to be disclosed to them via a secure portal (details of which they will provide) such as bank sort codes and bank account numbers so that they can inform the banks of any other data fields that may have been compromised at the same time. The FFA will provide a destruction certificate confirming the secure destruction of University data at the end of the investigation. Contact details for the FFA UK Press Office can be found at Annex B. PCI-DSS Incident Management Standard Version Page 11 of 21

12 4.8 University Press Office Activities Members of the he University Press Office will form part of the University Crisis Management Team as described at 4.1 above. They will work with FFA UK to manage communications and press releases and to counter any incident leakage disclosures that appear on social networking sites. 4.9 Further Reporting to the Payment card Brands Payment card brands will demand to know how many cards of their respective brands may have been compromised. This information must be provided within ten business days. The payment card brands will also need to know at the earliest stage: How the breach occurred; The status of the University s PCI DSS compliance at the time of the breach; That the eradication and recovery efforts have been effective; and, That the University is no longer compromised. This report is extremely important as it will be used to establish the University s future level of PCI DSS compliance and will determine whether the University is liable and to what extent. It is highly likely that the payment card brands will require an additional PCI-DSS Assessment in order to identify specific areas of non-compliance and for the University to develop a detailed remediation plan. 5 Recovery 5.1 Direction Recovery operations will be directed according to the conclusions of the PFI investigation and/or on the advice of the University s Acquirer, based upon the full circumstances of the breach, if a breach involving the University s CDE was proven to have taken place. Recovery operations will be also be influenced by the defined status of the University s PCI-DSS compliance at the time the incident took place. PCI-DSS Incident Management Standard Version Page 12 of 21

13 5.2 Verification Prior to resuming payment card operations using CDE components associated with a breach (on conclusion of the PFI investigation, if one has taken place), the re-build, configuration, software installation, network connectivity, etc. of the CDE, as appropriate, will be independently validated by a PCI-DSS QSA. An up to date list of PCI-DSS certified PCI-DSS QSAs can be found on the PCI SSC website at 6 Post Incident Review and Actions 6.1 Verification After the security breach has been handled, the University will review its security strategy, incident response plan, and monitoring processes as PCI-DSS requires the development and modification of processes to evolve the incident response plan according to the lessons learned from an incident. A thorough analysis of how the incident was detected, notified, handled and contained will be performed. The incident plan will be updated, as appropriate, in order to improve monitoring alerts analysis, response times, and to optimize the incident response procedures. 6.2 Counter-Compromise Subject to the nature of a successful breach it may be assumed that an attacker has been able to obtain a vast knowledge of the University s IT infrastructure, such as: Details of operating systems in use, naming conventions, applications and services running for most of the servers; Details of student, or employees, user-ids and passwords, accounts, and / or other personal information; and, Application source code. As part of the post incident review the PCI-DSS Incident Investigations Team will consider the technical and procedural options available to them to prevent a further attack. PCI-DSS Incident Management Standard Version Page 13 of 21

14 Annex A - PCI-DSS Incident Investigations Team The following individuals are members of the PCI-DSS Incident Investigations Team: Name Contact Role Kevin Darley, IT Security Co-ordinator T Incident Controller M E. k.j.darley@leeds.ac.uk Dave Neild, Cybersecurity Analyst T Deputy Incident Controller E. d.neild@leeds.ac.uk Clive Smith, Treasury Manager T Assistance E. c.r.smith@adm.leeds.ac.uk Abi Shearsmith, Head of Student Finance T Assistance & Support E. a.shearsmith@adm.leeds.ac.uk Shelley Fox, Catering Systems Manager T Assistance E. s.k.fox@leeds.ac.uk Majid Khan, Support Services Manager T Assistance E. m.m.khan@leeds.ac.uk Karl Grocock, Head of Infrastructure T Resource Allocation E. k.grocock@leeds.ac.uk Andrew Steel, Network Services Manager T Resource Allocation E. a.j.steel@leeds.ac.uk Mark Madeley, Windows Server Manager T Resource Allocation E. m.a.madeley@leeds.ac.uk Martin Lomas, Storage and Unix T E. m.j.lomas@leeds.ac.uk Resource Allocation PCI-DSS Incident Management Standard Version Page 14 of 21

15 Annex B Reporting Information Global Payments Incident Reporting Tara Marwaha Corporate Relationship Manager Global Payments, 51 DeMontfort Street, Leicester, LE1 7BB Mobile: tara.marawaha@globalpay.com Service Desk Number: Grahame Vincent (Covers Tara for planned absences) Tel: grahame.vincent@globalpay.com Alastair Shields (Leicester office) Tel: alastair.shields@globalpay.com PCI-DSS Incident Management Standard Version Page 15 of 21

16 Payment Service Providers & Service Providers WPM Education 26 Victoria Way, Burgess Hill, West Sussex, RH15 9NF Tel: MCR Systems Tel: Technical Support Manager: Operations Director: Verifone UK Ltd Symphony House, 7 Cowley Business Park, High Street, Cowley, Uxbridge, UB8 2AD Tel: Creditcall Limited Merchants House North,Wapping Road, Bristol, BS1 4RW KeyIVR Dianne Smith, Sales Manager, Head of Channel Partner Relationships PCI-DSS Incident Management Standard Version Page 16 of 21

17 Supoport Telephone Support Sage Pay Customer Support Centre, North Park, Newcastle-Upon-Tyne, NE13 9AA Card Brands Visa Europe Visa Europe Data Compromise Team Manager Telephone: MasterCard For reporting requirements to MasterCard please see PCI-DSS Incident Management Standard Version Page 17 of 21

18 Payment Forensic Investigation Companies Foregenix Andrew Bontoft T: SRM Brian Fenwick T: Mandiant Christopher Glyer T: Mnemonic Kare Presttun T: Pentest Partners Consulting LLP Benn Morris T: SecurityMetrics, Inc. Ian Eyles (Europe) T: Trustwave Holdings, Inc. PCI-DSS Incident Management Standard Version Page 18 of 21

19 Mike Wilkinson T: Verizon/CyberTrust Laurance Dine T: National Crime Agency 24 hours reporting. Telephone and ask for National Cybercrime Unit Duty Officer Financial Fraud Action UK All FFA UK media enquiries are to be directed to the Press Office Office hours telephone Out-of-hours telephone press@ukcards-ffauk.org.uk PCI-DSS Incident Management Standard Version Page 19 of 21

20 Annex C Card Brand Reporting Timelines PCI-DSS Incident Management Standard Version Page 20 of 21

21 PCI-DSS Incident Management Standard Version Page 21 of 21