You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 30 Next »

Draft available at https://docs.google.com/document/d/176vzNaoK6KvKTMp8Glk2n1NaM6bxiS1QqH8M3_mu7NI/edit# 


Objective 

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. 

Audience 

Operational Management of Research Communities and their respective infrastructures

Process

  1. Identify key actors in Blueprint Architecture (Membership Manager, Proxy Operator, etc) 
  2. Identify Policies Required for Compliance with Snctfi
  3. Identify Example Policies from other infrastructures to serve as inspiration
  4. Produce a training module to enable Research Communities to have a basic starter pack for policies
    1. Introduce the concept of frameworks and policies, why are they important 
    2. Introduce Snctfi
    3. Encourage RC actors to make policy decisions (e.g. log retention, minimum assurance etc)
    4. Translate those decisions into policy templates
    5. Q & A
  5. Place templates on the AARC Website and produce an AARC Guideline document that links to each piece

Assumptions

  • 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

Pre-Requisites

  1. Stable DP CoCo Version
  2. Aligned AUP AARC Deliverable

Use Cases

  • EPOS
  • Life Sciences
  • HelmHoltz Data Federation

Roles

  • PI/Membership Manager (including Security Contact) 
  • Proxy Operator
  • Users
  • Service Management (including Security Contact)
  • Infrastructure Management (including Security Contact)

Next Steps

  1. Design a top level policy, either modular or verbose
  2. Add templates for easy wins (IR, AUP, Privacy Policy from CoCo, Membership Management )  
  3. More difficult modules (Authentication Assurance - Uros Stevanovic)

Which policies do we need?

Policy NeedSourceTemplate BasisAudienceCommentNameWhat should we produce?Actions
Incident Response ProcedureSirtfiEGI Incident Response, should link to Sirtfi, AARC workProxy, Services
  • What about policies?
  • Incident Response Procedure from AARC
Incident Response ProcedureTemplateH to add template based on AARC and EGI

Policy on

  • authentication, 
  • authorisation, 
  • access control, 
  • physical and network security, 
  • security vulnerability handling and 
  • security incident handling → IR procedure

for all Constituents

SnctfiEGI Operational Security PolicyProxy, 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 PolicyTemplate
AUP for end usersSnctfiWISE Baseline AUPUsers
  • EGI seems to have 2 AUPS, Infrastructure and User Community
  • Wait for Ian's WISE Baseline AUP
Infrastructure AUPTemplateWait for Ian, check with him
Collections of users' aims and purposesSnctfi

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 

SnctfiEGI Membership Management
In XSEDE it's much more simpleMembership ManagementTemplateU to add template based on https://docs.google.com/document/d/1vPcAja1EyTp-kJPvJpwu3NSd8e1aVcytY3nSGthWNLU/edit#

Data Protection Policy, e.g. DP CoCov2

SnctfiCoCo
Could be included in top levelData Protection Code of ConductFramework descriptionU to go through CoCov2 and check whether this is prescriptive enough

Privacy Policy 

CoCoCoCo Template

Privacy PolicyTemplateH to add the Privacy Policy template from CoCov2
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

Service EligibilityTemplate
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.

https://wise-community.org/risk-assessment-template/




Acceptable Authentication Assurance




We should make people think about this, but RAF not quite ready.
TemplateVery basic template included


Example Policy Sets

CTSC PoliciesRelevant for AARC?
Acceptable Use Policy TemplateYes
Access Control Policy TemplateYes
Asset Management Policy Template
Asset-Specific Access and Privilege Specification Template
Disaster Recovery Policy TemplateNo
Incident Response Policy and Procedures TemplateYes
Information Asset Inventory TemplateNo
Information Classification Policy TemplateNo
Information Security Training and Awareness Policy TemplateNo
Master Information Security Policy & Procedures TemplateYes
Password Policy TemplateNo
Physical Security Policy TemplateYes



EGI PolicyRelevant for AARC?
Access Platform AUP and Conditions of Use (aka. Platform for the long tail of science)No
EGI Access Platform Security Policy (aka. Platform for the long tail of science)No
EGI Glossary V2No
Grid Policy on the Handling of User-Level Job Accounting DataNo
Policy on e-Infrastructure Multi-User Pilot Jobs (Updated 14 Nov 2016)No
Security Policy for the Endorsement and Operation of Virtual Machine Images (Updated 10 Oct 2016)No
Security Policy Glossary of TermsPerhaps
Security Traceability and Logging Policy (Updated 14 Nov 2016)Perhaps
Service Operations Security Policy (Updated 1 June 2013)Perhaps
Virtual Organisation Registration Security PolicyPerhaps
VO Operations PolicyPerhaps
VO Portal Policy (Updated 14 Nov 2016)Perhaps
Acceptable Use Policy and Conditions of Use (Updated 10 Oct 2016)Yes
e-Infrastructure Security Policy (Updated 1 Feb 2017)Yes
Policy on Acceptable Authentication Assurance (Updated 1 Feb 2017)Yes
Policy on the Processing of Personal Data (New policy from 1 Feb 2017)Yes
Virtual Organisation Membership Management PolicyYes
Security Incident Response Policy (Updated 14 Nov 2016)Yes for procedure


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


ActionStatusWho
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
CoCov2 Privacy Policy Template
  •  
Hannah
Check whether CoCov2 can be our "policy"
  •  
Uros
Send an update to Irina
  •  
Hannah
Consider DPIA
  •  
Uros
Put on AARC Website in a modular format
  •  
...
Ask David about RAF and Assurance Profiles
  •  

Uros

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
Add diagram
  •  
Hannah


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

Relevant questions:

  • 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?


Introductory Content:

  • Make clear why these policies should be adopted, where they have come from and examples of how they help


Policy Areas:

(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


Membership management & AUP

  • Can cover Users, Communities and contributing services

  • Attribute request/release

  • 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

  • AARC templates

  • CoCo work

  • WLCG 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

  • Road show

  • 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?

  • Sub policies

  • Does my RC/Infrastructure need it?

  • What do I need to do?

  • Who needs to agree to the policy and where should it live?

  • Template


Could group as:

  • General Policies

  • Audience Specific

See e.g. https://edms.cern.ch/ui/#!master/navigator/project?P:1412060393:1412060393:subDocs

And https://wiki.egi.eu/wiki/SPG:Documents


  • No labels