Difference between revisions of "WI07 Security Vulnerability handling"
Jump to navigation
Jump to search
(Add some links to related pages) |
m (some more links) |
||
Line 6: | Line 6: | ||
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 to enforce them, allowing to adapt the answer. | 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. | ||
{| align="center" cellspacing="0" cellpadding="5" border="1" | {| align="center" cellspacing="0" cellpadding="5" border="1" | ||
Line 14: | Line 14: | ||
|- | |- | ||
| 1 | | 1 | ||
| IRTF is responsible for: | | [[IRTF]] is responsible for: | ||
* looking at Pakiti/the security dashboard | * looking at Pakiti/the security dashboard | ||
* looking for false positives | * looking for false positives |
Revision as of 18:02, 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:
|
2a | If there is no acknowledgement or answer from the site:
|
2b | If there is an acknowledgement, but no solution announced:
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:
|
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. |