EGEE Security Coordination Group meeting. 22 Oct 2009 - phone conference. Present: Linda Cornwall, David Groep, Romain Wartel, Dave Kelsey. Apologies: Steven Newhouse, John White, Christoph Witzig. 1. Roundtable reports a. GSVG (Linda) GSVG Issue handling continues. There have been 8 new issues reported since the last SCG meeting at the end of August. EGI and Risk assessment issues will be discussed later in this meeting. Linda mentioned some recently reported problems of lack of appropriate server validation during authentication. She will follow up on this. b. EUGridPMA/IGTF (David G) - a new IGTF distribution (1.32) is scheduled for October 26th. The derived EGEE (and LCG) distribution 1.32 is the last one that will carry the exceptional FNAL_KCA CA. Also: some obsoleted CAs (7 in total) will be withdrawn, which may alleviate the occurance of the infamous Apache mod_ssl bug 46952 (see https://issues.apache.org/bugzilla/show_bug.cgi?id=46952) Following the IGTF all-hands meeting, a couple of documents were provisionally approved and some new concepts added. Although it will take a bit of time to consolidate the new consensus into the document stack and the Authentication Profiles, this is what you may expect early 2010: - the requirement for all CAs that 'the user is the only one that is allowed to generate and store a private key' is being replaced by requirements better representing current practice, aiming to both improve security of private key storage as well as make handling of private keys easier. In particular, the new "Guideline on Private Key Protection" will allow: * generation and storage of private keys on shared file systems and remote user interface systems (codifying current practice) * generation and storage of private keys *for end users* on well secured and managed portals, without the user ever having to hold the private key * enabling (national?) Credential Stores and national MyProxy Services run for many users and no behalf of many portals, subject to some specific security restrictions. * the guideline also foresees that the *home organisation* of a user could pre-generate key pairs in a trusted service on behalf of its users, contingent on certain policy restrictions. In principle, this would allow the pre-provisioning of key pairs for users in, e.g., AD. This last option may trigger some discussion, although in practice it follows from generation and storage of user key pairs on shared systems in a user's home organisation (it carries the same risk analysis). When endorsed by the IGTF and once implemented, this could address many of the usability issues seen for 'true' end users. Personally, I see a role here for NGIs to run national, trusted MyProxy stores and credential repositories, a bit like HellasGrid is doing for its internal CAs at the moment. The formal text of the PKP Guideline is at: https://www.eugridpma.org/guidelines/pkp/ - although not yet agreed, it seems that the use of secure hardware tokens to protect key pairs pertaining to "Robot" certificates does not fundamentally improve security over having software tokens, if the hardware tokens remains activated for longer time periods and if the relying parties accept 'proxy' certificates for delegation. Since in practice grid accept proxies, and portals (where the Robot certificates are used) keep the hardware token activated continuously, they may not bring the factual security benefits often ascribed to hardware tokens. Different groups in the IGTF will now proceed with a more in-depth analysis of the security issues. It is likely but not certain that future versions of the Guideline on Robots may relax the requirement to use hardware tokens. The latest version of the draft Guideline for Robots can be found at https://grid.ie/eugridpma/wiki/GuidelineOnRobots c. OSCT (Romain) OSCT has been busy chasing sites to apply kernel patches to fix the recently announced root exploits. Given that this was taking too long and with the strong support of the EGEE and WLCG management boards, strict deadlines were set by which sites had to be fully patched. This has been very successful and the infrastructure is no longer affected by these vulnerabilities. To achieve this, 4 sites were either closed or were suspended. This has been a painful process but it has been worth all the effort. This needs to be more streamlined in future. Romain reported that they are now thinking about introducing their monitoring tool as a day-to- day operations tool. They worked really hard on incident response (new procedures, training, security drills, etc.) during EGEE-III and he thinks improving the sites patching status/timing would be another big step forward to prevent security incidents. Most incidents over the past years propagated through known (but unpatched) security vulnerabilities. d. JSPG (Dave) A face to face JSPG meeting was held in Berlin (16/17 Sep) http://indico.cern.ch/conferenceDisplay.py?confId=63007 The main agenda item was the new draft security policy framework, to be used as we move forward to EGI. I gave a presentation on this at EGEE'09: http://indico.cern.ch/contributionDisplay.py?contribId=292&sessionId=7&confId=55893 We are also revising the Grid User AUP (to make it more usable for other infrastructures, such as DEISA) and the Site Registration Security Policy. The next JSPG F2F meeting will be held at CERN (7/8 December) concentrating on the new framework and the JSPG EGEE-III milestone MSA1.11. Dave has also attended the EUGridPMA meeting (Sep) and OGF27/TAGPMA/IGTF All Hands (Oct). 2. Gilda (training) security issues 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. 3. Security Risk Assessment Linda has produced a first list of risks and brief document describing the strategy. This was updated after discussion with JSPG in September. The only people who have so far expressed an interest in participating (apart from Linda) are Dorine Fouossong, Ake Sandgren and Dave Kelsey. Should we try and progress with just 4 people? (Note 75 threats - each member would need to check up on the situation with 19, 4 opinions is not many.) There was a suggestion for having a 1 day meeting at CERN on 9th December following JSPG - but no-one from CERN or JSPG (except Dave) has expressed an interest. (Only person said they would participate is Dorine). This face to face meeting will therefore not take place. SCG agreed that we need to identify a larger group of volunteers to help with this work. Linda will contact the various groups again and also send invitations out to Site Security contacts. The first phase of the work will be to check that the list of identified risks is complete. Dave points out that there is an SCG deliverable, DJRA1.2 - Report on EGEE-III Security, which is supposed to review progress in operational security as well as middleware. This deliverable, due in Feb 2010, would be a good place to report on this new Security Risk Assessment. 4. EGI proposal status Dave reported on the current status of the EGI proposal work. The Security Policy Group (ex JSPG) and the Software Security Group (replacing MWSG) are both included in NA2 and the groups replacing OSCT and GSVG are in SA1. Linda reported that she had produced draft input related to handling of vulnerabilities in the Service Level Description for Software Providers as requested by Steven Newhouse. She has suggested 9 points that the software providers should agree to. She distributed it to the RAT and SCG and has so far received no comments. She is not sure exactly what is needed. Is it about now she should do a summary description of issue handling - i.e. a first cut for revision so that potential participants know what they are agreeing to? If so, is there an EGI template yet? 5. AOB None. 6. Date of next SCG meeting Dave will set up a Doodel poll for an SCG meeting in November. Notes by Dave Kelsey (29 Oct 09)