Document control

AreaISM
Procedure status

FINALISED

OwnerComputing Security Incident Response Team (CSIRT)
Approvers
Approval status

APPROVED

Approved version and date

v.2  

Statement

Work instruction to follow Security Vulnerability handling RT tickets

Next procedure reviewtogether with process review
Dissemination Level

TLP:WHITE

Procedure reviews

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

DateReview bySummary of resultsFollow-up actions / Comments

 

Baptiste Grenier 

Import from Mediawiki




Table of contents

Overview

The purpose of this page is to provide instructions to the EGI SDIS team members part of the operations-vulnerability-handling SSO group on how to handle Security Vulnerability identified by CSIRT IRTF.

The main idea behind this handling is to make sure that sites are aware of the issue and working on it. Usually, sites that are showing good intention are not penalised even if the progress is not strictly within the procedure: SEC03 EGI-CSIRT Critical Vulnerability Handling.

Definitions

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

  • CSIRT IRTF
  • EGI SDIS team (former EGI Operations team)

Triggers

Steps

Step# ResponsibleActionPrerequisites, if any
1
IRTFis responsible for:
  • looking at Pakiti and Security dashboard.
  • looking for false positives
  • creating new RT tickets in the Vulnerability Handling queue with a due date of 3 days.

2aSDIS
Dear security contact for XX-XX-XXX,

This is a friendly reminder that we didn't receive any update about this ticket!

Thanks,
  • 0.5 working day before the due date, EGI SDIS sends a last reminder, potentially including operational contacts in addition to security contacts. In such case, in case of an answer, SDIS verifies that the security contact is still valid
  • After the due date, suspend the site
There is no acknowledgement or answer from the site

bSDIS
  • 1 working day before the due date, EGI SDIS checks Pakiti:
    • If there is no change, ask for progress/for an update, insisting
    • If the vulnerability disappeared from Pakiti, ask for a confirmation that the vulnerability was fixed and that it's not simply the affected node not being reached by the Nagios probe (which usually reach different nodes every day)
There is an acknowledgement, but no solution announced
3aSDIS
  • If it's a mitigation:
    • If different from any mentioned in the advisory escalate to IRTF
    • If it's the same, EGI SDIS waits for up to a day and checks the security dashboard
  • If it's a simple package/kernel update, EGI SDIS checks Pakiti:
    • If there is a report for the affected node(s) without any vulnerability, thanks and closes the ticket
    • If the last report for the affected node(s) is still from before the update, ask to run the Pakiti client by following EGI_CSIRT:Pakiti_client.
      • If the vulnerability then disappear from Pakiti, with or without any other message, closes the ticket
A solution is said to be deployed

bSDISsuspends the site and closes the ticket.After the due date, if there is still no answer/solution announced