1. Grid Security in EGEE/LCG ISGC 2005, Taipei, Taiwan 29 April 2005 David Kelsey CCLRC/RAL, UK d.p.kelsey@rl.ac.uk

2. 29-Apr-05David Kelsey, Grid Security, ISGC 20052 Introduction The Grid aim –Easy and open sharing of resources However –Highly distributed resources and communities –Independent administrative domains The Internet today –An ever-increasingly hostile environment –Growing need for firewalls and other controls Therefore need to convince –Computer Centres to allow Grid services –Developers & Users to take security seriously Grid functionality versus Security –A major challenge!

3. 29-Apr-05David Kelsey, Grid Security, ISGC 20053 Outline These slides are available at http://hepwww.rl.ac.uk/kelsey/kelsey29apr05.ppt Security requirements –Security groups & requirements in EGEE The Grid Security model Authentication Authorization & VO Management Security Policy & Procedures Operational Security –Security Service Challenges Future plans Final words

4. 29-Apr-05David Kelsey, Grid Security, ISGC 20054 Security Requirements Users require –Open/easy access to cpu and data –Single Registration (once per VO) –Single Sign-On (login once per session) –Not to be bothered by security! But they do need Availability and Data Integrity Computer Centres/Security Officers require –Full local control of access to their resources –Knowledge of User details –Ability to audit (Who? What? When?) –Secure middleware, applications and services –Not to be bothered by security incidents

5. Enabling Grids for E-sciencE INFSO-RI-508833 David Kelsey, Grid Security, ISGC 2005 5 JRA3JRA1 NA4 Middleware Security Group Joint Security Policy Group NA4 Solutions/Recommendations Req. SA1 “Joint Security Policy Group” defines policy and procedures and inputs requirements to MWSG (For LCG/GDB and EGEE/SA1) (Cross Membership of US OSG Sec Team) CA Coordination Security Middleware Applications Operations OSG LCG OSCT Security requirements - Understanding how input from applications, sites and operations are handled.

6. 29-Apr-05David Kelsey, Grid Security, ISGC 20056 The Security Model

7. 29-Apr-05David Kelsey, Grid Security, ISGC 20057 The Security Model Authentication – proof of identity –GSI: Globus Grid Security Infrastructure (interoperate) –Single sign-on via X.509 certificates (PKI) –Delegation (via short-lived proxy certs) to services Global Authorization – right to access resources –Virtual Organisation (VO) – e.g. a Biomed experiment Maintains list of registered users Allocates users to groups and/or roles Controls global policy and allocations Local Authorization – site access control –Via local (e.g. Unix) mechanisms or –Callouts to local AuthZ enforcement (Grid developments) –Grid ACL’s - global identity or VO AuthZ attributes Policy –Grids (e.g. EGEE, OSG) define security policy –Many stakeholders also contribute to “policy”

8. Enabling Grids for E-sciencE INFSO-RI-508833 David Kelsey, Grid Security, ISGC 2005 8 Security Baseline assumptions Be Modular and Agnostic –Allow for new functionality to be included as an afterthought –Don’t settle on particular technologies needlessly Be Standard –Interoperate (GGF, WS-I, OSG, …) –Don’t roll our own, to the extent possible Be Distributed and Scalable –“Central services are evil” –Always retain local control Slide from Olle Mulmo – EGEE-3 Athens 19 April 2005

9. Enabling Grids for E-sciencE INFSO-RI-508833 David Kelsey, Grid Security, ISGC 2005 9 Baseline assumptions VOs self-govern the resources made available to them –Yet try to minimize VO management! –Use AuthN to tie policy to individuals/resources An open-ended system –No central point of control –Can’t tell where the Grid ends Best-effort solutions –rather than “appropriate” solutions Slide from Olle Mulmo – EGEE-3 Athens 19 April 2005

10. 29-Apr-05David Kelsey, Grid Security, ISGC 200510 Security Policy Graphics from Globus Alliance & GGF OGSA-WG Policy comes from many stakeholders

11. 29-Apr-05David Kelsey, Grid Security, ISGC 200511 Authentication

12. 29-Apr-05David Kelsey, Grid Security, ISGC 200512 Authentication Keep Authentication and Authorization separate –Authentication best done at Institute level –Authorization best done at VO level Provide the User with one (Grid) electronic identity –For use in many Grid projects or VOs –For user convenience Have successfully built a global PKI (X.509) –Mutual Authentication of people and services What is the most appropriate scale? –One CA per country/region (ideally for all eScience) EU Grid PMA has coordinated the (global) CA’s –“minimum requirements” for accredited CA’s Now three worldwide PMA’s for Authentication –Asia/Pacific, The Americas and EU –International Grid Federation coordinates these Federation agreement aimed for GGF in June 2005

13. 29-Apr-05David Kelsey, Grid Security, ISGC 200513 EU Grid PMA CAs Other Accredited CAs:  DoEGrids (USA)  GridCanada  ASCCG (Taiwan)  ArmeSFO (Armenia)  Russia  Israel  Pakistan “Catch-all” CAs operated by CNRS (for EGEE) US DoE (for LCG) SEE-GRID (for SE Europe) Austria Belgium CERN Cyprus Czech Republic Estonia France Germany Greece Hungary Ireland Italy Nordic countries Poland Portugal Slovakia Slovenia Spain Switzerland The Netherlands UK Under consideration Baltic Grid Bulgaria China – IHEP TERENA TACAR repository (for root certificates)

14. 29-Apr-05David Kelsey, Grid Security, ISGC 200514 Authorization and VO Management

15. 29-Apr-05David Kelsey, Grid Security, ISGC 200515 Authorization & VO Management In EGEE gLite Release 1 Global AuthZ (VOMS) –Virtual Organization Membership Service VO members, their groups and roles Provides digitally signed AuthZ “attributes” –Included in the grid proxy certificate Local AuthZ –Local Centre Authorization Service (LCAS) A framework to handle local policy (e.g. banned users) –Local Credential Mapping (LCMAPS) Provides local credentials (Kerberos/AFS, ldap nss…) Local policy decisions (CE and SE) –Can decide and enforce policy on VOMS attributes n.b. LCAS/LCMAPS is just one local AuthZ service

16. 29-Apr-05David Kelsey, Grid Security, ISGC 200516 AuthZ – VOMS & LCAS VO-VOMS user service authentication & authorization info user cert (long life ) VO-VOMS CA low frequency high frequency host cert (long life ) authz cert (short life) service cert (short life) authz cert (short life) proxy cert (short life) voms-proxy-init crl update registration LCAS

17. 29-Apr-05David Kelsey, Grid Security, ISGC 200517 Security Policy

18. 29-Apr-05David Kelsey, Grid Security, ISGC 200518 EGEE/LCG Security Policy During 2003/04, the LCG project agreed a first version of its Security Policy –Written by the Joint Security Policy Group –Approved by the Grid Deployment Board A single common policy for the whole project –But does not override local policies An important step forward for a production Grid The policy –Defines Attitude of the project towards security and availability –Gives Authority for defined actions –Puts Responsibilities on individuals and bodies Now being used by EGEE and (some) national Grids

19. 29-Apr-05David Kelsey, Grid Security, ISGC 200519 EGEE/LCG Security Policy (2) Security & Availability Policy User AUP Certification Authorities Audit Requirements Incident Response User Registration & VO Management http://cern.ch/proj-lcg-security/documents.html Application Development & Network Admin Guide picture from Ian Neilson VO AUP Under Revision

20. 29-Apr-05David Kelsey, Grid Security, ISGC 200520 Operational Security and Security Service Challenges

21. EGEE3 Athens 21 April 2005 - 21 Operational Security After LCG Workshop and EGEE2 Practical information for sys admins System monitoring tools Incident response Security Service Challenge EGEE Operational Security Coordination Team Slide from Ian Neilson – EGEE-3 Athens 19 April 2005

22. EGEE Athens 21 Apr 2005 - 22 Operational Security Coordination Security Service Challenges Objectives (https://edms.cern.ch/document/478367)https://edms.cern.ch/document/478367 a) Evaluate the effectiveness of current procedures by simulating a small and well defined set of security incidents. b) Use the experiences of a) in an iterative fashion (during the challenges) to update procedures. c) Formalise the understanding gained in a) & b) in updated incident response procedures. d) Provide feedback to middleware development and testing activities to inform the process of building security test components. Slide from Pal Anderssen – EGEE-3 Athens 21 April 2005

23. EGEE Athens 21 Apr 2005 - 23 Future Plans

24. 29-Apr-05David Kelsey, Grid Security, ISGC 200524 Future plans Authentication Many concerns about user-managed credentials –Too complex and too insecure Several solutions to be considered –Smart Cards –Credential Repositories (e.g. MyProxy) Long-term credentials never held by user –Site Integrated Proxy Services (SIPS) e.g. Kerberos CA Better certificate revocation technologies –E.g. OCSP

25. 29-Apr-05David Kelsey, Grid Security, ISGC 200525 Future plans (2) Other foreseen EGEE security developments include Logging and Auditing Authorization –Local policy decisions and enforcement –Standards based (OGSA-AuthZ) Delegation Data Key management –privacy & confidentiality Isolation and Sandboxing Dynamic Connectivity (Site Proxy) See EGEE Global Security Architecture https://edms.cern.ch/document/487004/ EGEE Site Access Control Architecture https://edms.cern.ch/document/523948/

26. 29-Apr-05David Kelsey, Grid Security, ISGC 200526 Future plans (3) Security Policy and Procedures Joint Security Policy Group –With OSG –Revise all security policy documents Aim to make more general (wherever possible) –e.g. by working on joint documents –Today, too LCG-specific Currently working on User AUP and VO AUP –See Bob Cowles’ talk Security Vulnerability Detection and Reduction Look for and record known problems –Middleware and Deployment –And encourage speedy fixes Work started in UK GridPP Now collaborating with EGEE JRA3

27. 29-Apr-05David Kelsey, Grid Security, ISGC 200527 Future plans (4) Operational Security In Europe, EGEE OSCT will continue the work recently started Incident Response –see Bob Cowles’ talk on OSG work –EGEE using same approach Perform Security Service Challenges Security Monitoring Forensic Analysis Best practice guides

28. 29-Apr-05David Kelsey, Grid Security, ISGC 200528 References LCG/EGEE Joint Security Policy Group http://proj-lcg-security.web.cern.ch/ EGEE JRA3 (Security) http://egee-jra3.web.cern.ch/ http://egee-jra3.web.cern.ch/ Open Science Grid Security http://www.opensciencegrid.org/techgroups/security/ http://www.opensciencegrid.org/techgroups/security/ EU DataGrid Security http://hep-project-grid-scg.web.cern.ch/ http://hep-project-grid-scg.web.cern.ch/ LCG Guide to Application, Middleware and Network Security https://edms.cern.ch/document/452128 https://edms.cern.ch/document/452128 EU Grid PMA (CA coordination) http://www.eugridpma.org/ http://www.eugridpma.org/ TERENA Tacar (CA repository) http://www.terena.nl/tech/task-forces/tf-aace/tacar/ http://www.terena.nl/tech/task-forces/tf-aace/tacar/

29. 29-Apr-05David Kelsey, Grid Security, ISGC 200529 Final Words Much has been achieved over recent years –Authentication –Authorization –Policy and Procedures –Operational Security “Keep Security Simple” – or deployers & users will turn it off But Grid middleware is less mature than Operating Systems –and see the many security patches for OS’s Security incidents will happen –Well defined/agreed response procedures are essential –Grid services/middleware will need frequent security patches Perhaps this will be the first sign of maturity?