Hello LCG rollout people,

As the grid security vulnerability group got mentioned on the list by
Stephen, maybe now is a good time to circulate the agreed terms.

There was a lot of discussion on disclosure some months ago, and it was
decided that the group would not decide on disclosure, but raise the
issue to LCG, EGEE and GridPP management.  The terms below have been
formally agreed by LCG, EGEE and GridPP management.

Note below that any sysadmins in GridPP LCG or EGEE are entitled to join
the group.  All we require is that you agree not to make information
learnt as a result of being a member of the group public. We are not
asking for any formal signatures, just a gentleman's (or woman's)
agreement in an e-mail. The reason we don't make information public is
because much of the information is gained from inside knowledge of the
middleware, particularly the EGEE project, we are not an independent
body like CERT-CC. 

We have already circulated information on some issues to the LCG
security contacts list, and are improving and refining our process.

Linda.


------------------------------
Security Vulnerability Group
------------------------------

We have formed a security vulnerability group, internal to EGEE, LCG,
and GridPP. The purpose of this is to inform developers and deployment
people of vulnerabilities as they are identified and encourage them to
produce fixes or to reduce their impact.  

A subset of the vulnerability group is a core group currently led by
Linda Cornwall from RAL. This core group manages the group including its
membership.  Sysadmins and Developers in EGEE, LCG and GridPP are
entitled to join the group, others at the discretion of the core group.

Information on vulnerabilities will be entered in a database which is
readable only by members of the group. 

If urgent action is needed then system administrators at registered
sites will be informed (OSCT is responsible for defining the mechanism
to do this). 

Mirror entries will be entered into the world-readable JRA1 savannah
database but with the details missing.

The vulnerability will be assigned to the appropriate development
cluster and a target time for resolution (usually 45 days) will be
assigned.  

If a solution isn't available by the target time sites will be informed
of the problem by forwarding information on the specific vulnerability
and a risk assessment to the appropriate list(s) defined by OSCT. 

The vulnerability group will not publish information on vulnerabilities
to which there isn't a solution, however once the sites receive this
information we cannot guarantee they will not publicise it. 

We will also produce a web page accessible to anyone with an appropriate
grid certificate listing the number of vulnerabilities and their status
for each piece of software, to enable progress to be tracked and
encourage the resolution of problems.

We will report progress including the number of vulnerability bugs that
are open for each piece of software, including those that are open
beyond their target time, to JRA1 and SA1 management on at least a
monthly basis. 

The work is carried out on a best efforts basis. We are a group
facilitating the tracking and reduction of potential vulnerabilities,
including providing a process where potential problems can be kept
private pending their resolution. 

JRA1 and SA1 management are responsible for the software and deployment
along with their own policy on the public release of vulnerability
information.

All liability or responsibility, if any, to sites and/or other
customers, internal or external, of the grid software rests with the
project(s) as a whole and its management and not with the vulnerability
group.

We encourage open source middleware developers to work towards the
adoption of open responsible public disclosure of all security
vulnerabilities after a suitable period of time. This responsibility
remains with JRA1 and SA1 management and not with the vulnerability
group.

-----------------------------------------
Notes :-
 
Any vulnerability that has been exploited is considered an incident and
should not be handled by the vulnerability group, but be handled by
agreed incident response procedures.  The vulnerability group aims to
reduce the likelihood of incidents. 

We are not doing security operations, the OSCT (EGEE SA1 Operational
Security Coordination Team) will define the appropriate mailing list or
contacts for informing sites and system administrators.

The process for handling the vulnerabilities will be reviewed as we
progress.

------------------------------------------


-----------------------------------------
Dr Linda Cornwall,
Particle Physics Department,
The Rutherford-Appleton Laboratory,
Chilton, DIDCOT, OX11 OQX
England

Tel. 44/0 1235 44 6138

E-mail [log in to unmask]