Security EGEE/SA1 ROC Managers ARM-3 meeting Lyon, 17 March 2005

1. SecurityEGEE/SA1 ROC Managers ARM-3 meetingLyon, 17 March 2005 David KelseyCCLRC/RAL, UKd.p.kelsey@rl.ac.uk

2. Aims • Status report on JSPG activities • and work with Open Science Grid (OSG) • Security Service Challenges • JRA3 deliverables • Authentication: CA PMAs • Security Best Practice/Guides • US HEP Cybersecurity workshop • GridPP work on Vulnerability analysis • Hopefully time for discussion! David Kelsey, Security, ARM-3

3. Who does what? • EGEE JRA3 • Responsible for EGEE Security • EGEE Middleware Security Group • JRA3, JRA1, SA1, NA4, Other projects • See JRA3 agenda page • LCG/EGEE Joint Security Policy Group (JSPG) • Reports to LCG GDB and EGEE ROC Managers • Cross participation with USA OSG • EGEE Operational Security Coord Team (OCST) • Led by Ian Neilson (CERN) – Security Officer • All ROCs have a representative • Mail list exists (and used sometimes) • But not yet met David Kelsey, Security, ARM-3

4. JSPG Policy/Procedures • Site Registration • Acceptable Use Policy (AUP) • For Users • For Sites (not today) • VO Security Policy • LHC Experiment User Registration (not today) • Security Incident Response • Have removed the 3 obsolete GOC “guides” • SLA, Self Audit, Resource Managers • Future work David Kelsey, Security, ARM-3

5. Site Registration • Site Registration document (Maria Dimou) • Approved by GDB (yesterday) • https://edms.cern.ch/document/503198/ • Discussed with ROC Managers many times • Many thanks for valuable input/comments • Final change was to remove all references to • Dispute escalation/resolution • Removal of sites (suspend or de-register) David Kelsey, Security, ARM-3

6. AUP (Users) • Similar policy to OpenScienceGrid (these are their words) • Keep it short and simple (users may read) • (1) You may only perform work and store data consistent with the charters of the organizations of which you are a member, and only on resources authorized for use by those organizations. • (2) You will not attempt to circumvent administrative and security controls on the use of resources. If you are informed that some aspect of your grid usage is creating a problem, you will adjust your usage and investigate ways to resolve the complaint. You will immediately report any suspected compromise of your grid credentials (security@opensciencegrid.org) or suspected misuse of grid resources (abuse@opensciencegrid.org). • (3) Resource providers have the right to regulate access as they deem necessary for either operational or security-related reasons. David Kelsey, Security, ARM-3

7. VO Security Policy • Draft document distributed this week (Ian N) • https://edms.cern.ch/document/573348/ • VO Registration Requirements • Information that must be captured/maintained • VO Membership Policy • Clearly states the goals of the VO • Requires all members to act within constraints • Allows sites to decide whether to accept the VO • VO Community Responsibilities • Users and VO managers • VO membership rights • Use of resources • Privacy David Kelsey, Security, ARM-3

8. Security Incident Response • Current policy/procedures • https://edms.cern.ch/document/428035/ • Near future • Aim for common approach with OSG • With minimal changes • This was presented in EGEE-2 (Den Haag) • The OSG document is at • http://computing.fnal.gov/cgi-bin/docdb/osg_public/ShowDocument?docid=19&version=2 David Kelsey, Security, ARM-3

9. JSPG future work • Complete VO Security Policy document • New top-level Policy document • More general • To apply to EGEE and LCG (and others?) • Revise all other sub-documents • Again more general • Bring up to date • Then seek approval by EGEE and LCG management • Revise/Update the Security Risk Analysis • And work on risk management/mitigation • Continue to lobby for better security David Kelsey, Security, ARM-3

10. Security Service Challenges • OSG recently tested their communication channels • Emergency reporting list • Discuss list • Highlighted several problems – but it worked! • EGEE • OSCT will organise and do first test • Test audit trails • Logs exist, contain enough info, can be analysed • All in timely manner • Planning to have first try in March/April • Before the EGEE-3 meeting (Athens) David Kelsey, Security, ARM-3

11. JRA3 deliverables • MJRA3.6 - Security Operational Procedures (first revision) • https://edms.cern.ch/document/566174/ • Author: Yuri Demchenko • 3 sections • Operational Procedure Documents • Vulnerability Analysis & Incident Definition • IODEF for incident reporting • MJRA3.7 – EUGridPMA Accreditation Procedure • https://edms.cern.ch/document/565290/ • Author: David Groep • Comments to authors please David Kelsey, Security, ARM-3

12. CA PMAs • EU Grid PMA: http://www.eugridpma.org • Met in Marseille at end of Jan 2005 • Next meeting in Estonia – end of May • Several new CAs discussed/approved • The Americas PMA (TAGPMA): http://www.tagpma.org/ • Now exists • Working on requirements for online CAs • This week in GGF (Seoul) • International Grid Federation (IGF) meets • http://www.gridpma.org/ • Asia/Pacific, TAG and EU PMAs • OSG has formally requested the PMAs to accredit CAs for use in OSG (and specified some requirements) • EGEE should do same? • And revise our own CA Acceptance policy document David Kelsey, Security, ARM-3

13. Security Best Practice • Work started by some members of OSCT • Following Nov 2004 Operations Workshop • Alessandra Forti (Manchester, UK) • Romain Wartel (UK/I ROC) • Miguel Cardenas Montes (Ciemat, ES) • Ian Neilson (CERN) • Contents: • Forensic analysis • Some early draft web pages (mainly structure) exist • for now on GridPP deployment web • http://www.gridpp.ac.uk/deployment/security/index.html • But also aimed at EGEE/LCG David Kelsey, Security, ARM-3

14. US Cybersecurity workshop • LBNL (Oakland), 9-10 March 2005 • http://hpcrd.lbl.gov/HEPCybersecurity/ • ~30 participants • Denise Heagerty and DPK represented CERN/EU/LCG • Goal: to produce a work-plan for Grid Deployment to ensure US LHC Computing will be as secure as possible in 2007 • No time to report here in detail • Important issues • Risk Analysis, Management and Mitigation • Big concers about use of LCG for external DOS attacks • Must have good monitoring, auditing, incident response • Must be able to regain control quickly after an incident • Proposal/Work Plan now being developed David Kelsey, Security, ARM-3

15. Vulnerability Analysis • GridPP work (Linda Cornwall/RAL) • Was also a report in the US workshop • Vulnerability analysis of Condor being done • Design and code reviews • Draft GridPP document exists (Linda) • “Vulnerability – detection and reduction” • See recent EGEE MWSG meeting • http://agenda.cern.ch/fullAgenda.php?ida=a051137 • 3 activities • Checklists (deployment and middleware) • Vulnerability logging and tracking • Anti-use cases David Kelsey, Security, ARM-3

16. Vulnerability (2) • Aim to review gLite (V1) and LCG (v2.4) • Goal is to improve middleware and deployment • How/where to report problems? • JSPG encourages reporting of security holes • UK sites keen to go “public” • But problems of public/archived mail lists • We have a responsibility to our colleagues/projects • JSPG investigating secure area in GGUS • But unlikely to be available this year • Create our own database? • In the meantime please report to Linda Cornwall • Linda.Cornwall@rl.ac.uk • She is starting to gather info David Kelsey, Security, ARM-3

17. Discussion? David Kelsey, Security, ARM-3