This was discussed at the EGEE PMB level, with the following conclusion:

SUMMARY: it is the PMB who decides the timeline to start suspending sites. In previous critical vulnerabilities, it was set to 7 days.

The PMB considers the security of the infrastructure as of paramount to the operation and reputation of the project. The potential damage that such vulnerabilities could cause to the infrastructure both in terms of loss of service and the damaging publicity were of great concern to the PMB.

The project has mandated the Grid Security Officer to work with the ROC Security Contacts (as well as the JSPG and GSVG) to pro-actively manage security policy and its operational implementation. The use of the security monitoring tool to mimic normal user site access patterns and to discover non-intrusively the host configuration information in order to infer potential site vulnerabilities was fully supported by the PMB. The PMB was disappointed that despite the established and agreed operational structures, sites were slow in responding, or refused to perform the necessary routine systems maintenance.

All sites are reminded that there is an established policy and procedure that allows a site to be suspended in general if the site is deemed to pose an immediate threat for the infrastructure. This is stated in the Grid Site Operations Security Policy (https://edms.cern.ch/file/819783/2/GridSiteOperationsPolicy-v1.4a.pdf):

"When notified by the Grid of software patches and updates required for security and stability, you shall, as soon as reasonably possible in the circumstances, apply these to your systems. Other patches and updates should be applied following best practice.
[...]
The Grid may control your access to the Grid for administrative, operational and security purposes and remove your resource information from resource information systems if you fail to comply with these conditions."

The federation representative of the PMB are following up within their own regions to understand why their sites were not immediately patched. However, the PMB noted that if the fix has not been installed at a particular site by a given deadline then the PMB reserves the right to remove the offending site from the EGEE production infrastructure in accordance with the established security policy. As the Grid Security Officer we ask you to inform the sites of these issues and as part of the site access agreement, the sites are mandated to follow these instructions or their access to the infrastructure could be curtailed.

We are now approach the deadline for addressing the vulnerability that raised this issue. If, following circulation of this notice, sites are still after 7 days exhibiting these vulnerabilities, please work with the ROC Security Contacts to curtail access of these sites to the infrastructure or ensure that there is a clear upgrade plan in place to eliminate these vulnerabilities.

Romain reported on the EGEE plans to integrate the Gilda training resources into the production infrastructure. There have been several e-mail threads on this. The issues were discussed earlier this week at the SA1 operations meeting. Romain reported that many concerns were raised about this and not just security-related ones.

The security concerns include the fact that the Gilda CA does not have robust enough identity vetting procedures to be accredited by IGTF.
Gilda has a separate VO which has been registered with EGEE and one suggested approach has been to leave Sites to decide to support the Gilda VO and to also trust the Gilda CA. The sites would then have to agree to take on any risks.

SCG discussed the security issues at some length and concluded that:

a. The risks are more complex than individual sites agreeing to take on the associated risks. Any risks associated with Gilda work running at EGEE production sites potentially threatens the whole infrastructure.

b. SCG is very concerned that EGEE procedures have allowed the Gilda VO (which violates currently adopted security policies) to be officially registered. SCG recommends that the Gilda VO should not be registered with EGEE. Several NGIs handle training at the national level and already have a local training CA. Perhaps this would be the best model to follow?

c. SCG strongly recommends that Gilda certificates should not be issued online without appropriate identity vetting of the applicant.

d. The Gilda Portal should meet the requirements of the recently adopted VO Portal Policy.

Update 20/10/2009: request made to Hepix, proposal to change it to SPEC-CPP06
Update 03/11/2009: Hepix did not agree to the change of name

Done. The reports are being produced on a monthly basis since September. - John

Agreement at the SA1 coordination meeting on 009-10-06:
Any site serious about being in the Grid should be able to afford this. If money is a problem for a site then this information should be collected (this is up to the ROCs to do).
We will change the name to make it HEP neutral.

Agreement at the SA1 coordination meeting on 009-10-06:
Any site serious about being in the Grid should be able to afford this. If money is a problem for a site then this information should be collected (this is up to the ROCs to do).
We will change the name to make it HEP neutral.

Update for 2009-06-30 meeting (Maria):
new TPM model updated to reflect the decision of the f2f SA1 mgnt meeting of 2009-06-09.
- More automation will be evaluated later as the number of tickets the TPM gets are only about 35 per week.
Work item on this is savannah #108496
- Role of the central TPM teams should be in the updated OLA.
If 'central TPM teams' refers to 'central coordination tasks', these will be in section 6 of the User Support strategy note.
Central coordination tasks are:
a.continuous training
b.documentation update
c.intervention on tickets being late or misrouted
d.ticket monitoring, analysis and reporting to the relevant project management bodies.

Update for 2009-09-01 meeting (Maria):
The following was sent to USAG, ROC-managers, TPM and VOs' mailing list on 2009-07-09:
"We need the following actions done before our next meeting on 2009-08-27:
* ROCs to bid for the TPM role in the new model
* SA1 management to allow discussion slot at their Sept. 1st meeting in
case we need a plan B,
i.e. if there are not 4 ROCs to do TPM shift according to the new model"
As per mid-August, bids were received from IT and NE.

Update for 2009-10-06 meeting (Maria):
USAG @ EGEE'09 summary: http://indico.cern.ch/materialDisplay.py?materialId=4&confId=68477
SA1 @ EGEE'09 summary: https://savannah.cern.ch/support/?108496#comment5
Yet another step to automation: Allow assignment to the ROC by the submitter: https://savannah.cern.ch/support/?108708#comment5

Update form SA1 coordination meeting in Barcelona:
The decision taken at today’s SA1 coordination meeting about the new EGEE TPM model is to continue with the present rota involving all teams for some time longer, and migrate directly to the NGIs that will be awarded with the associated EGI global task, O-E-7: Triage of Incoming Problems. The estimated timeline is to stay with the present TPM model till the end of the year, and to migrate to the EGI model by the beginning of 2010. This is only a tentative timeline because we don’t know who the awarded NGIs will be, and the transition plan needs to be agreed with them. As soon as this is known, it will be the task of the USAG to work out a feasible transition plan with them and to put it in place.

UPDATE 05/05/09: See discussion in this meeting's minutes.

UPDATE 11/06/09: Discussed at several meetings and at the F2F meeting. This can be closed.

UPDATE 05/05/09: In progress.
This is done in the most recent version, released on 18th September 2009, and available here: https://edms.cern.ch/document/840932

UPDATE 13/01/09: Propose to have next face-to-face SA1 meeting in June at CERN. Can't have it with COD meeting in Finland in June as EGEE review rehearsals and review itself are in June.
Proposing to have it some time during week of 8th – 12th of June at CERN. Maite will send out proposed dates to ROC Managers.

UPDATE 03/02/09: Meeting will be on June 9th at CERN.

UPDATE 19/02/09:

Production grid: 17 nodes --> I propose to close this action and open one for the missing ROCs

* (UK-Ireland)
* RAL
1: 1000.gridpp.rl.ac.uk
1: 2000.gridpp.rl.ac.uk
1: 3000.gridpp.rl.ac.uk
1: 700.gridpp.rl.ac.uk
2: 500.gridpp.rl.ac.uk

* (Russia)
* RU-Protvino-IHEP
3: ce0004.m45.ihep.su

* (Asia Pacific)
* KR-KISTI-GCRT-01
3: ce01.sdfarm.kr

* IN-DAE-VECC-01
3: gridce01.tier2-kol.res.in
3: gridce02.tier2-kol.res.in

* (Central Europe)
* HEPHY-UIBK
3: test-lcgCE.uibk.ac.at

* (France)
* ESRF
4: grid-ce02.esrf.eu

* (South East Europe)
* HG-02-IASA
20: cream-ce01.marie.hellasgrid.gr

* (South West Europe)
* PIC
1: ppsce02.pic.es
1: ppsce03.pic.es
1: ce-test.pic.es

* (Germany-Switrerland)
* FZK-LCG2
48: cream-1-fzk.gridka.de
* GSI
1: grid29.gsi.de

UPDATE 17/02/09:
Mail will be sent (by whom?) to all ROCs to get update. Alexander confirmed that Russia have a CREAM CE (name?) installed.

UPDATE 03/02/09:
Italy update: starting today the installation
APROC update: no response. Last interaction recorded by Antonio: timeline requested on January 20, no reply
SEE update: in Greece, progress but no news, will be ready by next week
Nordic: working according to plan.
Benelux update: working according to plan.
UKI update: Antonio is in contact with the site
SWE:Antonio is in the loop.We are deploying in pre-production, when successful will install it in production.
FR: Nothing changed from last time
CE: scheduled installation, will be ready in 2 weeks
RUSSIA: agreement reached, one site will install it. Will update you later this week on which site and by when it will be installed.

UPDATE 13/01/09: Which ROCs are proposing to install and CREAM CE?
• Italy: Intend to have production instance at tier-1 site within next 2 weeks.
• Asia Pacific: (no response)
• SEE: Planning to install at least one in next couple of weeks.
• Nordic: Will be at least 1 month for KTH. Due to lack of staff.
• Benelux: We plan to install a CREAM CE on febr. 12 and 13.
• UK: 2 being installed but not working yet.
• SWE: Setting one up at PIC now. Other sites waiting for ICE WMS.
• France: Planning to have it in March but site admin is now off sick for 2 months, so unsure.
• CE: No decision which site but decision to be made Monday 19 Jan.
• Russia: (no response)

UPDATE: 5 May 09:
Antonio checked several days ago to see how many CREAM queues are available in prod. 40 for ALICE, 10 for CMS.
Italy: Installed. 1 in prod on Turin
• AP: (not present)
• SEE: (not present)
• SWE: 3 CREAM CEs: 2 in PPS (but published in production), 1 in production (but only supports OPS and dteam VOs)
• France: In progress
• CE: 1 installed
• Russia: 1 installed
• UK/I: at least one installed
• SEE: at least one installed
• Benelux: One at SARA
• NE: not sure

UPDATE: 19 May 09:
Maite will upload the document received by Antonio R. and close this action.

UPDATE 13/01/09: In progress.

UPDATE: 17/02/09: Not needed any more. Gilles announced that confusing “Core” flag will be removed in GOCDB as soon as coordination with CIC portal is done (after Catania).

UPDATE 13/01/09: List isn't ready yet. Will distribute the list before the next meeting.

UPDATE: 17/02/09 Linked to 341 and closed.

UPDATE 13/01/09: The proposal given by Maite will be tried for 3 months and re-evaluated at that point. Also, Maite will include a comment that the ROC of the problematic site can request that the OCC gets involved earlier than stated in the proposed process. All cases of site suspension that require the intervention of the OCC will be reported in the Quarterly Report.

UPDATE 13/01/09: Maite will get an update from Antonio.

UPDATE: 17/01/09: this was discussed at last meeting, together with the post-mortem of releases:
http://indico.cern.ch/getFile.py/access?sessionId=8&resId=1&materialId=0&confId=44167
The action can be closed.

http://indico.cern.ch/conferenceDisplay.py?confId=44163

UPDATE 13/01/09: No further comments were received so it is considered approved.

UPDATE 13/01/09: Nick has been discussing with various interested groups. He will send out a list of the middleware clients that SA1 should support. The list can then be modified as required.

UPDATE 03/02/09: Nick will send the related document to the ROC managers list asap

UPDATE 17/02/09: Nick will send the related document to the ROC managers list ASAP

UPDATE 05/05/09: Done several weeks ago. Close.

UPDATE 13/01/09: In progress. Note deadline is End Of Jan! Would be very useful to have this in time for All Activities meeting - please can all ROCs get this information to Maite several days before the All Activities meeting if at all possible.

UPDATE 03/02/09: some progress, but nothing ready yet. Maite asked for a draft to be sent the ROC managers as soon as possible.

UPDATE 17/02/09: Maite will evaluate document and distribute it.

UPDATE 05/05/09: Draft has now got comments from RAG. Close to version for ROC managers to review.

UPDATE 19/05/09: New requirement to be added:
- A check in the metrics on the number of jobs and CPU usage outside seed resources (if any)
- To measure whether the VOs in a period of more than 6 months do start using the production infrastructure and/or bring their own resources.

UPDATE 03/02/2009:
CE: done; SEE: done it; France: we have nobody assigned to it, and have no effort for it currently as we have staffing problems; UK: one site has a local instance, we are looking into deployment it for the ROC; Italy: installation is difficult; DECH: we tried to install it, but we have a problem. We cannot complete the configuration with YAIM.

UPDATE 17/02/09:
Steve will provide a status. Kai confirmed that SWE have a regional Nagios. Shu-Ting said AP also have one. Cyril: France will also have one (for dashboard testing).

UPDATE 18/05/2009:
From Wen Mei (ROC_DECH): We have ROC NAGIOS installed, upgrade to the latest version. The Yaim configuration is able to completed and the Nagios based ROC DECH monitoring is running. All the sites and VOs are monitored. We are checking all the available services found by the Nagios probes. We had problem to create and retrieve Myproxy credential and the problem has been fixed now.

This can be closed. to be continued through the OAT.

UPDATE 17/02/09:
* Not all are on the OAT discussion list. James said “we’re still debating” (about GOCDB vs Information System). The IS approach is a good idea, but might be too late. We need estimations on how much effort would each option cost, and who would do it (not clear in the IS case)

UPDATE 5/5/09:
* Technical discussions at OAT F2F week between Gilles + Laurence. Have worked out the similarities between GOCDB and GLUE information models. Work is now on BDII side to expose the information that could be merged into the GOCDB. From Gilles :

 Any info to insert in a regional GOCDB   
will then be inserted from a defined XML format, no matter whether it   
comes from a web interface, another GOCDB, an external tool or a   
siteBDII.   
Potentially the only work needed to move towards a solution where sites   
publish their endpoints or downtimes in their sBDII would be on your   
side... in the sense that it would require:   
- a separated branch for storing this info in Glue at Site level   
- a publisher that formats this info into the defined XML expected by   
GOCDB   

UPDATE 11/06/09: no further feedback received. The action can be closed.

UPDATE 17/02/09:
* Antonio to send a file. Related to 344 and should be closed

UPDATE 17/02/09:
Collapse into previous one (373).

UPDATE 03/02/2009: the schedule for Helene will be available in a document which will be available
in the next two weeks.

UPDATE 17/02/09: DECH & Russia input still missing (but may be in back-log of Helene's mails).

UPDATE 05/05/09: Entry date of last 4 ROCis June 15. They need to give feedback by 11 May. Close.

UPDATE 03/02/2009: we are ready, but we need the possibility to have some special implementation
for our ROC, for instance to have per country view. We need to discuss the implementation details with Helene.