Report Security Incident

From GridPP Wiki
Jump to: navigation, search

Security Incident in GridPP / UK NGI

Any security incident which occurs in GridPP / UK NGI is handled according to the approved EGI Security Incident Response Procedure written by the EGI CSIRT team.

This wiki page is effectively a copy of the site responsibilities defined in this procedure with a little UK specific information added.

This applies to all GridPP / UK NGI sites.

1. Report the Security Incident

If you detect, or suspect you may have detected, a security incident at your site then please report it IMMEDIATELY. It is better to have a false report, and find there is no problem, than for an incident to go unreported and spread across the Grid.

Report by e-mail to:

  • ukngi-security at cern.ch and
  • abuse at egi.eu and
  • Your local site security team

Ensure you at least give the following information in your initial report:

  • Name
  • E-mail address
  • Telephone number and/or mobile phone number
  • Details of the incident, as far as possible

This step MUST be completed within 4 hours after the suspected incident has been discovered.

Details of the incident may be reported using the template

Sites must report an incident or possible incident to abuse at egi.eu, at least within 4 hours after the suspected incident has been discovered. The people behind the UKNGI-SECURITY at cern.ch are the UK security team, and behind the abuse at egi.eu are the EGI CSIRT Incident response task force and will do what they can to help you. If you do not know what to do, DON'T PANIC, just send an e-mail and they will help you.

Please print the EGI Security Incident Response Procedure, you will find it useful. It contains information on how incidents are handled from both the site view and the EGI CSIRT view. It provides the information you will need in addition to this page.

2. Contain the incident

Do NOT reboot or power off the host. If no support is available in the next 2 hours, whenever feasible and, if admitted by your local security procedure and if you are sufficiently familiar with the host/service to take responsibility for this action, try to contain the incident. For instance by unplugging all connections (network, storage, etc) to the host.

Please note down carefully what actions you take with a timestamp; that would be very important for later analysis as well as if the incident ends up in a legal case.

This step SHOULD be completed as soon as possible, and MUST be completed within one working day after the suspected incident has been discovered.

3. Confirm the incident

Confirm the incident, with assistance from your local security team, the UKNGI security team, and the EGI CSIRT.

4. Announce downtime as appropriate

If applicable, announce downtime for the affected hosts in accordance with the EGI operational procedures, with “Security operations in progress” as the reason. If applicable, this step MUST be completed within one working day after the suspected incident has been discovered.

This may be carried out via the Grid Operations Centre Database, GOCDB

5. Analyse Incident

Analyse the Incident with the help of EGI CSIRT and your local Site Security Team.

Perform appropriate analysis and take necessary corrective actions as per Appendix A of the EGI Security Incident Response Procedure. Logging information such as IP addresses, timestamps and identities involved etc., concerning the source of any suspicious successful connection, must meet the minimal requirements specified in Appendix A of the EGI Security Incident Response Procedure. The objective is to understand the source and the cause of the incident, the affected credentials and services, and the possible implications for the infrastructure. Throughout this step, requests from the EGI CSIRT MUST be followed-up within 4 hours.

6. Provide Report

Coordinate with your local security team and the EGI CSIRT to send an incident closure report within 1 month following the incident to all the sites via site-security-contacts at mailman.egi.eu, including lessons learnt and resolution. This report should be labelled AMBER or higher, according to the Traffic Light Protocol at EGI CSIRT Traffic Light Protocol

7. Restore Service

Restore the service and, if needed, update the service documentation and procedures to prevent recurrence as necessary.

More information


EGI CSIRT incident reporting wiki contains further templates and information.

EGI Security Incident Response Procedure written by the EGI CSIRT team.

Report Software Vulnerability describes how to report a software vulnerability

GridPP Wiki Security Information


This page is a Key Document, and is the responsibility of Ian Neilson. It was last reviewed on 2017-02-14 when it was considered to be 100% complete. It was last judged to be accurate on 2017-02-14.