Page History

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:

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:

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:

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.

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.