1. EGI Security Policy Update
David Kelsey STFC-RAL
18/09/2013
EGI Security Policy

2. EGI Security Policy Group Security for Collaborating Infrastructures
Outline
EGI Security Policy Group
Security for Collaborating Infrastructures
Federated Identity Management for Research
Future work
18/09/2013
EGI Security Policy

3. EGI Security Policy Group https://wiki.egi.eu/wiki/SPG
18/09/2013
EGI Security Policy

4. Current EGI Security Policy
Current EGI Security Policy is available at
As formally adopted by EGI.eu
Now show recent policy changes
18/09/2013
EGI Security Policy

5. Revised Security Policies
Service Operations Security Policy
Added new text on the policy requirement for deployment of Security Emergency Suspension
18/09/2013
EGI Security Policy

6. Service Operations Security Policy
You must implement automated procedures to download the security emergency suspension lists defined centrally by Security Operations and should take appropriate actions based on these lists, to be effective within the specified time period.
18/09/2013
EGI Security Policy

7. Service Operations Security Policy (2)
Other changes:
addresses end of security support for software
… software patches, updates or configuration changes required for security or end of security support …
removes the IPR statement (as covered elsewhere)
addresses the retirement of a service
18/09/2013
EGI Security Policy

8. Revision to Grid AUP
EGI Council decided to require its users to acknowledge support and the resources used
And requested change to the User AUP
EGI SPG considered
Not easy as Users usually register with VOs not sites or infrastructures
This is one document where common wording between all VOs, communities etc is very useful!
The following new wording was proposed
Next page
18/09/2013
EGI Security Policy

9. New AUP(2)
Acknowledgement of support or of your use of the resources or services provided to you by Infrastructure Providers, Infrastructure Organisations and/or Resource Centres may be required by the body or bodies granting you access. You shall comply with all such requirements by adding the specified citations or acknowledgements to all published papers, preprints, conference papers and talks and any other published material, whether or not these are subject to copyright.
Note: Additional procedures are required to specify what acknowledgements are required and by whom
18/09/2013
EGI Security Policy

10. SPG received complaints that this wording is too detailed
New AUP(3)
SPG received complaints that this wording is too detailed
E.g. the list of types of publication affected
A simpler wording will be proposed to the stakeholders.
18/09/2013
EGI Security Policy

11. Security for Collaborating Infrastructures (SCI)
18/09/2013
EGI Security Policy

12. Building a new Trust Framework
There are several large-scale production Distributed Computing Infrastructures
Grids, Clouds, HPC, HTC, …
Each includes resources, services, users, policies and procedures
Subject to many common security threats
Common technologies
Common users (spreading infections)
Essential to share information and work together on security operations
18/09/2013
EGI Security Policy

13. Security for Collaborating Infrastructures
A collaborative activity of information security officers from large-scale infrastructures
EGI, OSG, PRACE, EUDAT, CHAIN, WLCG, XSEDE, …
Developed initially out of EGEE and WLCG
We are developing a Trust framework
Enable interoperation (security teams)
Manage cross-infrastructure security risks
Develop policy standards
Especially where not able to share identical security policies
18/09/2013
EGI Security Policy

14. SCI: areas addressed Operational Security Incident Response
Traceability
Participant Responsibilities
Individual users
Collections of users
Resource providers, service operators
Legal issues and Management procedures
Protection and processing of Personal Data/Personally Identifiable Information
18/09/2013
EGI Security Policy

15. Older public draft (V0.95) at http://www.eugridpma.org/sci/
SCI Document
V1 of the SCI document was submitted to ISGC 2013 proceedings (under review)
SCI has met since then
new version (V1.3?) under way
Older public draft (V0.95) at
18/09/2013
EGI Security Policy

16. SCI example – Incident Response
Imperative that an infrastructure has an organised approach to addressing and managing events that threaten the security of resources, data and overall project integrity.
Each infrastructure must have:
[IR1] Security contact information for all service providers, resource providers and communities together with expected response times for critical situations.
[IR2] A formal Incident Response procedure, which must address roles and responsibilities, identification and assessment of … (text continues)
And continues …
18/09/2013
EGI Security Policy

17. SCI Assessment
To evaluate extent to which requirements are met, we recommend Infrastructures to assess the maturity of their implementations
According to following levels
Level 0: Function/feature not implemented
Level 1: Function/feature exists, is operationally implemented but not documented
Level 2: … and comprehensively documented
Level 3: … and reviewed by independent external body
18/09/2013
EGI Security Policy

18. Example of assessment form
18/09/2013
EGI Security Policy

19. Security for Collaborating Infrastructures SCI meetings
Further info
Security for Collaborating Infrastructures
SCI meetings
18/09/2013
EGI Security Policy

20. Federated Identity Management for Research Communities (FIM4R)
18/09/2013
EGI Security Policy

21. Introduction – FIM4R
Federated Identity Management for Research Collaborations
An ad-hoc activity that started 2 years ago in Europe
To explore and document a joint vision and our common requirements for FIM
And describe issues that make progress difficult
Includes: Climate Science, Earth Sciences, ESA, High Energy Physics, Social Sciences & Humanities, Life Sciences, Neutron & Photon Facilities, WeNMR
And open to any others who wish to join
18/09/2013
EGI Security Policy

22. Separate authentication and authorisation
Why federate?
Separate authentication and authorisation
Identification done by home institute
Community manages authorisation
Ease of use
User single sign-on
Ease of management
18/09/2013
EGI Security Policy

23. Workshops and Paper 5 workshops to date
link to Mar 2013 agenda (and links therein)
April 2012: We prepared a paper that documents use cases, common requirements, a common vision and recommendations
Paper: CERN-OPEN :
18/09/2013
EGI Security Policy

24. Common vision statement
A common policy and trust framework for Identity Management based on existing structures and federations either presently in use by or available to the communities. This framework must provide researchers with unique electronic identities authenticated in multiple administrative domains and across national boundaries that can be used together with community defined attributes to authorize access to digital resources
18/09/2013
EGI Security Policy

25. Common Requirements User friendliness
Many users use infrequently
Browser and non-browser federated access
Bridging between communities
Multiple technologies and translators
Translation will often need to be dynamic
Open standards and sustainable licenses
For interoperability and sustainability
Different Levels of Assurance
When credentials are translated, LoA provenance to be preserved
Authorisation under community and/or facility control
Externally managed IdPs cannot fulfil this role
Well defined semantically harmonised attributes
For interoperable authorisation
Likely to be very difficult to achieve!
18/09/2013
EGI Security Policy

26. Requirements (2) Flexible and scalable IdP attribute release policy
Different communities and different SPs need different attributes
Negotiate with IdF not all IdPs – for scaling
Attributes must be able to cross national borders
Data protection/privacy considerations
Attribute aggregation for authorisation
Privacy and data protection to be addressed with community-wide individual identities
We need to identify individuals
E.g. ethical committees can require names, addresses, supervisors to grant access
18/09/2013
EGI Security Policy

27. Pilot Projects
18/09/2013
EGI Security Policy

28. Addressing e-Researchers Requirements
Licia Florio, TERENA
REFEDS Meeting
2 June 2013
18/09/2013
EGI Security Policy

29. Roadmap for collaboration
REFEDS/eduGAIN produced a document to address FIM4R issues:
Provides an initial list of prioritised requirements (thanks also to Bob Jones & co.)
Addresses some perceived issues
Presents proposals to solve some of the challenges
18/09/2013
EGI Security Policy

30. Approach
The roadmap IS a joint work ID Fed and e-Researchers:
Identify key projects within the e-research community that REFEDS/GÉANT can liaise with
Funding:
eduGAIN and GN3plus have dedicated budget to carry out some work and do some pilots
REFEDS can offer a limited budget
Participating e-Research projects may use some of their funding ?
18/09/2013
EGI Security Policy

31. REFEDs https://refeds.org/ VAMP http://www.terena.org/activities/vamp/
More info
FIM4R (see this and links therein)
REFEDs
VAMP
18/09/2013
EGI Security Policy

32. Future work EGI SPG SCI FIM4R
Revisions needed to cover Federated Clouds
New more general Top-level policy
VO policies need revision
Accounting and other data protection issues
Other gaps identified by SCI
SCI
V1.3 will be produced
Continue work on self-assessments
FIM4R
Next meeting (with REFEDS and VAMP) – in 2 weeks
Evaluate progress and future plans
18/09/2013
EGI Security Policy

33. Questions?
18/09/2013
EGI Security Policy