Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Start with words from SCI document version 1

A Trust Framework for Security Collaboration among Infrastructures

http://pos.sissa.it/archive/conferences/179/011/ISGC%202013_011.pdf

( Copyright owned by the author(s) under the terms of the Creative Commons Attribution-NonCommercial-ShareAlike Licence)

 

Workplan

Start with the part related to Incident Response.
Then move to Data Protection.
Afterwards - add behaviour of the Proxy itself, the Community Attribute Authority and credential stores. 

 

 

A Trust Framework for Security Collaboration among Infrastructures

Scalable Negotiator for Community Trust Framework in Federated Infrastructures (Snctfi)

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.

...

Infrastructure

All of the IT hardware, software, networks, data, facilities, processes etc. that are required to develop, test, deliver, monitor, control or support services.

Distributed IT Infrastructure (DII)

An Infrastructure together with its management, Resource Providers and Service Operators. It provides, manages and operates (directly or indirectly) all the services required by the Resource Providers and their collections of users.

Resource

The equipment (CPU, disk, tape, network), software, middleware and data required to run a service.

Service

Any computing, storage, preservation,  or software system which provides access to, information about or controls resources.

Resource Provider

The smallest resource administration domain in a DII. It can be either localised or geographically distributed.

Service Operator

An entity responsible for the management, deployment and operation of a service.

Participant

Any entity providing, using, managing, operating, supporting or coordinating one or more service(s).

User

An individual or an organisation who has been given authority to access and use resources.

 

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.

...

  • 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.

 

To evaluate the extent to which the requirements described in this document are met, we recommend that each infrastructure assess the maturity of its implementation according to the following levels:

 

Level 0:  Function or feature not implemented

 

Level 1:  Function or feature exists, is operationally implemented but not documented

 

Level 2:  Function or feature is comprehensively documented and operationally implemented

 

Level 3:  Function or feature implemented, documented, and reviewed by an independent external body

 

We encourage openness and transparency in the documentation and for Levels 2 and 3 we recommend that wherever possible such documents should be made available to collaborating infrastructures as a way of promoting trust.

ADD sections on behaviour of Proxy/Gateway and associated AA and credential store. Address Sirtfi, DP CoCo, new AARC DNA3.5 Data Protection policy guidance, REFEDS R&S.

ADD Introduction

1. Operational Security [OS]

...

  • [DP1] Accounting Data
  • [DP2] User Registration Data
  • [DP3] Monitoring Data
  • [DP4] Logging Data
  • [DP5] Data owned by or produced by Users or Collections of Users

7. Acknowledgements

The authors acknowledge the support and collaboration of many colleagues in their respective infrastructures and the funding received by these infrastructures from many different sources.

 

These include but are not limited to the following:

 

EGI acknowledges the funding and support received from the European Commission and the many National Grid Initiatives and other members. The EGI-InSPIRE project is co-funded by the European Commission (contract number: RI-261323).

 

The Worldwide LHC Computing Grid (WLCG) project is a global collaboration of more than 170 computing centres in 36 countries, linking up national and international grid infrastructures. Funding is acknowledged from many national funding bodies and we acknowledge the support of several operational infrastructures including EGI, OSG and NDGF.

 

PRACE: The research leading to these results has received funding from the European Union Seventh  Framework Programme (FP7/2007-2013 ) under grant agreements n° 261557 and n° 312763.

 

We acknowledge the contribution of the CHAIN project (Grant Agreement n. 260011) co-funded by the European Commission under the 7th Framework  Programme.

 

The Extreme Science and Engineering Discovery Environment (XSEDE) is supported by the National Science Foundation.

 

Fermilab: Work supported by the U.S. Department of Energy under contract No. DE-AC02-07CH11359.

8. References

[1] ISO 27000 series of information security standards. http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=56891

[2] NIST 800-53 series of standards. http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf

[3] http://www.eugridpma.org/sci/

[4] http://www.igtf.net



[1] For software agents initiating actions there must be a human individual responsible for all actions of the agent

[2] Examples include but are not limited to: Registration or renewal in a membership system, dynamic authorisation such as acquisition of VOMS attributes, authentication to a Science Gateway or portal, job submission or file transfer initiated by the Collection on behalf of an individual user