Difference between revisions of "SVG:SVG-CSIRT Critical Vulnerability Notes"
(Created page with '{{svg-header}}') |
|||
Line 1: | Line 1: | ||
{{svg-header}} | {{svg-header}} | ||
This is to help SVG and CSIRT handle a critical vulnerability prior to following the approved procedure at | |||
Sme of these notes may also be useful for 'High' risk vulnerabilities, or vulnerability handling in general. | |||
== Consider Sending a 'Heads up' == | |||
This is optional, if quite a lot is known about the problem and it is likely that the team will send an advisory recommending what to do very shortly it might not be considered necessary. | |||
The purpose of sending a ‘heads up’ is to alert sites that the critical vulnerability exists. This should refer to any public announcements of the problem. (Often there are public announcements, and it is often because of public announcements or public exploits that the vulnerability has become classified as critical.) This should also warn sites to expect further instructions, such as the requirement to install updates urgently when they become available. | |||
You may use the template – HeadsUp.txt | |||
This will usually be sent GREEN | |||
Send to site-security-contacts@mailman.egi.eu and ngi-security-contacts@mailman.egi.eu | |||
== Establish the effect of the exploit in the EGI Infrastructure == | |||
This may be very simple, such as by running a publicly available script any user authorized to use the Grid can get root. It may be more complex. This may already have been done by the SVG in the case of middleware issues reported to them, or it may already be readily available from some other source which is why the vulnerability has been assessed as ‘Critical’ | |||
== Establish in what situation the vulnerability can be exploited== | |||
Establish which pieces of software and/or configuration are required in order for this to be exploited. This may e.g. involve establishing whether the exploit can be exploited on only one version of Linux, multiple versions, or only on sites configured in certain (possibly non-standard) ways. Various people may volunteer to test whether the exploit works in various circumstances, such as on a site they manage. | |||
== Establish how widespread the problem may be in the EGI Infrastructure == | |||
== Follow approved procedure == | |||
When what action sites should take to eliminate the vulnerability follow the approved procedure at: | |||
Go to | |||
{{svg-rat-info}} | |||
{{svg-issue-views}} |
Revision as of 15:59, 19 July 2011
Main page | Software Security Checklist | Issue Handling | Advisories | Notes On Risk | Advisory Template | More |
SVG-CSIRT Critical Vulnerability Notes
This is to help SVG and CSIRT handle a critical vulnerability prior to following the approved procedure at
Sme of these notes may also be useful for 'High' risk vulnerabilities, or vulnerability handling in general.
Consider Sending a 'Heads up'
This is optional, if quite a lot is known about the problem and it is likely that the team will send an advisory recommending what to do very shortly it might not be considered necessary. The purpose of sending a ‘heads up’ is to alert sites that the critical vulnerability exists. This should refer to any public announcements of the problem. (Often there are public announcements, and it is often because of public announcements or public exploits that the vulnerability has become classified as critical.) This should also warn sites to expect further instructions, such as the requirement to install updates urgently when they become available.
You may use the template – HeadsUp.txt
This will usually be sent GREEN
Send to site-security-contacts@mailman.egi.eu and ngi-security-contacts@mailman.egi.eu
Establish the effect of the exploit in the EGI Infrastructure
This may be very simple, such as by running a publicly available script any user authorized to use the Grid can get root. It may be more complex. This may already have been done by the SVG in the case of middleware issues reported to them, or it may already be readily available from some other source which is why the vulnerability has been assessed as ‘Critical’
Establish in what situation the vulnerability can be exploited
Establish which pieces of software and/or configuration are required in order for this to be exploited. This may e.g. involve establishing whether the exploit can be exploited on only one version of Linux, multiple versions, or only on sites configured in certain (possibly non-standard) ways. Various people may volunteer to test whether the exploit works in various circumstances, such as on a site they manage.
Establish how widespread the problem may be in the EGI Infrastructure
Follow approved procedure
When what action sites should take to eliminate the vulnerability follow the approved procedure at:
Go to
| RAT Issue Handling Instructions |
RAT Issue Handling Templates |
RAT Issue Handling Templates contd |
SVG-CSIRT Critical Notes |
Advisory Template |
| Issue Handling Summary |
Reporters |
SVG View |
Software Providers |
EGI MW Unit |
Deployment |
Notes on Risk |