Document control

Procedure status

Approval status

Approved version and date31.03.2016
StatementThis procedure is aimed at minimising the impact of security incidents by encouraging post-mortem analysis and promoting cooperation between Resource Centres.
Next procedure reviewtogether with process review

Procedure reviews

The following table is updated after every review of this procedure.

DateReview bySummary of resultsFollow-up actions / Comments


Import from EGI wiki

Table of contents


This procedure is aimed at minimising the impact of security incidents by encouraging post-mortem analysis and promoting cooperation between Resource Centers.
It is based on the Security Incident Response Policy.

This incident response procedure is aiming at complementing local security procedures. Unless specified otherwise in separate service level agreements, all times in this document refer to normal local working hours.

This document is intended for Resource Center security contacts and administrators and is primarily aimed at reporting, investigating and resolving security incidents.

Previous approved version of the procedure - approved, July 2010 (MS405)  


Please refer to the EGI Glossary for the definitions of the terms used in this procedure.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", “MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Entities involved in the procedure

Contact points


A Security incident has been identified.

Resource Center Responsibilities

The following table describes the actions to be taken when an incident potentially affecting EGI users, data, services, infrastructure is suspected. Administrators are recommended to take note of every action (with timestamp) they take, for later analysis or legal cases.

1Inform your local security team, your NGI Security Officer and the EGI CSIRT via You are encouraged to use the recommended templates.Within 4 hours of discovery
2In consultation with your local security team and the EGI CSIRT, act to isolate the compromised systems and contain the incident whilst preserving forensic data. Take a snapshot of affected VMs. Isolate at the network level if possible. Do NOT reboot or power off hosts. Do NOT destroy VMs. Physically disconnect systems from the network ONLY where other options are not available.Within 1 day of discovery
3Together with your local security team and the EGI CSIRT decide if it is an incident that requires further investigation or action.
4If applicable, announce downtime for the affected services in accordance with the EGI Operational ProceduresWithin 1 day of isolation
5Perform appropriate analysis and take necessary corrective actions, see Incident Analysis GuidelineWithin 4 working hours of any EGI CSIRT request
6Coordinate with your local security team and the EGI CSIRT to send an incident closure report to the EGI CSIRT via, including lessons learnt and resolution. This report should be labelled AMBER or RED, according to the Traffic Light Protocol.Within 1 month of incident resolution
7Restore the service and, if needed, update the service documentation and procedures to prevent recurrence as necessary.

EGI-CSIRT Responsibilities

EGI-CSIRT Security Officer on Duty

The EGI-CSIRT Security Officer on Duty tasks are:

EGI-CSIRT Security Incident Coordinator

In addition, the EGI CSIRT appoints a security incident coordinator for each incident, responsible for:

Incident Analysis Guideline

As part of the security incident resolution process, RCs are expected to produce the following information:

RCs are also expected to:

RCs are also recommended to:

As part of the investigations, RCs MUST be able to provide the relevant logging information produced by local services. Logging information such as IP addresses, timestamps and identities involved etc., concerning the source of any suspicious successful connection, must meet the following minimal requirements, if possible according to local laws: