Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Remove duplicate sections

...

This guidance is intended to assist those implementing SCI and, as such, is not primarily scoped to 'end users' - members of collections of users. Infrastructure managers, service operators, security officers, the responsibles of collections of users, and others invested in the security of an infrastructure and its services, are the intended audience.

Comments are welcomed (you will need to be logged-in). This document is intended to be a 'living document', updated in response to experience in of use and readers' comments. Please leave comments using use the comment facility provided at the end of this page.the page or highlight the relevant text and use the 'Inline comment' pop-up feature provided.

Two versions of an accompanying assessment spreadsheet are provided as attachments: SCIv2-Assessment-Chart_V2-template_A.xlsx and SCIv2-Assessment-Chart_V2_template_B.xlsx. Version A bases the assessment categories on the SCIv2 section titles, whereas version B uses the 'Checks' provided in each table for SCIv2 sections below. Feedback on the use of, or preference for, either is welcomed.

Related documents for this How-toRelated documents:

https://wise-community.org/wp-content/uploads/2017/05/WISE-SCI-V2.0.pdf
https://indico.nikhef.nl/event/2146/contribution/13/material/0/

Table of Contents

Operational Security - OS

...

Each of the collaborating infrastructures has:

What:

"A person or team mandated to represent the interests of security for the infrastructure."

Why:

To ensure that implementing infrastructure security policy is clearly defined as an individual or group core responsibility, giving it appropriate priority and authority within the organisation for necessary actions to be carried out. To prevent confusion and delay in the event of a reported incident.

How:

Designate an individual, or team, with responsibility for the development and oversight of activities required to implement security policy, including those to address and mitigate security risks. Provide, or delegate to, a clear point of contact within the infrastructure for all matters related to security, including incident handling.

Checks:

  • The person or team is appointed with clear responsibility and authority.
  • Contact details for the above are published internally and externally.

OS2 - Risk Management Process

...

What:

"A security plan (e.g., architecture, requirements, controls, policies, processes) addressing issues, such as, authentication, authorisation, access control, physical and network security, risk mitigation, confidentiality, integrity and availability, disaster recovery, together with compliance mechanisms ensuring its implementation."

Why:

In order to ensure that the overall operational security of the Infrastructure is matched to agreed levels of confidentiality, availability and integrity of data and resources, and maintained on a continuous basis. And to facilitate regular review (internal or external audit) of the appropriateness of procedures and controls implementing these requirements in the light of changing technology and use, together with training and knowledge transfer given staffing changes. In order to ensure that critical steps and decisions are not forgotten in the event of an incident, and to facilitate knowledge transfer given staffing changes.

How:

Infrastructure must document requirements for a plan detailing the questions of access control (who and for which purpose can access resources), security, and reliability (all the aforementioned points must be addressed) together with creating policies and procedures to implement the plan. This point requires a substantial effort. As such, it may be fulfilled with multiple documents (a policy framework) that addresses the points in question. Procedures from other points of the SCI (not just from OS) can be used to address this requirement. The security plan may take the form of a "live" document that is subject to regular updates to reflect changes decided by OS1.

Checks:

  • documents Documents exist defining the security requirements of the Infrastructure
  • responsibility Responsibility for definition of policies supporting the requirements is clear
  • controls Controls and procedures are in place to implement the policies
  • ownership Ownership and ongoing review of the implementation of policies is defined

...

What:

"The capability to identify and contact authorised users and service providers."

Why:

Contact information of users is necessary to contact the user for security related reasons e.g. should malicious activity be found associated with a user's account to investigate if their credential has been stolen.
Similarly, contact information of service providers is vital should, for instance, security investigations indicate that a service has been compromised e.g. is part of a botnet generating spam emails.

How:

As a minimum, it is recommended that the name and a validated email address for all users is gathered at registration and this information is available, where necessary, to authorised parties for the investigation of security incidents.
The Infrastructure operations team should gather and maintain contact information for the service administrators. Periodic testing that service contact email addresses remain valid can help ensure smooth communications flow when needed. A generic contact email for the service team, rather than any personal email, is likely to be more appropriate in these cases.

Checks:

  • user User contact information is available and maintained
  • system System administrator contact information is available and maintained

...

What:

"A process to maintain security contact information for all service providers."

Why:

Accurate and up to date contact information enables participants to exchange information quickly and efficiently with affected parties in the event of a security incident.

How:

This is generally seen as mandatory information to be provided when joining an infrastructure. The security contact information is usually an email used to contact service providers and communities in case of security incidents. The methods to obtain this lists are multifoldmulti-fold, such as from the metadata (in the case of the federation participants that support Sirtfi: https://refeds.org/sirtfi), or directly from the service operators and communities during the Infrastructure onboarding process. The up-to-dateness of the information can be ensured via periodic email verification procedures.

Checks:

  • there There is an onboarding process which gathers security contact information
  • service Service security contact information is available and maintained
  • community Community security contact information is available and maintained

...

What:

"A documented Incident Response procedure. This must address: roles and responsibilities of individuals and teams, identification and assessment of incidents, minimisation of damage to the infrastructure, response and recovery strategies to restore services, communication and tracking tools and procedures, and a post-mortem review to capture lessons learned."

Why:

Having a prepared and tested incident response procedure, agreed by all participants, allows for rapid and well coordinated response when an incident occurs. Valuable information may be lost or additional damage occur if time is lost during the response to an incident.

How:

The required effort depends on the size and the purpose of the Infrastructure. As a rule of thumb, the bigger the Infrastructure (in terms of users, communities, and services), or the more valuable or sensitive the data being processed is, the more comprehensive the procedure should be. Accordingly, for a smaller Infrastructure, the required effort may be more limited.
As mentioned, the documented Incident Response procedure must (at the very least) address the points above. The diagram below is an example of step-by-step guidance on how to proceed in cases of security incidents.

Checks:

  • a A procedure covering the points listed is documented
  • all All relevant parties are aware of the procedure

...

What:

"The capability to collaborate in the handling of security incidents with affected service providers, communities, and infrastructures, together with processes to ensure the regular testing of this capability."

Why:

Security incidents often extend across organisational boundaries and the handling of such multi-domain incidents requires communication and collaboration with other participants.

How:

Infrastructure management must ensure that adequate authority, priority and resources are given to be able to cooperate in security incidents with all affected (and potentially affected) entities. All parties must be aware of their responsibility to, and willing to participate, in the sharing of information.
This generally implies the existence of a dedicated security officer with backup from a security team, and appropriate policy agreements in place to enable collaboration with other security teams.
The effectiveness of the capability should be tested, i.e. "mock-up" incident scenarios, rehearsed on a regular basis. This activity is valuable, not only in revealing problems in communications and procedures, but also in building contacts and trust between the participants in the exercise..

Checks:

  • resources Resources and responsibilities are clearly allocated to security collaboration
  • engagement Engagement in multi-domain testing for incident response

...

What:

"Policies and procedures to ensure compliance with information sharing restrictions on incident data exchanged during collaborative investigations. If no information sharing guidelines are specified, incident data will only be shared with other security teams on a need to know basis, and will not be redistributed further without prior approval."

Why:

Information, such as affected identities or hosts addresses, which might be invaluable in protecting from or helping in the response to a security incident, will only be shared by the owners of the information if they trust that you will handle the information appropriately. Demonstrating that those handling such information within the infrastructure will do so appropriately, by strict adherence to agreed policies and procedures, is key to building this trust. Similarly, information arising from an incident within an infrastructure should be shared with collaborators where possible and appropriate, and sharing policies should be put in place beforehand.

How:

This point requires the Infrastructure to create policies and procedures for the receipt and sharing of incident information. These policies should outline how this information should be shared (in a proper manner, through secure channels), preferably to whom (how "wide" the required and authorized audience is), and which channels for communication and information dissemination are available.
All of these functionalities should be tested as defined in IR3. If such policies do not exist, the information should still be shared on a need to know basis.
The Traffic Light Protocol (TLP) is widely used as a basis for information exchange classification.

Checks:

  • an An information sharing policy is agreed and known to collaborators

...

What:

"Traceability of service usage, by the production and retention of appropriate logging data, sufficient to be able to answer the basic questions – who? what? where? when? and how? concerning any security incident."

Why:

Log data is the primary source of authoritative information on service events, such as failed and successful network connections and logins, the import and export of data, vital to understanding and tracing the origins and progression of a security incident by asking the questions posed above.

How:

This point is more comprehensive than initially may seem, as it involves not only logs but the information necessary to produce those logs. That means that in addition to information the Infrastructure generates itself, it may need to receive enough information in order to be able to produce such information. For example, in a proxy scenario, the information received from the IdP must be verbose enough to generate and assign proper "uniqueness" to the user. One example of such standard that Infrastructure may follow is R&S https://refeds.org/category/research-and-scholarship
In addition to receiving the information, generated logs should also be verbose enough to easily answer aforementioned questions. An infrastructure should also possess tools to properly parse the logs.
To reduce the possibility that logs can be destroyed or tampered with during an incident, it is strongly recommended that all logs records are securely forwarded, on generation, to a suitably secured central logging service.
For infrastructures sharing common services or service provider organisations, it is relevant to share personal information within the R&S attribute set (name of the person, email address) in order to correlate incidents across services and infrastructures that share cross-community users. In that context, the only service-provider correlatable information is user-bound, and this information should be sufficient to - with a high probability - identify the ultimate end-entity.

Checks:

  • services Services are configured to receive and log all the necessary information
  • where Where possible, logs are securely stored on a central service

...

What:

"A specification of the data retention period, consistent with local, national and international regulations and policies."

Why:

The availability of log data, sufficient to trace historical incident reports, is vital in understanding an incident and protecting an infrastructure from future attack. However, log data often contains information directly or indirectly associated with an individual, such as an identifier or location. While such data may be essential evidence when the individual is involved in a security incident, blanket gathering and storage of the usage data of all individuals, for an extended period, not knowing whether or not they are associated with an incident, is often restricted by laws, such as the European General Data Protection Regulation (GDPR). A policy balance must be sought between the benefits of retaining the data for incident tracing, how long this data really remains useful, and the negative risk posed by invasion of privacy or the possibility of the exposure of data (data breach).

How:

The logs generated in the TR1 should be kept for as long as they are necessary, but not longer. This period is not necessarily short, and proper reasons for keeping the logs are for security purposes, accounting, incident response, legal requirements. The logs, naturally, should be properly protected and only available to authorized personnel. Users should be made aware of which of their data is kept and for how long.

Checks:

  • a A log retention policy is agreed and users are aware of it
  • logs Logs are stored in a suitably secured manner

...

What:

"A specification of the controls that a service provider implements to achieve the goals of [TR1]."

Why:

Whenever a user passes a control point (authentication, authorization checks) the system should log sufficient information (identifier and attributes checked) to enable a unique path to be constructed back to the user, together with their associated actions, in the event of a security incident.

How:

In order to achieve TR1 (and TR2, for that matter) proper specification of how the logs are generated and accessed should be in place. It should outline the generation of logs, information contained in them, the retention time, access to logs. In addition, Infrastructure may force service providers to specify how such logs will be generated on the service provider side. Most commonly used AAI and logging tools have options to generate and manage the storage of this information in the appropriate format, and the configuration should be checked to ensure completeness of the logs.
Service providers are also bound by Infrastructure policies, and the information generated on a service provider's side is vital to proper functioning of the Infrastructure.

Checks:

  • the The configuration of tools has been checked against requirements of TR1

...

What:

"An Acceptable Use Policy (AUP) addressing at least the following areas: defined acceptable and non-acceptable use, user registration, protection and use of authentication and authorisation credentials, data protection and privacy, disclaimers, liability and sanctions."

Why:

An AUP brings together all the policy information that a user needs to understand about their use of the infrastructure, including limitations to use and the authority of others to restrict their use, before they are granted access.

How:

A recommended starting point is the WISE Baseline Acceptable Use Policy template available on the WISE website <here>. Guidance on using the WISE Baseline AUP in common scenarios, published by the AARC project, is available here - https://aarc-community.org/guidelines/aarc-i044/

Checks:

  • Have an Acceptable Use Policy (AUP)
  • Check that the AUP covers the areas listed in PRU1
  • Copy and augment the WISE Baseline AUP if useful.

PRU2 - User Awareness & Agreement (Individual Users)

...

What:

"A process to ensure that all collections of users of their infrastructure are aware of, and agree to abide by, infrastructure policy requirements, including the capability to collaborate in the handling of security incidents."

Why:

Collections of Users may operate a service that, to maintain the security of the Infrastructure, must abide by Infrastructure security policies. Additionally, those managing Collections of Users are responsible for contacting end users and providing traceability information that may be of help in an incident.

How:

Infrastructure security policies applicable to collections of users must be communicated to those responsible for the collection to ensure that they understand their responsibilities with regard to Infrastructure security. It is recommended that, as a minimum, a top level Infrastructure Security Policy is created defining all participants' primary responsibilities, including those of collections (communities) of users. The AARC Policy Development Kit provides a template top level policy, with further guidance on its use.

Checks:

  • Define a collection's responsibilities in policy or at least in a top level policy
  • Have an onboarding process by which access for each collection is enabledCopy and adapt the AARC top level policy if useful

PRC2 - User Registration & Management (Collections of Users)

...

What:

"Policies and procedures regulating the management of the membership of individual users, including registration, periodic renewal, suspension and removal, including forced removal due to policy violation. These must address the validation of the accuracy of contact information both at initial collection and on periodic renewal."

Why:

Membership management is crucial to allow Infrastructure Services to trust the validity and accuracy of User attributes sufficiently to be able to grant Users access.

How:

The lifecycle stages of individual users within a collection must be defined and managed from the collection of accurate registration data (with AUP acceptance, see PRU2 above) through to the user's eventual removal from the collection. The AARC Policy Development Kit provides a template Membership Management Policy and further guidance on its use, covering the stages itemised above, as well as personal data protection and record keeping for use in case of a security incident.

Checks:

  • Define how collections must manage the lifecycle of their users
  • Include the verification and periodic testing of users' contact information
  • Use the AARC Top Level & Membership Management policies if required

PRC3 - Responsibility for Actions (Collections of Users)

...

What:

"Defined their common aims and purposes and made this available to the infrastructure and/or service providers to allow them to make decisions on resource allocation."

Why:

Each Service Provider has funding, or has otherwise agreed, to provide resources to a particular project or research activity. Defining its 'aims and purposes' allows Service Providers to match resources to appropriate Collections and their Users. As well as allowing resource allocation decisions, whether or not a resource is being misused will depend on under what understanding a user of a service was granted access. Having a Collection make a clear statement of its 'aims and purposes' allows such decisions to be made.

How:

A simple statement such as "to further the science goals of the BIG project" is sufficient and will be asked for by the Infrastructure as part of the Collection's onboarding process.

Checks:

  • Define and publish the collection's common aims and purposes.

PRS1 - Compliance Ensurement Procedures (Service Providers)

...

What:

"Policies and procedures to ensure that service providers understand and agree to abide by all applicable requirements in this document, including the capability to collaborate in the handling of security incidents."

Why:

Establishing trust in the behaviour of Infrastructure participants, including Service Providers, is essential to managing the risk posed to participants by their activity in the Infrastructure, and to enable the necessary exchange of information in the event of an incident. By agreeing to abide by a common set of procedures and policies, Service Providers create an environment where such trust can be fostered.

How:

Compliance with SCI results in requirements placed on service providers, such as log generation and storage. The SCI checklist can be used to make sure that all such requirements are gathered. It is recommended that, as a minimum, a Top Level Security Policy is created to fulfill this requirement. The AARC Policy Development Kit provides a template top level policy with further guidance on its use. Define a process by which these requirements are communicated to service providers before their service is attached to the infrastructure.

Checks:

  • Define the SP's responsibilities in policy or at least in a top level policy
  • Have an "onboarding" process, which all service providers go throughCopy and adapt the AARC Top Level policy if useful

Data Protection - DP

DP1 - Policies for Protection of Personal Data

...