Your resources, your research data, and your collaborators are valuable, yet continuously targeted by miscreants. Protecting these requires that everyone works together to protect them damage, disruption, and unauthorised use. The security operational baseline sets the bar to entry in most federated infrastructures, not only for the AAI but also for the protection of resources, data, and users. By adhering to a simple common baseline, the collaboration becomes easier and the expectations of all parties are clear. You will find that adherence to the security operational baseline is a prerequisite to entry for many of the ecosystems you want to join.

Adopting it as an e-Infrastructure or service provider

Users and research collaboration will be using your service(s) under the assumption that it is safe to do so, and - if you rely on others - that they can rely on you to manage your dependencies properly. Especially in 'cloud' scenarios, your supply chain in terms of both infrastructure and software is critical, and modern cybersecurity directives like Europe's NIS2 directive emphasise the importance of the supply chain. 

The security baseline gives you the outline of the security measures that help you participate in federation and provide trustworthy services. It relies on SIRTFI, the Security Incident Response Trust Framework for Federated Identity, and helps identify, mitigate, and resolve security incidents in your service and in your peers. Remember: you will typically find a security incident quite a long time after the intrusion actually happened, so keeping logs is particularly important! And exercising these communications channels is needed to make sure they work in case of emergencies.

Adopting it as an authentication source or collaboration

The AARC BPA identifies the collaboration layer as a key control point for resource access: as a collaboration, you hold critical data on 'who did what when', and are the most effective place to control access to resources and protect the infrastructures you use. You may be notified of security events by infrastructures and resource providers, since they will often identify anomalous behaviour first and have a definite interesting in stopping the abuse. The collaboration and the home organisation are the only ones in the AARC BPA that can associate the identifiers at the infrastructure and service layer with actual users. You are an essential part in stooping the incident from spreading and causing more harm!

How does the Security Operational Baseline fit into an AARC BPA compliant infrastructure?

Operational security is of course much more than AAI, but identity plays a critical role: as users 'traverse' the layered AARC BPA, they will acquire additional identifiers, and are gaining access to resources by virtue of their role, group memberships, and capabilities. Each of the layers in the AARC BPA provides control points to mitigate incidents and prevent the impact from spreading. 

Also keep in mind that each layer in the AARC BPA may keep state about the user sessions: even if an account is blocked at, for example, the identity layer, there may be sessions, tokens, or assertions active at the collaboration, infrastructure, or site-local layers. Therefore collaboration is essential, and reporting of security events and (potential) compromises to your partners is very important.

The twelve points to protect your resources and data

It is RECOMMENDED that all service providers follow these Baseline Requirements to achieve a sufficient level of security. These requirements augment but do not replace applicable security policies and obligations, nor any more specific security arrangements and service level agreements that may exist between participants. The baseline is specifically that: a set of minimal expectations between everyone in the infrastructure:

  1. comply with the SIRTFI1 security incident response framework for structured and coordinated incident response
  2. ensure that your Users agree to an Acceptable Use Policy (AUP) or Terms of Use, and that there is a means to contact each User.
  3. promptly inform Users and other affected parties if action is taken to protect their Service, or the Infrastructure, by controlling access to their Service, and do so only
    for administrative, operational or security purposes.
  4. honour the confidentiality requirements of information gained as a result of your Service’s participation in the Infrastructure.
  5. respect the legal and contractual rights of Users and others with regard to the personal data processed, and only use access personal data for administrative, operational, accounting, monitoring or security purposes.
  6. retain system generated information (logs) in order to allow the reconstruction of a coherent and complete view of activity as part of a security incident (the ‘who, what, where, when’, and ‘to whom’), for a minimum period of 180 days, to be used during the investigation of a security incident.
  7. follow, as a minimum, generally accepted IT security best practices and governance, such as pro-actively applying secure configurations and security updates, and taking appropriate action in relation to security vulnerability notifications, and agree to participate in drills or simulation exercises to test Infrastructure resilience as a whole.
  8. operate services and infrastructure in a manner which is not detrimental to the security of the Infrastructure nor to any of its Participants or Users.
  9. collaborate in a timely fashion with others, specifically those with which there is a direct trust relationship, in the reporting and resolution of security events or incidents related to their participation in the infrastructure and those affecting the infrastructure as a whole.
  10. honour the obligations on security collaboration and log retention (clauses 1, 6, and 9 above) for the period of 180 days after their Service is retired from the Infrastructure, including the retention of logs when physical or virtual environments are decommissioned.
  11. not hold Users or other Infrastructure participants liable for any loss or damage incurred as a result of the delivery or use of the Service in the Infrastructure, except to the extent specified by law or any licence or service level agreement.
  12. maintain an  suppliers that ensures that engagement of such parties does not result in violation of this Security Baseline.

Resources