From EGIWiki
Jump to: navigation, search
Main operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security

Documentation menu: Home Manuals Procedures Training Other Contact For: VO managers Administrators


Title EGI CSIRT Security Incident Handling Procedure
Document link
Last modified v5, 25.02.2016
Policy Group Acronym EGI-CSIRT
Policy Group Name EGI-CSIRT
Contact Group
Document Status Approved
Approved Date 31.03.2016
Procedure Statement This procedure is aimed at minimising the impact of security incidents by encouraging post-mortem analysis and promoting cooperation between Resource Centers.
Owner Owner of procedure


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.

Contact points

Entities involved in the procedure

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.

Step Action Deadline
1 Inform 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
2 In 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
3 Together with your local security team and the EGI CSIRT decide if it is an incident that requires further investigation or action.
4 If applicable, announce downtime for the affected services in accordance with the EGI Operational Procedures Within 1 day of isolation
5 Perform appropriate analysis and take necessary corrective actions, see Incident Analysis Guideline Within 4 working hours of any EGI CSIRT request
6 Coordinate 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
7 Restore 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:

Revision History

Version Authors Date Comments
1 Mingchao Ma/STFC 28/06/2011 First Draft based on MS405, a few minor update, added appendix C and appendix D
2 Mingchao Ma/STFC 28/07/2011 Addressed comments from Dorine
3 Mingchao Ma/STFC 11/10/2011 Corrected a reference in the incident response check list (appendix D)
4 Sven Gabriel/Nikhef/FOM 26/05/2015 Adjustments for IR in EGI Cloud environments
5 Vincent Brillault/CERN 25/02/2016 Adapted to the wiki format, several adjustment
Personal tools