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, in particular if the SVG chair is not available.

The full process is described in the EGI Software Vulnerability Issue Handling Process

This page is a simple 'how to' to make sure the important stages are not missed.

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.

Issue Handling Templates are available to help the RAT perform these tasks.

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.

• Acknowledge the reporter by e-mail, to ensure the reporter knows a real SVG member has seen it, and CC the RAT.

• Alert the RAT

• Alert the software provider unless:--
  • The report is clearly invalid
  • The technology provider clearly knows about this issue

I.e. in most cases where the issue has not been announced publicly.

• In the case of VO specific vulnerabilities, also alert the VO Security Officer (Found in the VO-ID card in the ops portal)

• For issues concerning Grid middleware, or Cloud Middleware Distribution, or other software which comes with the middleware distributions or others connected with the project with an EGI SSO ID
  • Add developer(s) as adminCC in the Request Tracker - so they can fully participate

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. Now that a much wider variety of software is installed in the EGI infrastructure it is not reasonable to expect RAT members to be expert in all of it, and we are likely to need to rely more on the software providers to investigate.

For issues which are announced publicly, the RAT duty is to try and establish the effect in the EGI infrastructure as much as possible.

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.

If the conclusion is that the issue is invalid, or not applicable in EGI, or no further action is to be taken, inform the reporter of this.

Risk Assessment

If the issue is valid and applicable in EGI request a risk assessment to the RAT.

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 be given 2 days 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.

Unless the issue is 'Critical' Members should be given 2 working days to give their opinion, and a 'Last call' for an opinion should be sent.

Set Target Date

After the risk category is established, the risk is set in the request tracker.

If the issue has not been fixed, the target date is set.

• critical - a special process is carried out.
• High 6 weeks
• Moderate 4 months
• Low 1 year

Inform the reporter of the issue of the outcome

Informing relevant people

• Inform relevant people of the Risk and Target date
  • Inform appropriate developers, software provider, packaging people, and EGI middleware unit
  • Add the software provider, packaging people, EGI middleware unit people as adminCC to the item

• For issues concerning operating systems, or software which comes with the operating system,

CSIRT/IRTF members will normally ask software providers for a solution according to urgency in the unlikely event of something which is reported to us rather than announced.

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. It should state what sites should do, if anything.

If the issue is 'High' or 'Critical' and not public it should be 'AMBER'

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

If the vulnerability has already been fixed then the advisory can be released straight away.

Otherwise the advisory should be released on the target date or when the problem is fixed, which ever is the sooner.

The advisory should also be sent to the Site security contacts, and NGI security contacts, and copied to the NOC managers, EGI CSIRT Team, and the RAT as EGI Software Vulnerability Issue Handling Process

If the issue is 'High' or 'Critical' and the information is not public it should be 'AMBER' and NOT put on the wiki. It is usually set to 'WHITE' and put on the wiki 2 weeks later.

Most other issues can be set to 'WHITE' and put on the wiki straight away.

Unless the issue is 'Critical' release during what are normal working hours for most people in Europe, as sending to site security contacts tends to set off alarms which call people in out of hours.

Close issue

The issue is normally closed:

• If problem is found to be invalid or no action is to be taken.

• When the problem is fixed in the software available to the EGI infrastructure and an advisory

has been issued and on the wiki.

• If a decision has been made not to fix - in this case an advisory may still be issued

• If no further action by SVG.

Note that closing an issue means setting it to 'resolved' in the EGI RT tracker. Prior to setting to 'resolved' enter a 'reply to requestors' (selection box above the comment box) to make it 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 |