Grid Security in WLCG & EGEE HEPiX, JLAB 12 Oct 2006

1. Grid Security in WLCG & EGEEHEPiX, JLAB12 Oct 2006 David KelseyCCLRC/RAL, UKd.p.kelsey@rl.ac.uk

2. Introduction • Last update to HEPiX was in October 2004 (BNL) • I gave my first talk on Grid Security here (Nov 2000) • Appropriate to present current status • Outline of talk • The Grid Security Model • Authentication and IGTF • Authorization and VO Management • Policies and procedures (JSPG) • Operational Security Coordination team • Grid Security Vulnerabilities Group • Integration and AAI Federations • Interoperability • Final words David Kelsey, Grid Security, HEPiX, JLAB

3. Grid Security Model David Kelsey, Grid Security, HEPiX, JLAB

4. Grid/VO/Site Model • Users have a single electronic identity • They register once per VO (and renew) • Can/do belong to more than one VO • do not register at sites or Grids • VOs register with Grid (again once per Grid) • Aim for single instance of VO membership database • To be used across multiple Grids • Sites can/do provide resources to multiple Grids • Sites decide which VOs to support • Distributed Grid Operations facilitates this • Deployment, configuration etc David Kelsey, Grid Security, HEPiX, JLAB

5. The Grid Security Model • Authentication – proof of identity • GSI: Globus Grid Security Infrastructure (interoperate) • Single sign-on via X.509 certificates (PKI, OpenSSL) • Delegation (via short-lived proxy certs) to services • Global Authorization – right to access resources • Virtual Organisation (VO) – e.g. an HEP experiment • Maintains list of registered users • Allocates users to groups and 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 David Kelsey, Grid Security, HEPiX, JLAB

6. Authentication and IGTF David Kelsey, Grid Security, HEPiX, JLAB

7. IGTF • International Grid Trust Federation • Formed in October 2005 • Federate to solve scaling problems • Coordinates the three regional Policy Management Authorities (PMA) • EU Grid PMA • Asia/Pacific Grid PMA • The Americas Grid PMA • Each PMA • Accredits Identity Providers for Grid Authentication • Owns and maintains various authentication profiles • Coordinates the X.509 namespace • Distributes roots of trust (globally) • Members are the CAs and major relying parties David Kelsey, Grid Security, HEPiX, JLAB

8. IGTF (2) • Authentication Profiles • Classic PKI • long-lived (12 months) certificates • held by the end entities • Medium assurance level • Photo-ID and face-to-face User <-> RA • CRLs issued • SLCS (recent addition) • short-lived certificate services • Certificates automatically generated • From local site authentication services (e.g. Kerberos) • No CRLs • Experimental CAs • Working towards an OCSP definition and service • With CAOPS-WG in OGF • TACAR is an important independent source of roots of trust • TERENA Academic CA repository David Kelsey, Grid Security, HEPiX, JLAB

9. IGTF(3) APGridPMA TAGPMA • common, global best practices for trust establishment • better manageability and response of the PMAs Slide from David Groep David Kelsey, Grid Security, HEPiX, JLAB

10. IGTF (4) • More than 50 countries/regions worldwide are members • Europe is well covered • “Catch-all” CA for gaps David Kelsey, Grid Security, HEPiX, JLAB

11. Authorization and VO Management David Kelsey, Grid Security, HEPiX, JLAB

12. AuthZ • In EGEE gLite middleware • Global AuthZ (VOMS) • Virtual Organization Membership Service • VO members, their groups and roles • Provides digitally signed AuthZ attribute certificate • Included in the grid proxy certificate • A “PUSH” model (user can select roles and VOs) • 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 (Compute and Storage Elements) • Can decide and enforce policy on VOMS attributes David Kelsey, Grid Security, HEPiX, JLAB

13. VO Groups and Roles • Each VO (Manager) assigns its members to groups and roles • Groups • Collections of individuals with something in common • E.g. group of scientists working on a particular topic • Used for access control and quotas/priorities • Roles • Capabilities/Privileges assigned to individuals or groups • e.g. production processing manager, DBA, … • We started to explore common role names • Some agreement possible but its close to impossible! • Too many VO’s and differences • At very least, names and semantics must be well understood within a VO context David Kelsey, Grid Security, HEPiX, JLAB

14. User Registration • For LHC experiments use VOMRS • Developed at FNAL • Links to CERN HR database • No duplication of personal information • User must register with Expt before joining VO • Process includes proof of mailbox ownership • Regular renewal (every 12 months) required • User warned in advance • The old LDAP based directories will be removed • by end of 2006 David Kelsey, Grid Security, HEPiX, JLAB

15. Policy and procedures David Kelsey, Grid Security, HEPiX, JLAB

16. Interoperable Policies • Aim to allow applications (VO’s) to easily use resources in multiple Grids • The simplest approach • Common Policies • User AUP • Site AUP • VO AUP • Operational procedures and other policies • If not common then at least not conflicting • Does NOT override local site and network security policy • JSPG includes other EU Grid projects and OSG • Common policies and procedures David Kelsey, Grid Security, HEPiX, JLAB

17. JSPG Security Policy picture from Ian Neilson Incident Response Certification Authorities Audit Requirements Site & VO Policies Security Policy Grid & VO AUPs Application Development & Network Admin Guide User Registration & VO Management David Kelsey, Grid Security, HEPiX, JLAB

18. Current policy The core set • Security and Availability Policy for LCG • V4c, 17 Oct 2003 • needs update • Grid Acceptable Use Policy • V3.1, 28 Oct 2005 • LCG/EGEE Virtual Organisation Security Policy • V1.7, 31 Oct 2005 Sub-policy documents • Approval of Certification Authorities • V2.5, 3 July 2006 • Audit Requirements for LCG-1 • V1.2, 19 June 2003 • needs update David Kelsey, Grid Security, HEPiX, JLAB

19. Current Policy (2) Sub-policy documents (continued) • Requirements for LCG User Registration and VO Membership Management • V2.7, 1 June 2004 • Guide to LCG Application, Middleware & Network Security • V1.6, 19 July 2004 • Site Registration Policy & Procedure • V2.0, 16 Mar 2005 • LCG/EGEE Incident Handling and Response Guide • V2.1, 15 June 2005 David Kelsey, Grid Security, HEPiX, JLAB

20. Recent JSPG work • Recently (last 12 months) approved documents • Grid AUP • VO Security Policy (this requires a VO AUP) • CA Approval (using IGTF accredited CA’s) • Current work • Top-level Security Policy document (revision) • Defines roles and responsibilities, sanctions etc • Site Operational Procedures Policy (new) • User-level Accounting data privacy issues • VO Naming (use DNS style) • revision of VO Security policy • All new documents are aimed to be simple and general, e.g. apply to “Grid” not “EGEE” (like the Grid AUP) David Kelsey, Grid Security, HEPiX, JLAB

21. JSPG future work • VO AUP • OSG working on this • EGEE should adopt this approach • Requires VO’s to accept responsibility… Will this work? • Minimum requirements for VO membership services • JSPG agreed this would be very useful (work not started) • Work with OSG on general Service AUP • Risk Analysis and Security Plan • OSG have done lots of good work in this area • EGEE long term strategy to do something similar • Security emergency plans • Define communication & decision processes (started) David Kelsey, Grid Security, HEPiX, JLAB

22. Operational Security Coordination Team (slides from Ian Neilson) David Kelsey, Grid Security, HEPiX, JLAB

23. What the OSCT does? • EGEE-II has a ROC-centric support model • Operational support • Tickets raised from several sources (may result in Incident) • ROC-on-duty process (SFT/SAM) • GGUS Ticket Process Management (TPM) (User/VO) • Incident Support • Incident Handling Guide • CSIRTS and CONTACTS lists • Representation of Operations Security in/to other groups • MWSG, GSVG, JSPG, SCG • ‘attitude’ of sites in the region to security developments • peer grids, NRENS David Kelsey, Grid Security, HEPiX, JLAB

24. OSCT Regional Operations Centre Resource Centre Resource Centre … … Resource Centre Resource Centre Operations Support Model Grid Operator on-duty PeerGrids Regional Operations Centre Regional Operations Centre … … ROC and Site work to resolve the problem David Kelsey, Grid Security, HEPiX, JLAB

25. OSCT – Security Service Challenges • Service Challenge 1 review • Summary of OSCT presentation by Pal Andersen • https://twiki.cern.ch/twiki/bin/view/LCG/LCGSecurityChallenge • Service Challenge 2 plans • Traceability of storage operations • Three pieces of information will be provided to the challenged site: • A time interval (~ 15 minutes) • The Distinguished Name (DN) used by the challenger • The Worker Node (WN) from which operations were executed • The question asked is: • What sequence of storage operations affected which files? • Delay because some logging clearly absent from configuration. David Kelsey, Grid Security, HEPiX, JLAB

26. Grid Security Vulnerability Group (slides from Linda Cornwall) David Kelsey, Grid Security, HEPiX, JLAB

27. The Vulnerability Task in EGEE II • The aim is “to incrementally make the Grid more secure and thus provide better availability and sustainability of the deployed infrastructure” • Recognition that it cannot be made perfect immediately • Handling of Security Vulnerability issues • the largest activity in this task David Kelsey, Grid Security, HEPiX, JLAB

28. Setup of the issue handling in EGEE II The GSVG issues group in EGEE II consists of • Core Group Members • Run the general process • Ensure information is passed on • 1 on duty each week • At present 4 members • Risk Assessment Team (RAT) • Carry out Risk Assessments • At present 8 full RAT members • Plus 4 others which confine their work to their own area of expertise • RAT people are security experts, experienced system administrators, deployment experts and developers David Kelsey, Grid Security, HEPiX, JLAB

29. GSVG process • Issue is submitted • Anyone can submit an issue • At least 3 RAT members carry out a Risk Assessment • Target Date (TD) set according to Risk • Extremely Critical – 2 days • High – 3 weeks • Moderate – 3 months • Low – 6 months • Mirror bug entered in JRA1 Savannah • The issue is then in the hands of JRA1 management • EMT co-ordinates fixing the issue and the release David Kelsey, Grid Security, HEPiX, JLAB

30. Disclosure Policy for EGEE II • Moving to a responsible public disclosure policy • On Target Date • information on the issue is made public • Regardless of whether a fix is available • Management approval for this approach still pending David Kelsey, Grid Security, HEPiX, JLAB

31. Integration with AAI Federations (slides from David Groep and Christoph Witzig)& Interoperability David Kelsey, Grid Security, HEPiX, JLAB

32. eIRG Roadmap: AAI federations The e-Infrastructure Reflection Group Roadmap contributors and actors in the field • e-IRG (high-level policy) • TERENA task forces: TF-EMC2, TF-Mobility • IGTF • eduroam™ • GEANT2 JRA5 (eduGAIN) • REFEDs • many national federations (CH, ES, NL, NO, UK, …) • software providers: Shibboleth, A-Select, PAPI, … David Kelsey, Grid Security, HEPiX, JLAB

33. e-IRG integrated AAI Roadmap Trans-disciplinary (Grid projects, NRENs, other user communities) and trans-continental forums that move towards the establishment of a global, seamless AA infrastructure for e-Science applications should be encouraged. The e-IRG wishes to acknowledge the efforts made in this direction by the IGTF and the open information exchange point provided by TERENA task forces. Recommendation to the e-IRGAustrian EU Presidency 2006 David Kelsey, Grid Security, HEPiX, JLAB

34. Shibboleth and Grids • SWITCH was an early adopter of Shibboleth, but in the meantime Shibboleth federations are being deployed and operated in many countries • US, Finland, UK, Australia, Belgium, France as well as others • Interest to leverage these (national) campus infrastructures against grids • SWITCH integrating gLite and Shibboleth • In EGEE-II David Kelsey, Grid Security, HEPiX, JLAB

35. Overview Phase 1 and 2 David Kelsey, Grid Security, HEPiX, JLAB

36. Interoperability • Interoperability – very important • OGF “Grid Interoperability Now” (GIN) project • AuthN and AuthZ recognised as very important • IGTF for AuthN • EGEE active in GIN AuthZ • Running VOMS service for GIN • AUP based on JSPG work • New developments on policy expression/evaluation • G-PBox • Security Operations and Policy/Procedures • Also aiming for more interoperability David Kelsey, Grid Security, HEPiX, JLAB

37. References • LCG/EGEE Joint Security Policy Group http://proj-lcg-security.web.cern.ch/ • EGEE Securityhttp://egee-jra3.web.cern.ch/ • Open Science Grid http://www.opensciencegrid.org • IGTF http://www.gridpma.org/ • EU Grid PMAhttp://www.eugridpma.org/ • TERENA Tacarhttp://www.tacar.org/ • Grid AUP https://edms.cern.ch/document/428036 David Kelsey, Grid Security, HEPiX, JLAB

38. Final Words • Have made good progress over last year • IGTF now fully established • Common, simple policies getting there • New EGEE-II security groups starting to make impact • OSCT & GSVG • VOMS has taken a long time • Now being used for AuthZ • But meeting policy requirements will take much time • Standards are essential – for interoperability • OGF is important here • Grid Security will drive/implement new standards • People/Social aspects even more important • Building international trust takes time • Between Grids, Sites and VOs David Kelsey, Grid Security, HEPiX, JLAB