Summary of the Vulnerability Procedure

This summarizes the procedure for handling issues by the Grid Security Vulnerability Group (GSVG). It should be followed by GSVG members, and is made visable to all so it is clear what we should be doing.

The core group manages the process, and the Risk Assessment Team (RAT) carries out the risk assessments and writes advisories.

GSVG duty rota

Each day there is 1 Core group member on duty

Submision of an issue

Issues may be submitted either by

After Submission of an issue

The duty core member:--

  • Enters the issue into the Savannah, if it has been submitted by any other means
  • Acknowleges the reporter with a standard letter
  • Asks the RAT for a Risk Assessment

Risk Assessment

The Core member ensures that a Risk assessment is carried out, and is fully responsible for the issue until the Risk Assessment is complete and issue passed on for resolution. This includes ensuring any appropriate people including developers and the reporter of an issue are consulted to check facts. (The Core member may delegate to other RAT members, or pass on responsibility if he or she is not going to be available throughout.)

  • The RAT establishes the Risk Category, which is one of Extremely Critical, High, Moderate, or Low
  • The Advisory is partially written.

Core member handles issue

  • If the Issue is Extremely Critical, EMT are informed immediately
  • If the Issue is Extremely Critical, a preliminary advisory (ususally without any recommendations) is sent to OSCT.
  • If the Issue is found to be not true or invalid, the core member closes the issue and informs the reporter of this finding. No further action is taken.
  • The Target Date (TD) is set to the value for that particular risk
  • A mirror bug is entered if it is due to a problem with EGEE middleware (this includes configuration files). The TD is included in the text, it is set to critical if the issue is considered Extremely Critical or High Risk, set to minor otherwise
  • A standard mail is sent to the Reporter, advising of the date by which it should be fixed
  • The issue is allocated to the Appropriate developer
  • An E-mail is sent to EMT/JRA1 representatives informing them of the issue, and the date by which it should be resolved, along with the partially completed advisory

After informing the EMT/JRA1/SA3

The issue will no longer be primarily the responsibility of the GSVG. The issue is dealt with by the release process. The development cluster and the integration team know that the issue will be made public on the Target date.

For Medium and Low risk issues, the EMT/JRA1/SA3 are reminded monthly

On Target Date or when fixed

  • Advisory is placed on the advisories web page.
  • Advisory should be sent to an open subscription e-mail list (soon)
Note that if an issue concerns 3rd party software we are not allowed to make an advisory public if it is not fixed without the agreement of the people providing the 3rd party software.

More details

For more details please see the Vulnerability Process detailed description. This document includes a description of the Criteria for the various risk categories.

Back to issues page GSVG home


Last modified Wed 18 July 2007 . View page history
Switch to HTTPS . Website Help . Print View . Built with GridSite 1.4.3
For more about GridPP please contact Neasan O'Neill