From Globus

Status of this Page

This page contains working process of the Security Committee. Changes to this process and addition of new members are by majority vote of the committee.

The Security Committee

The Security Committee is responsible for the handling of potential security holes in the software produced by the dev.globus community that might impact our users. It gets contacted by the finders of the problems before the problem report is made available to the public, to allow the projects to provide a fix in time for the report, thus reducing vulnerability to a minimum.

Membership model

The security committee is defined by being subscribed to the sec-committee email list. There are two categories of members:

• Members: these are regular committee members that take active part in the committee's work, and that can be assigned work items (e.g. become the owner of an issue, see below).
• Lurkers: these are people that "listen in". They may participate in any discussion, but any votes from a Lurker will be disregarded.

Only Members can vote. Majority quorom is considered to be reached if there's a majority within the set of Members.

A Member may step down and become a Lurker at anytime by sending an email to the list, or upon a majority vote. A Lurker may change status into Member after a majority vote.

Current Members

Current security committee Members are:

• Mine Altunay
• Rachana Ananthakrishnan
• Charles Bacon
• Jim Basney
• Lisa Childers
• Tim Freeman
• Mihael Hategan
• Keith Jackson
• Kate Keahey
• Raj Kettimuthu
• Stephen Langella
• Michael Link
• Ravi Madduri
• Sam Meder
• Laura Pearlman
• Alain Roy
• Robert Schuler
• Frank Siebenlist
• Gregor von Laszewski
• Von Welch

All other people subscribed to the sec-committee list have Lurker status:

• Olle Mulmo
• Tom Scavo
• Aaron Shelmire
• List is incomplete

Any change in the security committee membership should be reported to the Argonne MCS systems group so that they can make the corresponding change in the list of authorized posters to the security-announce@globus.org email list.

dev.globus Security Vulnerability Reporting and Handling

Terminology:

• issue a potential vulnerability
• vulnerability an issue which is decided by the security committee to require prioritized and expedient resolution

Reporting security vulnerabilities

• Potential security issues are reported by sending email to security-alert@globus.org
  • Non-sensitive, general conversations should occur on the security@globus email list (see Mailing Lists)
• Members of the Security Committee monitor the security-alert list. Upon receipt of a non-spam email, they will:
  • Forward the message to sec-committee@globus.org
  • Send an acknowledgment email to the reporter, with a reminder that the mailing list (security-alert@globus.org) should be copied on all further communication.

Steps to handle reported security vulnerability

• Each issue will be assigned an owner on the committee via round-robin order. The owner is responsible for making sure the vulnerability is resolved (they may seek help from anyone they choose).
• Discussions to establish if the reported issue is a threat will be conducted on sec-committee@globus.org.
• If it is not a threat, a reply should be sent back to the original reporter explaining the decision. Once it has been resolved, the issue and resolution should be added to resolved non threats page.
• If reported issue is a valid threat, a Globus Bugzilla entry should be created for the issue, with access restricted to “active-vulnerability” group.
• The Security Committee should work with component developers to design and develop a fix.
• A pre-announcement should be sent to the communities listed in Participating Communities Section with details on the reported security vulnerability and proposed fix.
• Components developers should work on fixes.
  • Commits to CVS should be done to coincide with any public announcement as closely as possible to prevent someone monitoring CVS from gaining early knowledge of the problem.
• Once all components have been fixed, patches and bundle should be generated for the supported versions (3.2.1 and 4.0.4 as of February 2007). Fixes should also be committed to trunk if relevant.
• A draft security advisory should be created in the format described below and sent to the sec-committee list for comments.
• A pre-announcement which includes the security advisory and patches should be sent to communities listed in the next section as well as to the original submitter if it is requested
• Any issues raised in previous step should be resolved and patches should be placed on the security advisories page.
  • In general, one working day should be allowed for depending communities to react to the patches and generate their own patches.
• Patches should be placed on the advisory page. Follow the directions at http://www-new.mcs.anl.gov/~globus/make-packages.html#update which are duplicated here for convenience:
  1. export CVSROOT=cvs.globus.org:/home/globdev/CVS/alliance-web
  2. cvs co alliance/toolkit/advisories.txt
  3. edit advisories.txt
  4. cvs commit alliance/toolkit/advisories.txt
  5. Verify that the advisories webpage lists your update, and it is downloadable.
• The security advisory announcement should be sent to security-announce@globus.org.
  • Note that Fridays or other days right before non-working days should be avoided for making announcements.
• The bug status should be changed to FIXED and access opened to the world.
• Once the security announcement is archived, a pointer to the announcement should be added to the advisory and status should be changed to CLOSED.

Participating Communities

Participating communities are communities which choose to participate in the Security Committee in exchange for advance notice of (potential) issues.

Current participating communities are:

To become a participant in the security committee:

• Communities wishing to become participating communities should send a request to any member of the security committee stating their request and reasons why.
• The criteria for inclusion are significant usage of Globus technologies, a demonstrated level of responsibility, and a willingness to serve on the security committee and help address issues. Ideally all three, but leave some flexibility.
• Decision to accept the community is by majority vote of the existing security committee Members.

Format of security advisory

This section describes the format for security advisory emails. See the security-announce archive for an example.

1. Title:

• Globus Security Advisory <year>-<advisory number> <Vulnerability>
• Example: Globus Security Advisory 2006-01: GSI Proxy generation tool

2. Original Issue Date

• Date of issue
• Example: August 15 2006

3. Last Revised

• Date of any previous revisions that were issued.
• Example: August 16 2006 (or) none

4. Software Affected

• List of all versions of Globus Toolkit that is affected by the vulnerability.

5. Specific Packages

• List of GPT package names of affected software

6. Reporter

• Name of reporter

7. Overview

• Brief overview of the problem followed by following sections:
  • Description
  • Impact
  • Solution

Links

• Security-announce archives
• Globus Toolkit Advisories