Skip to content

OSG Software Vulnerability Notification Handling

A software vulnerability is a weakness that allows an attacker to violate the integrity of the OSG infrastructure and/or the sites for grid computing. The OSG Software team is the primary group responsible for vulnerability handling in software that is developed and distributed by OSG. As part of the vulnerability handling process, the OSG Security Team performs a vulnerability assessment to determine the actions to take.

Process

The OSG Security team is responsible for performing the vulnerability assessment and notifying the OSG stakeholders about software vulnerabilities affecting the OSG infrastructure.

1. Initial Report

  • The software vulnerability handling process begins when a vulnerability report is acknowledged by members of the OSG Security team, the OSG Software team or the GOC staff:
  • The members of the OSG Security team actively monitor the mailing lists and other venues for announcements and discussions of vulnerabilities that may impact the software distributed by OSG and the software used at the sites for grid computing and data management.
  • The OSG Security team should be alerted via an email or through a GOC ticket indicating it is a security issue and the urgency to resolve.
  • OSG members are encouraged to report all security issues, including software vulnerabilities, to [email protected], [email protected].

2. Triage

  • The OSG Software and Security teams perform triage on discovered vulnerabilities or incoming reports to determine if vulnerability handling is required according to the following priority:
  • Priority 1: The security of services operated by OSG directly (OSG Operations, Glidein Factories), and software developed by OSG.
  • Priority 2: The security of software developed elsewhere which is packaged and distributed by OSG.
  • BEST EFFORT ONLY: Software issues that may impact large numbers of OSG's resource providers or users in a serious way, but do not fit into either of the priority groups above.
  • If the report is valid and it matches the given priorities, the vulnerability assessment procedure must be triggered and a member of the OSG Security team should be assigned as responsible for leading the process.
  • If the report is valid, but it does not match any of the given priorities, the OSG Security team does not trigger the vulnerability assessment procedure. However, if the reporter agrees, the OSG Software team will handle the report as a regular software issue.
  • If the report is not valid, no further actions within the OSG Security and OSG Software teams are required.
  • If the incoming report is made through a GOC ticket, it must be updated accordingly. Regardless the course of action decided for the report, the reporter must receive an acknowledgment from the OSG Security team through a direct email. Describing the course of action email message is left at OSG Security team discretion.

3. Analysis

  • The OSG security team assesses the risk associated with the vulnerability in consultation with the OSG Software team, the relevant software providers and other related parties as appropriate.
  • Based on the risk assessment, if a fix is required in the OSG Software stack, the OSG Security team should discuss with OSG Software and Release teams to set a target date. If the fix should come from the software provider, the OSG Security team should work with the software provider to determine when a fix will be available and if there are work-arounds.
  • The OSG security team prepares a draft for an advisory, and establishes as needed a grace-period for updates and further analysis. All members of the OSG Security team are asked to review the draft and send feedback. The final revision of the advisory should be approved by the OSG Security Officer.

4. Disclosure

  • A security announcement is sent to the VO/Site/SC security contacts. A GOC Security ticket should be created for further discussion about the vulnerability.
  • The OSG Security team determines if a private disclosure to OSG security contacts is warranted.
  • The OSG Security team may revise the target date for a public disclosure as needed, in consultation with involved parties.

Note

For issues that impact peer grids (EGI, WLCG, XSEDE), the OSG Security team makes a private disclosure to the corresponding peer grid contacts.

5. Closure

  • The GOC Security tickets are usually closed after 2 weeks.
  • If a grace-period has been established and the ticket must remain open, the member of the OSG Security Team leading the process should update the ticket accordingly.