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 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.

There is now also a plan to enter all types of vulnerability that are relevant to the EGI infrastructure in the report-vulnerability tracker, including those relating to the Linux operating system and software which comes with it, to allow a consistent risk assessment for all software vulnerablilities. Some CSIRT members have joint the RAT, and contact with relevant software providers of the for this will be handled mainly by the CSIRT members in the RAT. Of course, all RAT members will be asked for their opinion on the risk.

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. This is intended to help the RAT handle standard vulnerability bugs in the middleware distributed by the EGI UMD (or IGE).

Issue Handling Templates are available to help the RAT inform appropriate people Note that contact details i.e. e-mail addresses for the various software providers will be forwarded to the RAT and updated when necessary.

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.

• If the issue is public and/or it concerns the operating system or software which comes with the operating system, add the csirt sub-group as admin cc.

• Acknowlege the Reporter - Let the reporter know that a real person is aware that the vulnerability has been reported - template ReporterAfterReport cc the Rat.

• For issues concerning Grid middleware, or other software which comes with the middleware distributions
  • Contact sofware provider and/or developers (according to instructions/contacts for particular software provider) - template SoftwareProviderAfterReport
  • Add developer(s) as adminCC in the Request Tracker - so they can fully participate

• For issues concerning the operating system or software which comes with the operating system (most non SLA software)
  • add CSIRT sub-group (RAT additions) to admin cc for the tracker issue
  • CSIRT sub-group and SVG will decide who/how to contact the software provider

• Alert the RAT - template RATAfterReport.

This should be done as soon as possible.

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.

For issues which concern operating systems, it will be mainly csirt members who carry out the investigation - some of these are in the RAT too.

Information found should be summarized in the Request Tracker item.

This phase is complete when the situation is established, including the effect in the EGI environment.

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 should be discussed on the RAT mailing list.

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 normally look at the issue to establish the risk is 3 - 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.

The Risk category and reasons should be summarized in the Request Tracker item.

If the Risk is 'Critical' then SVG and CSIRT will jointly handle the problem. Some notes SVG-CSIRT Critical Vulnerability Notes will help to decide what to do next.

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)
• High 6 weeks
• Moderate 4 months
• Low 1 year

Inform the reporter of the issue of the outcome - template ReporterAfterRisk

Informing relevant people

• For issues concerning Grid Middleware (EMI/IGE etc)
  • Inform appropriate developers, software provider, packaging people, and EGI middleware unit - template FixingAlertAfterRisk
  • Add the software provider, packaging people, EGI middleware unit people as adminCC to the item
  • Use the Contacts document (ListOfContacts) to find the correct people.

• For issues concerning operating systems, or software which comes with the operating system, CSIRT members will normally ask software providers for a solution according to urgency.

The SVG RAT aims to get to this point within 4 working days, but within at most 1 working day for critical vulnerabilities.

Draft Advisory

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.

Template AdvisoryTemplateGeneral

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.

The advisory should also be sent to the EGI CSIRT Team, Site security contacts, and NGI security contacts, and copied to the NOC managers (See contact information.)

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.

Note that closing an issue means setting it to 'resolved' in the EGI RT tracker. It should be made clear why it has been resolved, for example 'This has been resolved by version x of software released on <date>.

| 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 |