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
m (Update RT links)
(Update Security Dashboard URL)
(13 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Template:Op menubar}} {{Template:GO menubar}} {{TOC_right}}  
{{Template:Op menubar}} {{Template:GO menubar}} {{TOC_right}}  


= Work instruction to handle new Security Vulnerability handling GGUS tickets  =
[[Category:Infrastructure_Oversight|*]]


The purpose of this page is to provide instructions to the EGI Operations team members on how to handle Security Vulnerability identified by [[IRTF]].
= Work instruction to follow Security Vulnerability handling RT tickets  =
 
The purpose of this page is to provide instructions to the EGI Operations team members part of the operations-vulnerability-handling SSO group 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.
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_EGI-CSIRT_Critical_Vulnerability_Handling|SEC03]] put deadlines on site to do few things but does not put a deadline on the [[Csirt|CSIRT]] to enforce them, allowing to adapt the answer.
Usually, sites that are showing good intention are not penalized even if the progress is not strictly within the procedure: [[SEC03_EGI-CSIRT_Critical_Vulnerability_Handling|SEC03]].


{| align="center" cellspacing="0" cellpadding="5" border="1"
{| align="center" cellspacing="0" cellpadding="5" border="1"
Line 15: Line 17:
| 1
| 1
| [[IRTF]] is responsible for:
| [[IRTF]] is responsible for:
* looking at Pakiti/the security dashboard
* looking at [https://pakiti.egi.eu/ Pakiti] and [https://operations-portal.egi.eu/ROD#csi Security dashboard].
* looking for false positives
* looking for false positives
* creating new [https://rt.egi.eu/ RT] tickets in the Vulnerability Handling queue with a due date of 3 days.
* creating new [https://rt.egi.eu/ RT] tickets in the Vulnerability Handling queue with a due date of 3 days.
Line 21: Line 23:
| 2a
| 2a
| If there is no acknowledgement or answer from the site:
| If there is no acknowledgement or answer from the site:
* 1 working day before the due date, send another reminder via [https://rt.egi.eu/ RT]
* 1 working day before the due date, EGI Operations send another reminder via the [http://go.egi.eu/rt_vulnhand Vulnerability Handling Queue in RT] using the '''Reply''' action.
* .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
<nowiki>Dear security contact for XX-XX-XXX,
 
This is a friendly reminder that we didn't receive any update about this ticket!
 
Thanks,</nowiki>
* .5 working day before the due date, EGI Operations send a last reminder, potentially including operational contacts in addition to security contacts. In such case, in case of an answer, verify that the security contact is still valid
* After the due date, suspend the site
* After the due date, suspend the site
|-
|-
| 2b
| 2b
| If there is an acknowledgement, but no solution announced:
| If there is an acknowledgement, but no solution announced:
* 1 working day before the due date, check Pakiti:
* 1 working day before the due date, EGI Operations checks [https://pakiti.egi.eu/ Pakiti]:
** If there is no change, ask for progress/for an update, insisting
** If there is no change, ask for progress/for an update, insisting
** If the vulnerability disappeared from [https://pakiti.egi.eu/ 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)
** If the vulnerability disappeared from [https://pakiti.egi.eu/ 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
| 3
| After the due date, if there is still no answer/solution announced, suspend the site
| After the due date, if there is still no answer/solution announced, EGI Operations suspend the site
|-
|-
| 4
| 4
Line 38: Line 45:
* If it's a mitigation:
* If it's a mitigation:
** If different from any mentioned in the advisory escalate to [[IRTF]]
** 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 the same, EGI Operations wait for up to a day and check the security dashboard
* If it's a simple package/kernel update, check [https://pakiti.egi.eu/ Pakiti]:
* If it's a simple package/kernel update, EGI Operations check [https://pakiti.egi.eu/ Pakiti]:
** If there is a report for the affected node(s) without any vulnerability, thanks and close the ticket
** 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 [[EGI_CSIRT:Pakiti_client]].
** 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, close the ticket
*** If the vulnerability then disappear from [https://pakiti.egi.eu/ Pakiti], with or without any other message, close the ticket
|-
| 5
| If a solution is announced but for after the deadline, it can be tolerated if justified (e.g. special kernel update requiring different vendor update). In case of doubt don't hesitate to escalate to [[IRTF]].
|}
|}

Revision as of 14:19, 28 April 2021

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 follow Security Vulnerability handling RT tickets

The purpose of this page is to provide instructions to the EGI Operations team members part of the operations-vulnerability-handling SSO group 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. Usually, sites that are showing good intention are not penalized even if the progress is not strictly within the procedure: SEC03.

Step Action
1 IRTF is 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.
2a If there is no acknowledgement or answer from the site:
Dear security contact for XX-XX-XXX,

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

Thanks,
  • .5 working day before the due date, EGI Operations send a last reminder, potentially including operational contacts in addition to security contacts. In such case, in case of an answer, 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, EGI Operations 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)
3 After the due date, if there is still no answer/solution announced, EGI Operations 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, EGI Operations wait for up to a day and check the security dashboard
  • If it's a simple package/kernel update, EGI Operations 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 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, close the ticket