EGEE security “pitch”

1. EGEE security “pitch” Olle Mulmo EGEE Chief Security Architect KTH, Sweden

2. Project PR

3. EGEE EGEE is the largest Grid infrastructure project in the World?: • 70 leading institutions in 27 countries, federated in regional Grids • Leveraging national and regional grid activities • ~32 M Euros EU funding for initially 2 years starting 1st April 2004 • EU review, February 2005 successful • Preparing 2nd phase of the project – proposal to 3rd EU Grid call September 2005

4. EGEE Activities • 48 % service activities (Grid Operations, Support and Management, Network Resource Provision) • 24 % middleware re-engineering (Quality Assurance, Security, Network Services Development) • 28 % networking (Management, Dissemination and Outreach, User Training and Education, Application Identification and Support, Policy and International Cooperation) EGEE emphasis is on production grid operations and end-user support

5. gLite • First major release of gLite announced on April 5 • Focus on providing users early access to prototype • Reusing existing components • Addressing current shortcomings • Interoperability & Co-existence with deployed infrastructure • (Cautious) service oriented approach • Follow WSRF standardisation • Site autonomy LCG-1 LCG-2 gLite-1 gLite-2 Globus 2 based Web services based

6. Pilot New Deployment of applications • Pilot applications • High Energy Physics • Biomed applications • Generic applications –Deployment under way • Computational Chemistry • Earth science research • EGEODE: first industrial application • Astrophysics • With interest from • Hydrology • Seismology • Grid search engines • Stock market simulators • Digital video etc. • Industry (provider, user, supplier)

7. Country providing resources Country anticipating joining EGEE/LCG In EGEE-0 (LCG-2): • >100 sites • >10,000 CPUs • >5 PB storage Computing Resources – Feb. 2005

8. What I came here for The EGEE view on Security - some philosophy and baseline assumptions

9. 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 • Don’t roll our own, to the extent possible • Be Distributed and Scalable • Avoid central services if possible • Always retain local control

10. 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

11. We can’t do anything too fancy ParadigmShift(SOA) Requirements on functionality Authentication Access control Credential mgmt Delegation Privacy … Existing capabilities GridPMAs WS-Security MyProxy Shibboleth VOMS Globus … Other workalreadyunderway(LCG, OGSA,…)

12. Architecture Technologies and more details

13. Authentication • IGF: Federation of PMAs • Better revocation technologies • Managed and Active credential storage • i.e., where access policy can be enforced • Smart cards, MyProxy, … • Organizationally rooted trust (KCA, SIPS) • User-held password-scrambled filesshould go away

14. Authorization • Flexible framework to support for multiple authorities and mechanisms • VOMS, banlist, grid-mapfile, SAML, … • Frank covered this in detail

15. Authorization model • Decentralized • Predominantly role-based push model • Out-of-the-box support for VOMS • Semantic-free role and group attributes • Pros • Scalability • Site autonomity • Multi-scenario support, VO self-governance • Cons • Fine-grained access control (?) • VO management still heavyweight • VOMS is proprietary

16. VO management • VOMS for now • modularity keeps it open for others • Allow for lightweight VO deployment • Proposed solution: VO policy service • Brainchild

17. CredentialStorage Obtain Grid credsfor Joe PseudonymityService 1. “Joe → Zyx” 2. 3. AttributeAuthority 4. Joe “The Grid” “User=Zyx Issuer=Pseudo CA” “Anonymity” • Pseudonymity as an selective additional step to the SSO process “Issue Joe’sprivileges to Zyx”

18. Data “privacy” • Data always encrypted except in RAM • Simple solution that ignores all the hard problems • (we have to as the system is open-ended)

19. Accounting • Several solutions • and none of them are deployed at an EGEE level… • Increasingly important

20. Audit • Not solved at a Grid level • Scalability and information release issues • Good tracking at the individual resource level for now

21. Integration and Development • Middleware Security Group • Cross-activity group • Operations, Applications, Developers, OSG • Mailing list, phone conferences, face-to-face meetings

22. Operational Management • Joint Security Policy Group • OSG, LCG participation • EUGridPMA • TERENA TF-CSIRT (incident response) • NREN CERTs start to show interest

23. More information • EGEE Websitehttp://www.eu-egee.org • DJRA3.1: Global Security Architecture (1st rev.) • https://edms.cern.ch/document/487004/ • DJRA3.2: Site Access Control (1st rev.) • https://edms.cern.ch/document/523948