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

Compare with Current View Page History

« Previous Version 14 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. Encourage RC actors to make policy decisions (e.g. log retention, minimum assurance etc)
    2. Translate those decisions into policy templates

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?
Incident Response ProcedureSirtfiEGI Incident Response, should link to Sirtfi, AARC workProxy, ServicesWhat about policies?Incident Response ProcedureTemplate

Policy on

authentication,
authorisation,
access control,
physical and network security,
security vulnerability handling and
security incident handling

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 AUPUsersEGI seems to have 2 AUPS, Infrastructure and User CommunityInfrastructure AUPTemplate
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 ManagementTemplate

Data Protection Policy, e.g. DP CoCov2

SnctfiCoCo
Could be included in top levelData Protection Code of ConductFramework description

Privacy Policy 

CoCoCoCo Template

Privacy PolicyTemplate
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
Risk Assessment (DPIA)Data Privacy Statement??
NOT A POLICY but could inform policy decisions????


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



  • No labels