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 |