Grid Security in EGEE/LCG ISGC 2005, Taipei, Taiwan 29 April 2005 David Kelsey CCLRC/RAL, UK

29-Apr-05David Kelsey, Grid Security, ISGC 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!

29-Apr-05David Kelsey, Grid Security, ISGC Outline These slides are available at 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

29-Apr-05David Kelsey, Grid Security, ISGC 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

Enabling Grids for E-sciencE INFSO-RI David Kelsey, Grid Security, ISGC 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.

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

29-Apr-05David Kelsey, Grid Security, ISGC 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”

Enabling Grids for E-sciencE INFSO-RI David Kelsey, Grid Security, ISGC 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

Enabling Grids for E-sciencE INFSO-RI David Kelsey, Grid Security, ISGC 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

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

29-Apr-05David Kelsey, Grid Security, ISGC Authentication

29-Apr-05David Kelsey, Grid Security, ISGC 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

29-Apr-05David Kelsey, Grid Security, ISGC 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)

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

29-Apr-05David Kelsey, Grid Security, ISGC 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

29-Apr-05David Kelsey, Grid Security, ISGC 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

29-Apr-05David Kelsey, Grid Security, ISGC Security Policy

29-Apr-05David Kelsey, Grid Security, ISGC 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

29-Apr-05David Kelsey, Grid Security, ISGC EGEE/LCG Security Policy (2) Security & Availability Policy User AUP Certification Authorities Audit Requirements Incident Response User Registration & VO Management Application Development & Network Admin Guide picture from Ian Neilson VO AUP Under Revision

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

EGEE3 Athens 21 April 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

EGEE Athens 21 Apr Operational Security Coordination Security Service Challenges Objectives ( 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

EGEE Athens 21 Apr Future Plans

29-Apr-05David Kelsey, Grid Security, ISGC 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

29-Apr-05David Kelsey, Grid Security, ISGC 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 EGEE Site Access Control Architecture

29-Apr-05David Kelsey, Grid Security, ISGC 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

29-Apr-05David Kelsey, Grid Security, ISGC 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

29-Apr-05David Kelsey, Grid Security, ISGC References LCG/EGEE Joint Security Policy Group EGEE JRA3 (Security) Open Science Grid Security EU DataGrid Security LCG Guide to Application, Middleware and Network Security EU Grid PMA (CA coordination) TERENA Tacar (CA repository)

29-Apr-05David Kelsey, Grid Security, ISGC 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?