OSG Software Vulnerability Handling
A software vulnerability
is a weakness that allows an attacker to violate the integrity of the system.
The VDT team is the primary group responsible for software vulnerability handling in OSG for software that is distributed by OSG. This process does not apply to software vulnerabilities for software that might be used by OSG but is not distributed by OSG. (For example, it does not cover the deployment of Twiki by the GOC.)
Software vulnerabilities are distinguished from security incidents.
A security incident is a violation of the integrity of the system
(for example, an account, server, or credential compromise).
Security incidents in OSG are handled by the security team following the
incident response process
This document defines the process for handling software vulnerabilities in software distributed by OSG.
The OSG Software Coordinator has overall responsibility for this process.
The OSG Security Officer has responsibility for software vulnerability risk assessment.
The Virtual Data Toolkit
(VDT) provides software to OSG participants and to others who are not associated with OSG.
The vulnerability handling process must strive to meet the needs of all VDT consumers.
- Initial Report
- The software vulnerability handling process begins when a vulnerability report is sent to goc [at] opensciencegrid.org . This report will then be processed by a GOC staff member, who will create a confidential ticket for it and alert the software and security teams.
- VDT and OSG security team members actively monitor mailing lists and other venues for announcements and discussions of vulnerabilities that may impact the VDT. When they discover vulnerabilities, they create a ticket to begin the vulnerability handling process.
- OSG members are encouraged to report all security issues, including software vulnerabilities, to email@example.com. When receiving software vulnerability reports to this address, the GOC and/or the OSG Security Team will create tickets as described above.
- The VDT team performs triage on incoming reports to determine if vulnerability handling is required.
- Is the message a software vulnerability report? If not, it is handled like a regular VDT ticket by the VDT team.
- Is the vulnerability in VDT software (i.e., software included in a currently-supported VDT distribution)? Does it significantly impact VDT software? If not, it is out of scope and should be forwarded to the software provider (as appropriate) and the ticket should be closed.
- For valid reports, a VDT team member promptly sends an acknowledgement to the reporter.
- The VDT team member initially handling the ticket promptly assigns a ticket owner, who is responsible for leading the vulnerability handling process.
- The ticket owner performs a risk assessment in consultation with the OSG security team (firstname.lastname@example.org), the relevant software providers, the OSG executive team (email@example.com), and other related parties as appropriate. Severity categories are defined below.
- The ticket owner sets a target date for releasing an advisory, based on the risk assessment.
- The ticket owner works with the software provider to determine when a fix will be available and if there are work-arounds.
- For issues that impact peer grids (EGEE, TeraGrid), the ticket owner promptly makes a private disclosure to the peer grid contacts.
- The OSG Security team determines if a private disclosure to OSG security contacts is warranted.
- The ticket owner may revise the target date for a public disclosure as needed, in consultation with involved parties.
- When sufficient information about the issue is gathered, the ticket owner issues a public VDT Security advisory.
- The advisory should properly credit the reporter. Always check with the reporter to see how he or she would prefer to be credited (if at all).
- The advisory should follow the VDT Security Advisory template. It should include an advisory number, the relevant VDT ticket number(s), and a timeline. It should be published on the VDT Security Advisories page at a stable URL, where the latest version can always be found.
- The advisory should include details sufficient for system administrators to determine their risk, but it should not include details that make it easier for an attacker to exploit the vulnerability. This can be a difficult trade-off. When in doubt, consult the security team.
- The advisory may be released at the same time as a new VDT software update that resolves the issue, but if a timely fix is not available, an advisory may be released beforehand to provide notification of the risk.
- The advisory may recommend a work-around while a VDT software update is in preparation.
- The advisory may recommend that VDT users should stop using a software component until a fix is available.
- When feasible and as appropriate, the timing of the advisory release should be coordinated with the software provider and other grid vulnerability handling teams (GSVG, Globus)
- The security team may recommend that OSG sites and/or VOs take action in response to the advisory, but this is a separate action from the release of the public advisory by VDT to all VDT users.
- Once the advisory is posted on the VDT Security Advisories page, the ticket owner announces it on the firstname.lastname@example.org mailing list and to the GOC. The GOC will forward it as appropriate to OSG sites and users. The announcement may be combined with a VDT release announcement (for the release containing the fix).
- In case new information becomes available, the ticket owner updates the advisory page and sends a new announcement to the email@example.com mailing list and the GOC, who will forward it as appropriate.
- Software Update
- The ticket owner works with the software provider to obtain a fix for the issue.
- The VDT team performs internal testing and validation of the fix.
- Unless the issue is critical (requiring a fix within days), the fix should be tested in the VTB before inclusion in an official VDT release. VTB testing typically has a one week turn-around time.
- If possible (given the required time line) fixes that require significant changes should also be tested in the ITB before inclusion in an official VDT release.
- The VDT team issues a new VDT release with the fix together with an (updated) advisory.
- The ticket owner closes the ticket when the software update(s) and public advisories are released.
- Unless the information in the ticket is still sensitive, the ticket owner makes the ticket public at this time.
- Depending on the severity level of the vulnerability, the ticket owner sends a short email to firstname.lastname@example.org notifying the EB that the issue is closed.
|| This rating is given to flaws that are likely to result in major, grid-wide security incidents.
|| Target Date: 2 business days
Response is coordinated with the OSG Security Team. Prompt advisories and patches are needed to avoid the spread of an attack.
|| This rating is given to flaws that allow unauthenticated, remote attackers to gain privileges (run executable at root level) or allow authenticated users to elevate privileges to root. DoS? attacks caused by unauthenticated users are in this category. If the target system of the DOS attack does not affect OSG production, then the rating is dropped to low level.
|| Target Date: 3 weeks
|| This rating is given to flaws with potentially serious consequences but where exploit is unlikely, because they are difficult to exploit or require uncommon configurations or are easily traceable to misbehaving, authenticated users. DoS? attacks that can be exploited by local users are in this category.
|| Target Date: 3 months
Fixes for these issues will likely go through ITB testing and be included with other fixes in periodic VDT updates.
|| This rating is given to flaws where impact is considered minimal.
|| Target Date: 6 months
Fixes for these issues may be scheduled for major VDT updates.
The following mailing lists provide software vulnerability information:
A member of the OSG security team will monitor the mailing lists, etc. for vulnerability notices.
Currently this is Kevin Hill.
Topic revision: r30 - 25 Feb 2012 - 00:57:44 - MarkoSlyz