SVG:SVG-CSIRT Critical Vulnerability Notes
|Main page||Software Security Checklist||Issue Handling||Advisories||Notes On Risk||Advisory Template||More|
- 1 SVG-CSIRT Critical Vulnerability Notes
- 1.1 Consider Sending a 'Heads up'
- 1.2 Establish the effect of the exploit in the EGI Infrastructure
- 1.3 Establish in what situation the vulnerability can be exploited
- 1.4 Establish how widespread the problem may be in the EGI Infrastructure
- 1.5 Find out if or when a patch is likely to be available
- 1.6 Decide whether or not to wait for a patch
- 1.7 Find whether other action can mitigate or solve the problem
- 1.8 If interim action or mitigation is to be carried out
- 1.9 Follow approved procedure
SVG-CSIRT Critical Vulnerability Notes
This is to help SVG and CSIRT jointly handle a critical vulnerability prior to following the approved procedure at SEC03
This is fairly general, and applies regardless of the source of the vulnerability, such as whether it is in the Middleware supplied in the EGI UMD or in an operating system.
Some of these notes may also be useful for 'High' risk vulnerabilities.
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.
Send to site-security-contacts at mailman.egi.eu and ngi-security-contacts at 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
If the effect is only likely to occur on a small number of sites, it may be that it is better to simply handle it by contacting those sites and suggest they take appropriate action. If it affects a large number of sites, but not all sites, it is important to be clear about in what circumstances sites are affected.
Find out if or when a patch is likely to be available
In most cases, the Critical Vulnerability will be due to a software problem. If the Vulnerability is in the middleware supplied as part of the EGI UMD, then contact details will be available, and this task will probably already have been carried out by the EGI SVG. If the problem is in the operating system, then usually the SVG members who are also in CSIRT will chase the provider for a new version of the software.
Decide whether or not to wait for a patch
According to how long a patch is likely to be, decide whether or not to wait for a patch prior to recommending further action.
Find whether other action can mitigate or solve the problem
A small configuration change may be sufficient to prevent the vulnerability being exploited. If this is the case, establish what needs to be done in which circumstances. Test any changes that are recommended. Care should obviously be taken not to recommend a change in a hurry, which has no effect, prevents the site operating, or causes a worse problem than that it attempts to solve.
If interim action or mitigation is to be carried out
After testing, and no objections within CSIRT, write and send an initial advisory to sites including any recommendations for mitigation. You may use the AdvisoryTemplate to help make it easier to write. This will usually be sent as WHITE or GREEN.
GREEN should be the case if by recommending certain actions it reveals information that is not yet public which makes it easier for the issue to be exploited, or if the vulnerability has not been made public. Send to site-security-contacts at mailman.egi.eu and ngi-security-contacts at mailman.egi.eu
Follow approved procedure
When what final action sites should take to eliminate the vulnerability have been estalished write or update the advisory and follow the approved procedure at: SEC03