Ongoing draft available at https://docs.google.com/document/d/176vzNaoK6KvKTMp8Glk2n1NaM6bxiS1QqH8M3_mu7NI/edit#
Preliminary version (2018-07-31, as a pdf) of the AARC Policy Development Kit.
Provide new or evolving Research Communities and Infrastructures with the guidance they need to develop a complete policy suite supporting Federated Identity Management. This should be done with input from the wider community, through FIM4R, WISE and relevant bodies. For this work in AARC, the policy kit should be tightly scoped to the blueprint architecture but there is an expectation that the work be extended to be relevant for infrastructures in general.
Operational Management of Research Communities and their respective infrastructures
- Identify key actors in Blueprint Architecture (Membership Manager, Proxy Operator, etc)
- Identify Policies Required for Compliance with Snctfi
- Identify Example Policies from other infrastructures to serve as inspiration
- Produce a training module to enable Research Communities to have a basic starter pack for policies
- Introduce the concept of frameworks and policies, why are they important
- Introduce Snctfi
- Encourage RC actors to make policy decisions (e.g. log retention, minimum assurance etc)
- Translate those decisions into policy templates
- Q & A
- Place templates on the AARC Website and produce an AARC Guideline document that links to each piece
- RCs/Infrastructures may not have a security focussed person, could just be a PI. Definitely can't assume CSIRT body
- Those using this policy pack are following the AARC blueprint
- Stable DP CoCo Version
- Aligned AUP AARC Deliverable
- Life Sciences
- HelmHoltz Data Federation
- PI/Membership Manager (including Security Contact)
- Proxy Operator
- Service Management (including Security Contact)
- Infrastructure Management (including Security Contact)
- Excel of Training Course https://docs.google.com/spreadsheets/d/16sdyV_MtD8AsvJb1wZvPuCsjTdpKjHhED91ymcCmRFY/edit?usp=sharing
- Document of content https://docs.google.com/document/d/176vzNaoK6KvKTMp8Glk2n1NaM6bxiS1QqH8M3_mu7NI/edit?usp=sharing
- Slides pending
Which policies do we need?
|Policy Need||Source||Template Basis||Audience||Comment||Name||What should we produce?||Actions|
|Incident Response Procedure||Sirtfi||EGI Incident Response, should link to Sirtfi, AARC work||Proxy, Services||Incident Response Procedure||Template||H to add template based on AARC and EGI|
for all Constituents
|Snctfi||EGI Operational Security Policy||Proxy, Services|
Top level policy that covers physical and network security, vulnerability handling and refers to additional policies on Acceptable Assurance, Incident Response Procedure, Membership management
We either make very modular or try to make this quite long
|Top Level Policy||Template|
|AUP for end users||Snctfi||WISE Baseline AUP||Users||Infrastructure AUP||Template||Wait for Ian, check with him|
|Collections of users' aims and purposes||Snctfi||This is the User Community AUP. There is an example somewhere. Would be better if these could be combined.|
Policies and procedures regulating the behaviour of the management of the Collection of users
|Snctfi||EGI Membership Management||In XSEDE it's much more simple||Membership Management||Template||U to add template based on https://docs.google.com/document/d/1vPcAja1EyTp-kJPvJpwu3NSd8e1aVcytY3nSGthWNLU/edit#|
Data Protection Policy, e.g. DP CoCov2
|Snctfi||CoCo||Could be included in top level||Data Protection Code of Conduct||Framework description||U to go through CoCov2 and check whether this is prescriptive enough|
|Policy on eligibility to join the infrastructure (i.e. services)||Elixir|
NOT Similar to EGI Service Operations, there is some overlap with the Top Level Policy.
Try and include in overall policy
|Data Protection Impact Assessment (DPIA)||Data Privacy Statement|
NOT A POLICY but could inform policy decisions. Could be one of the steps to think about before the policy.
Acceptable Authentication Assurance
|We should make people think about this, but RAF not quite ready.||Template||Very basic template included|
Example Policy Sets
Differences with EGI Policies?
- Cannot assume a CSIRT for each Infrastructure
- Assume there is one AUP
- Resource Centres are not relevant
- There are not necessarily multiple User Communities
|Reword "Research Community" to Infrastructure||Hannah|
|IR Procedure Template, cross check with CTSC & EGI, add internal part||Hannah|
|AUP Template, should be a reasonable version||Ian|
|Membership Management Template||Uros|
|Check whether CoCov2 can be our "policy"||Uros|
|Send an update to Irina||Hannah|
|Put on AARC Website/Moodle in a modular format||Irina & Consultant|
|Ask David about RAF and Assurance Profiles|
|Move frameworks before policies||Hannah|
|Top Level Policy, check whether it really covers things||Hannah|
|Add "Other things you may want to think about"||Hannah|
|Acceptable Authentication Assurance improve||Hannah|
|Put on slides and give to Irina||Uros/Hannah|
|Insert "top" Data Protection Policy (for Infra), in comparison per Service||Uros|
|Update AUP to reflect recent changes (2018-07-31)||Uros|
Notes & Thoughts
Objective: Provide new or evolving Research Communities and Infrastructures with the guidance they need to develop a complete policy suite supporting Federated Identity Management
Audience: Operational Management of Research Communities and their respective infrastructures
We’re worried that we will have legal issues receiving federated identities, which policies do we need?
What is a reasonable expectation of assurance of incoming identities?
How can I ensure that all my users are covered by an incident response capability?
What checks and measures should I put in place when managing the users of my community services, or members of virtual organisations?
Make clear why these policies should be adopted, where they have come from and examples of how they help
(Would be good to have actionable points as well as dry document examples)
(Can we encourage people to be in the right mindset to make their own decisions about timelines for policy decisions etc)
Snctfi (top level) -- for scalable, bounded communities https://aarc-project.eu/policies/snctfi/
Data Protection & Privacy
AARC deliverable template
Risk Assessment (due to the GDPR) -> WISE https://wise-community.org/risk-assessment-template/
Membership management & AUP
Can cover Users, Communities and contributing services
AUP - Acceptable Use Policy
Accounting, logging, monitoring policies
LoA (What is the acceptable level? Is step up required?)
Security Incident Response
Sirtfi (Able to assert for RC? Require it for incoming federated users? Is step up required?)
AARC deliverable template
Security policies e.g. EGI
Sources of input:
EGI security and community policies
ELIXIR AAI strategy Appendix A: Acceptable Usage Policy, Appendix B: Policy for Relying Parties, Appendix C: Requirements for ELIXIR AAI operators
Also, maybe we can re-use the EGI work (Security and Community policies)
Crazy ideas for how this could work...
Moodle course walking people through decisions for each policy aspect
Website static pages (bit dull)
Recorded video snippets for each aspect (Uros and Hannah can do a double act of questions and answers!)
“Click in” style website
Face-to-face session where we split the room into sections and ask for questions on specific policies
Recorded interviews with experts on specific topics, e.g. GDPR, Security Incident Response
Key Ideas for each topic:
What is this policy for?
Does my RC/Infrastructure need it?
What do I need to do?
Who needs to agree to the policy and where should it live?
Could group as: