GridPP Security Incident Handling Procedure

GridPP Security Incident Handling Procedure
EGI Security Incident Handling Procedure
Useful Contacts

GridPP Security Incident Handling Procedure

(updated 9th Sept 2011 - further updates soon )

This page defines GridPP security incident handling procedure. This procedure is based on The EGI SPG's incident response policy and EGI CSIRT Security incident handling procedure. This is also summarised on the EGI CSIRT Wiki EGI CSIRT Security incident reporting Wiki. All GridPP sites should follow the procedure specified on this page to report and handle any Grid-related security incidents.

This document is intended for Grid site security contacts and site administrators.

Please note: site security contacts and site administrators should also be familiar with and abide by your local incident response policy. This prodecure is aiming at complementing local security procedures.

Incident Handling Procedure

When a security incident affecting grid hosts is suspected, the following procedure MUST be followed:

1. Inform immediately your local site security team and GridPP security officer via

UKNGI-SECURITY at JISCMAIL.AC.UK

2. If no support at your site is available in the next hour or two, 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 the network cable connected to the host. Do NOT reboot or power off the host.

3. Assist your local security team and GridPP security officer to confirm and then announce the incident to all the sites via

GridPP-CSIRTS at JISCMAIL.ac.uk

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

4. If appropriate:

Report a downtime for the affected hosts on the GOCDB (https://goc.egi.eu/)
Send an EGI broadcast announcing the downtime for the affected hosts Use "Security operations in progress" as the reason with no additional detail both for the broadcast and the GOCDB. This can be done at: https://cic.gridops.org/index.php?section=roc&page=broadcast **needs updating**

Step 4 MUST be completed within one working day after the suspected incident has been discovered.

5. Perform appropriate forensics and take necessary corrective actions:

Identify and kill suspicious process(es) as appropriate, but aim at preserving the information they could have generated, if possible both in memory and on disc;
If it is suspected that some grid credentials have been abused or compromised, you MUST ensure the relevant accounts have been suspended
If it is suspected that some grid credentials have been abused, you MUST ensure that the relevant VO manager(s) have been informed. VO contacts are available from: https://cic.gridops.org/index.php?section=vo **needs updating**
If it is suspected that some grid credentials have been compromised, you MUST ensure that the relevant CA has been informed. CA contacts are available from: https://www.eugridpma.org/showca
If needed, seek for help from your local security team or from GridPP security officer
UKNGI-SECURITY at JISCMAIL.AC.UK

or from EGI CSIRT via

abuse at egi.eu
If relevant, additional reports containing suspicious patterns, IP addresses, files or evidence that may be of use to other Grid participants SHOULD be sent to:
GridPP-CSIRTS at JISCMAIL.ac.uk

and

site-security-contacts at mailman.egi.eu
Never send potentially sensitive information (ex: IP addresses, usernames) WITHOUT clearance from your local security team and/or GridPP security officer.

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.
As part of the investigations, sites MUST be able to provide the relevant logging information (IP addresses, timestamps, identities involved), produced by local services, concerning the source of any suspicious successful connection, as follows:

6 months prior to the discovery of the incident for successful SSH connections against grid services, and for the originating submission host for grid jobs
3 months prior to the discovery of the incident for all other grid-related services

For example, should an incident be detected and reported on 1st September, it is expected that sites can produce the relevant logging information for suspicious SSH connections from 1st of March.

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

Host(s) affected (ex: compromised hosts, hosts running suspicious user code)
Host(s) used as a local entry point to the site (ex: UI or WMS IP address)
Remote IP address(es) of the attacker
Evidence of the compromise, including timestamps (ex: suspicious files or log entry)
What was lost, details of the attack (ex: compromised credentials, (root) compromised host)
If available and relevant, the list of other sites possibly affected
If available and relevant, possible vulnerabilities exploited by the attacker
The actions taken to resolve the incident

Throughout step 5, requests from GridPP security officer and/or the Operational Security Coordination Team MUST be followed-up within 4 hours.

6. Coordinate with your local security team and GridPP security officer to send an incident closure report within 1 month following the incident, to all GridPP sites via

GridPP-CSIRTS at JISCMAIL.ac.uk

and to all EGI sites via

site-security-contacts at mailman.egi.eu

including lessons learnt and resolution.

7. Restore the service, and if needed, send an EGI broadcast, update the GOCDB, service documentation and procedures to prevent recurrence as necessary.

When contacted, all recipients of GridPP-CSIRTs and EGI-security-contacts are expected to take appropriate action, including processing the information available (ex:suspicious log entries, DN, or IP addresses), checking locally for signs of compromise, and reporting suspicious findings.

EGI Security Incident Handling Procedure

This procedure (updated 1st October 2010) is provided by the EGI Computer Security Incident Response Team (CSIRT) and is aimed at minimising the impact of security incidents, by encouraging post-mortem analysis and promoting cooperation between the sites.

Useful Contacts

UKNGI security team may be contacted by e-mail to UKNGI-SECURITY at JISCMAIL.AC.UK

Last modified Fri 16 September 2011 . View page history

Switch to HTTPS . Website Help . Print View . Built with GridSite 1.4.3

Sections

Security

GridPP Security Incident Handling Procedure