Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "WI07 Security Vulnerability handling"

From EGIWiki
Jump to navigation Jump to search
(First import)
 
(Start formatting things a bit more cleanly)
Line 1: Line 1:
The purpose of this page is to provide instructions to the EGI Operations team members on how Security Issues handling should be done.
{{Template:Op menubar}} {{Template:GO menubar}} {{TOC_right}}


Previously this was managed by the IRTF team.
= Work instruction to handle new Security Vulnerability handling GGUS tickets  =


* For the time being, IRTF will still be responsible for looking at Pakiti/the security dashboard, look for false positives and create new tickets with a due
The purpose of this page is to provide instructions to the EGI Operations team members on how to handle Security Vulnerability identified by IRTF.
date of 3 days.


* If there is no acknowledgement or answer:
The main idea behind this handling is to make sure that sites are aware of the issue and working on it.
** 1 working day before the due date, send another reminder via RT
Usualy sites that are showing good intention are not penalized even if the progress is not within the procedure: SEC03 put deadlines on site to do few things but does not put a deadline on the CSIRT to enforce them, allowing to adapt the answer.
** .5 working day before the due date, send a last reminder, potentially including operational contacts in addition of security contacts. In such case, in case of answer, make sure to verify that the security contact is still valid
** After the due date, suspend the site


* If there is an acknowledgement, but no solution announced:
{| align="center" cellspacing="0" cellpadding="5" border="1"
** 1 working day before the due date, check Pakiti:
|-
*** If there is no change, ask for progress/for an update, insisting
! Step
*** 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
! Action
|-
| 1
| IRTF is responsible for:
* looking at Pakiti/the security dashboard
* looking for false positives
* creating new tickets with a due date of 3 days.
|-
| 2a
| If there is no acknowledgement or answer from the site:
* 1 working day before the due date, send another reminder via RT
* .5 working day before the due date, send a last reminder, potentially including operational contacts in addition of security contacts. In such case, in case of an answer, make sure to verify that the security contact is still valid
* After the due date, suspend the site
|-
| 2b
| If there is an acknowledgement, but no solution announced:
* 1 working day before the due date, check 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)
being reached by the Nagios probe (which usually reach different nodes every day)
 
|-
* After the due date, if there is still no answer/solution announced, suspend  the site
| 3
 
| After the due date, if there is still no answer/solution announced, suspend  the site
* If a solution is said to be deployed:
|-
** If it's a mitigation:
| 4
*** If different from any mentioned in the advisory escalate to IRTF
| If a solution is said to be deployed:
*** If it's the same, wait for up to a day and check the security dashboard
* If it's a mitigation:
** If it's a simple package/kernel update, check pakiti:
** If different from any mentioned in the advisory escalate to IRTF
*** If there is a report for the affected node(s) without any vulnerability, thanks and close the ticket
** If it's the same, wait for up to a day and check the security dashboard
*** If the last report for the affect node(s) is still from before the update, ask to run the pakiti client by following https://wiki.egi.eu/wiki/EGI_CSIRT:Pakiti_client.
* If it's a simple package/kernel update, check pakiti:
**** If the vulnerability then disappear from Pakiti, with or without any
** If there is a report for the affected node(s) without any vulnerability, thanks and close the ticket
other message, close the ticket
** If the last report for the affect node(s) is still from before the update, ask to run the pakiti client by following https://wiki.egi.eu/wiki/EGI_CSIRT:Pakiti_client.
* If a solution is announced but for after the deadline, it can be tolerate if justified (e.g. special kernel update requiring different vendor update). In case of doubt don't hesitate to escalate to IRTF.
*** If the vulnerability then disappear from Pakiti, with or without any other message, close the ticket
 
|-
The main idea behind such handling is to make sure that sites are aware of the issue and working on it. We usually don't penalize sites that are showing good intention even if the progress is not within the procedure: SEC03 put deadlines on site to do few things, but does not put deadline on the CSIRT to
| 5
enforce them, allowing us to adapt our answer.
| If a solution is announced but for after the deadline, it can be tolerate if justified (e.g. special kernel update requiring different vendor update). In case of doubt don't hesitate to escalate to IRTF.
 
|}
I'm saying multiple time "escalate to IRTF", but as I understand there is no such system in RT, so pinging us by sending a mail to irtf@ should be enough.

Revision as of 17:56, 2 May 2018

Main EGI.eu operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security


EGI Infrastructure Operations Oversight menu: Home • EGI.eu Operations Team • Regional Operators (ROD) 



Work instruction to handle new Security Vulnerability handling GGUS tickets

The purpose of this page is to provide instructions to the EGI Operations team members on how to handle Security Vulnerability identified by IRTF.

The main idea behind this handling is to make sure that sites are aware of the issue and working on it. Usualy sites that are showing good intention are not penalized even if the progress is not within the procedure: SEC03 put deadlines on site to do few things but does not put a deadline on the CSIRT to enforce them, allowing to adapt the answer.

Step Action
1 IRTF is responsible for:
  • looking at Pakiti/the security dashboard
  • looking for false positives
  • creating new tickets with a due date of 3 days.
2a If there is no acknowledgement or answer from the site:
  • 1 working day before the due date, send another reminder via RT
  • .5 working day before the due date, send a last reminder, potentially including operational contacts in addition of security contacts. In such case, in case of an answer, make sure to verify that the security contact is still valid
  • After the due date, suspend the site
2b If there is an acknowledgement, but no solution announced:
  • 1 working day before the due date, check 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)

3 After the due date, if there is still no answer/solution announced, suspend the site
4 If a solution is said to be deployed:
  • If it's a mitigation:
    • If different from any mentioned in the advisory escalate to IRTF
    • If it's the same, wait for up to a day and check the security dashboard
  • If it's a simple package/kernel update, check pakiti:
    • If there is a report for the affected node(s) without any vulnerability, thanks and close the ticket
    • If the last report for the affect node(s) is still from before the update, ask to run the pakiti client by following https://wiki.egi.eu/wiki/EGI_CSIRT:Pakiti_client.
      • If the vulnerability then disappear from Pakiti, with or without any other message, close the ticket
5 If a solution is announced but for after the deadline, it can be tolerate if justified (e.g. special kernel update requiring different vendor update). In case of doubt don't hesitate to escalate to IRTF.
Retrieved from "https://wiki.egi.eu/w/index.php?title=WI07_Security_Vulnerability_handling&oldid=99100"