...

A Trust Framework for Security Collaboration among Infrastructures

1. Background

The Security for Collaborating Infrastructures (SCI) group is a collaborative activity of information security officers from several large-scale distributed IT infrastructures (DIIs), including EGI, OSG, PRACE, EUDAT, CHAIN, WLCG, and XSEDE. SCI is developing a trust framework to enable interoperation of collaborating DIIs with the aim of managing cross-infrastructure operational security risks. We also aim to build trust between the DIIs by developing policy standards for collaboration especially in cases where we cannot just share identical security policy documents.

SCI was created to help address several issues. Firstly, the WLCG infrastructure which uses resources from several DIIs, including EGI, OSG and NDGF, found itself in the position where agreeing security policy documents was becoming more difficult. Different DIIs had similar policies addressing similar issues but agreement on the exact wording was in many cases not possible. What was needed was a higher-level agreement on the types of security policies required and the issues they should address rather than the detailed policy words. Secondly, the various operational security teams were finding that they needed to work more and more often together on shared security incidents. This collaboration was often found to be successful, but all agreed that having a common security policy framework would help enable a more formal trust environment. Finally, it was recognised that the adoption of a common security policy framework would also help facilitate interoperation between the DIIs in the sense of shared communities of users.

There are several series of national or international standards defining best practice in the management of Information Security, including ISO 27000 [1] and NIST 800-53 [2]. These standards provide extremely useful guidance for handling security within a single management domain but are not really of much use when dealing with the management of security across multiple DIIs where each DII already consists of resources from many different sites each having their own management. We are not aware of any other activity to define standards and a trust framework as presented here.

The detailed requirements for security differ between our DIIs, but nevertheless, in this SCI activity we are concentrating on those issues which are common to all infrastructures. The characteristics may differ and some issues may be more or less important, but all of them should be considered by every DII.

Many of the requirements expressed in this current document are left deliberately vague, e.g. by not setting minimum requirements for the content of policy documents, nor defining detailed procedures, e.g. the time limit for security patching. Experience has shown that these are often the areas where DIIs differ and that it works better to allow infrastructures the freedom to define the detailed procedures according to their own environment and needs. Future versions of the SCI document, which may always be found on our web site [3], may well define some of these issues more tightly.

The SCI deliberations have been conducted by face to face meetings, by telephone or video conference and by email. Most of our face to face meetings have been co-located with meetings of the International Grid Trust Federation (IGTF) [4] as it involves many of the same individuals. IGTF has also agreed to host our web-site. This is very appropriate in that this is a neutral, DII-independent, location and IGTF is after all in the business of building global trust.

The document presented here is written by our group but is not yet approved by the management of our infrastructures. SCI does not have the authority to force new policy standards on our parent infrastructures, nor can we commit effort to performing self-assessments. The next stage of the work will involve wider consultation with our DIIs to gather feedback on and wherever possible will also include seeking endorsement of the SCI document. We aim to perform self-assessments of the extent to which our DIIs meet the documented requirements according to the maturity scale presented here. Based on the feedback received and the results of our self-assessments it is likely that we will need to further refine the SCI document.

SCI is an open group. Other DIIs interested in contributing to the group's activities or using our documents and assessments are very welcome to join our deliberations.

The SCI document itself follows after the Glossary starting with the section: "Introduction".

1. Glossary

The following terms are defined for use in the SCI document:

...

2. The SCI document - Introduction

In recent years we have seen the implementation of a variety of infrastructures supporting distributed computing environments and sharing of resources.  Each such infrastructure consists of distributed computing and data resources, users (who may be organised into separate user communities), and a set of policies and procedures.  Examples of such infrastructures include computing grids and/or clouds, as well as cooperating computing facilities managed by different organisations.

Even when such an infrastructure considers itself to be decoupled from other infrastructures, it is in fact subject to many of the same threats and vulnerabilities as other infrastructures because of the use of common software and technologies.  Moreover, there may be users who take part in more than one infrastructure and are thus potential vectors that can spread infection from one infrastructure to another.  Finally, one infrastructure may want to extend rights to use its resources to users who are enrolled in a different infrastructure. In each of these situations, the infrastructures can benefit from working together and sharing information on security issues.  

Security in a distributed collaborative environment is governed by the same principles that apply to a local centrally managed system, but complicated by the diversity of sites (both in terms of hardware and software systems and in terms of local policies and practices that apply), and by the lack of a centralized management hierarchy that can "order" certain operations to be performed in specific ways.

Governing principles include:

• The management of risk; both to mitigate the most likely occurring and dangerous risks, and to take counter measures that are commensurate with the scale of the involved risks
• Containing the impact of a security incident while keeping services operational, but in certain cases this may require identifying and fixing a security vulnerability before re-enabling user access
• Identifying the cause of incidents and understanding what measures must be taken to prevent them from re-occurring
• Identifying users, hosts and services, and controlling their access to resources, all of which must  be sufficiently robust and commensurate to the value of the resources and the level of risk and must comply with the regulatory environment

In this document we lay out a series of numbered requirements in six areas (operational security, incident response, traceability, participant responsibilities, legalities, and data protection) that each infrastructure should address as part of promoting trust between infrastructures.

...