SVG:RAT Issue Handling Instructions
Main page | Software Security Checklist | Issue Handling | Advisories | Notes On Risk | Advisory Template | More |
RAT Issue Handling Instructions
This page is under construction. |
This page is intended for RAT members to provide a summary of what to do when a software vulnerability has been reported. It is intended as a practical summary, to help the RAT carry out the process. Note that this is a first draft, and will probably change/improve as we follow the process.
The full process is described in the Software Vulnerability Isssue handling process document
Also note that common sense may be used - as not all issues are straight forward. The most important thing to remember is not to release information publicly that may be useful to an attacker.
Note that contact details i.e. e-mail addresses for the various software providers will be forwarded to the RAT.
When a new issue is reported
The RAT member on duty should:
- Enter into the Request Tracker - If the issue was not reported via the tracker, including adding a cc to the reporter in the tracker.
- Acknowlege the Reporter - Let the reporter know that a real person is aware that the vulnerability has been reported - template ReporterAfterReport cc the Rat.
- Contact sofware provider - template SoftwareProviderAfterReport
- Contact developer(s) - if possible - template SoftwareDevelopersAfterReport
- Alert the RAT - template RATAfterReport.
This should be done as soon as possible.
Enter appropriate people in tracker
Enter developers and software providers as adminCC for this issue in the Request Tracker after this is clearly established.
Investigate Issue
Some RAT members with appropriate knowlege and experience, along with the software provider and developers should investigate the issue, establish whether it is real, and what the effects of an exploit might be.
Information should be placed in the Request Tracker, either directly or as a reply to an e-mail from the tracker concerning the issue.
Risk Assessment
If the issue is valid request a risk assessment to the RAT - template RATRequestRiskAssessment
RAT members should then look at this issue if they are able to, and provide their opinion of the Risk.
The Risk category is established by vote, each RAT members opinion of the Risk Category (Critical, High, Moderate or Low) is treated as their Vote. Apart from the case of 'Critical' issues - RAT members should have a least 24 hours to respond. The minimum number of RAT members who should give their opinion is 3 to establish the risk - although in most cases it is hoped that more will respond. If any member considers the issue to be critical - all RAT members who are at work should give priority to looking at the issue - and give their opinion on the risk.
Set Target Date
After the risk category is established, the risk is set in the request tracker, and the target date is set.
- critical 3 days (a special process is carried out TBW)
- High 6 weeks
- Moderate 4 months
- Low 1 year
Inform the reporter of the issue of the outcome - template ReporterAfterRisk
Inform appropriate developers, software provider, packaging people, and EGI middleware unit - template FixingAlertAfterRisk
The SVG RAT aims to get to this point within 4 working days.
Draft Advisory
The advisory template has not been written yet.
The advisory should be drafted - it should alert the sites as to the problem the vulnerability may cause - but not provide information to allow an attacker to exploit the problem.
The advisory should be agreed between the software providers, probably including the developers and the RAT.
Be willing to help
While it is not an SVG RAT activity to fix vulnerabilities - RAT members should be willing to give advice where appropriate if developers need it.
Release Advisory
The advisory should be released on the target date or when the problem is fixed.
(exact location TBD.)
Close issue
The issue is normally closed:
- If problem is found to be invalid
- When the problem is fixed in the software available to the EGI infrastructure and an advisory
has been issued.
- If a decision has been made not to fix - in this case an advisory will be issued
- If the issue turns out to be operational - and not a software problem. An advisory will be sent out in conjuction with CSIRT.
| Issue Handling Summary |
Reporters |
SVG View |
Software Providers |
EGI MW Unit |
Deployment |
Notes on Risk |