Establishment of Baseline SRCNet Security Agreements

See Policy Page - https://confluence.skatelescope.org/x/-vVcE

Policy Development Kit - https://aarc-community.org/policy/policy-development-kit/

Iris Security Policies - https://www.iris.ac.uk/security/

Some Action Planning:

• Liam (top level context): Provide context regarding the underlying framework (for the security policies)
  • A brief history.
  • The benefits of this framework for SRCNet. Reference to this framework working for existing organisations / projects. Etc.
  • How do we know we have chosen the right level of coupling between policies for SRCNet?
  • This context could be via e.g. slideware, or new section in confluence ... so long as this is SRCNet facing, discoverable via SRCNet pages, shared with the endorsers (at some point), usable by Rosie for Council.
• Liam (per policy context): Provide context / commentary for each policy, for non-experts, to understand: the necessity of each policy, how the policies nest/fit together, how IRP numbers were arrived at, how long to keep logs for etc...
  • This could be a rewrite of each confluence outline, if not too long
  • Add a commentary/context section.
• Not an Action: Standard Definitions - in addition to acronyms, some policy terms have implicit meaning that may differ by nation. These terms are to be clarified by a standard/shared definitions document, clarifying terms/definitions within policies and replying to comments  , removing use of these terms...
• Rob : Extension of the policy-setting workflow... user agreements aren't the same as policies per site
  • Clarify the policy wrapper approach - the full version is endorsed, with all the preamble, versioning etc. But the users only see the main content.
  • Make a couple
  • Make the link to the version without all the preamble most prominent
• Rob: to add to the Funnel desired tooling, visibility via public website, centralised location (permanence of policies) etc. Liam to please add his suggested solution
• Liam: Check where the AUP restriction is coming from / if actually we can adapt points 1-10?
• Rob to talk with Janneke: Request for a diagram to show the policy setting workflow & recognise other actors (not just the internal roles), the SRCs will have legal departments, officers etc. 
• Rob: Add to Funnel SRCNet AUP and Privacy Policy sign-up trigger to the SKA IAM, Rosie to add context
• Rosie had questions about the WLCG IAM service ... add the answers to our policy page
• Liam short action: review all of our Sources / Resources to ensure that no contents are missing. Once done, we will no longer need that section.
• Project Team (data policies, resource management): review all of our Sources / Resources, meeting notes, to ensure that no contents are missing. Once done, we will no longer need that section.
• Project Team: Identify the endorsers and reviewers per policy - provide names (could be via excerpt).
  • Also clarify what level of review is required - the reviewer list have the opportunity to review, but do not block progress if not engaged
• Project Team: Clear identification of the Officer role(s), their responsibilities, expected FTE fraction, and info on how they are expected to oversee the enactment of the policies
  • This may evolve over time - so minimal for v0.1, if needed at all at this stage
  • To be clearly distinguished from the Owner role OR combined
• Liam: Split out user agreements into different box / format than site policies
• Project Team: Understand distinction between a formal policy (signed) and an agreed approach (that the Project team can manage in other formats)
  • Check if any current policies on the list can be agreed approaches instead
  • More a data management check, not expected to change the security policy list
• Janneke: to share ISMG policy feedback and translate into actions (if not done already)
• Liam: Policy contents review exercise with the SOG
• Rosie: to set up meeting at RAL