Operational security in EGI

A central entity aimed at coordinating the operational security activities in the infrastructure, in particular response to security incidents, has been documented in the EGI_DS. This functionality is implemented and indentified below as the "EGI CSIRT" activitiy.

EGI CSIRT strategy

It is essential to ensure a coherent and comprehensive collaboration, at the operational security level, between all the resource providers of the EGI user community.

As security incidents may affect any resource providers, inside or outside EGI, the appropriate procedures, information flow and a collaboration based on trust have to be implemented to ensure security incidents are dealt with appropriately by the resource providers and the involved CSIRTs.

The large number of resource providers and the infrastructure topology requires a structured approach to be adopted, based on the different levels. From bottom to top:

• Site CSIRT (hundreds, usually one per site)
• NGI CSIRT, NREN CSIRT (tenths, the degree of interaction between NGI and NREN CSIRT varies)
• Main academic grid CSIRT (units)

As a result, the EGI CSIRT ensures both the coordination with peer grids (via its GRID-SEC membership), and with the NGIs and NREN CSIRTs.

EGI CSIRT mission

The main objective of the EGI CSIRT is to provide the EGI infrastructure with incident response capabilities across the participating NGIs.

By implementing a number of procedures, technical means and appropriate communication channels, the EGI CSIRT ensures that that all incidents are investigated as fully as possible and that sites promptly report intrusions. In particular, security incidents are to be treated as serious matters and their investigation must be resourced appropriately.

In addition, the EGI CSIRT acts as a forum to mutualise efforts and resources from the NGIs in different areas:

• Grid security monitoring
• Security training and dissemination
• Incident response improvement (ex: security drills)

EGI CSIRT regulation

The activities and mandate of the EGI CSIRT are regulated by a set of security policies approved by EGI. Additional security procedures are implemented and agreed by the project via the appropriate approval process.

EGI CSIRT membership

Each NGI appoints a "NGI Security Officer" in order to provide the NGI CSIRT function:

• Coordinate the security activities within the NGI
• Ensure the coordination of the resolution of security incidents in the NGI
• Contribute to the EGI CSIRT
• Act as a contact point for security issues in the NGI for the rest of the infrastructure
• Participate in the EGI security groups as necessary

A number of NGIs are implementing this functionality via their local NREN CSIRT. When this is not the case, a close collaboration with the local NREN CSIRT is highly encouraged.

The resulting group of NGI Security Officers collaborate as part of the EGI CSIRT.

The EGI CSIRT is lead by the EGI security officer, whose role and mission are defined by security policies approved by the NGIs.

MW Security in EGI

Organization

The UMD middleware security team is organized around the middleware product teams and consists of a core group and an extended group (see figure):

• The core group consists of middleware security experts from each supported middleware stack (ARC, gLite, Unicore). The core group is lead by a team of three (one per middleware stack) with the lead person alternating on a regular basis.

• The extended group consists of the core group plus one security liaison person from each product which does not already have a member in the core group. The purpose of the liaison person is to establish the communication between product teams and core security group.

Initially, it is expected that the collaboration between the ARC, gLite and Unicore core security group is rather loose. However, with increasing harmonization we expect the firm establishment of the UMD middleware security group. The goal within EGI is that all middleware stacks use the same security components wherever feasible.

Collaboration

The UMD middleware security group collaborates with other middlewares and projects that are using their products. They are invited to attend the UMD security meetings. The collaboration with other middlewares that are not using UMD products is done through the OGF working groups.

Joint Security Policy Group in EGI

The current JSPG (http://www.jspg.org) mandate includes:

• JSPG is jointly owned by and makes recommendations to both WLCG and EGEE, its primary stakeholders.
• The most important JSPG activity is that it prepares and maintains security policies for its primary stakeholders.
• JSPG should, wherever possible, aim to prepare simple and general policies which are not only applicable to the primary stakeholders but that are also of use to other Grid infrastructures (NGI's etc). The adoption of common policies by multiple Grids can ease the problems of interoperability.

The need to continue this function is recognised in the EGI Blueprint in Section 3.1: "In a European e-Infrastructure, coordination will be required on security policies and operational security to support and coordinate the work of teams drawn from the NGIs." In the table of EGI.ORG tasks and resources, 0.5 FTE is foreseen for security policy coordination: "Security policy development and maintenance to define agreement on best practice and security policies, CA policies (EUgridPMA) etc. (EGI.ORG + NGI). A team of security people in NGI's will take care of ensuring the definition and application of standard security policies - EGI.org support and coordination"

Proposed plans for JSPG in EGI:

• Keep the name. Well known "brand". Joint will still be true; joint amongst NGIs, joint with other major Grids, joint to include major User/Application communities or VOs.
• JSPG's primary stake-holders will be internal to EGI, i.e. the NGIs, the sites and the application communities. But must continue to aim for common simple policies for interoperation across the world. External links are therefore still important. Submit new policies to IPG for discussion and feedback.
• The membership must continue to contain not just NGI reps, but also (some) Site managers, VO managers, middleware experts, operations experts, operational security etc.
• Foresee two JSPG bodies. Document revisions and new docs should be prepared by a small(ish) editorial team. For discussion in a larger (with fuller representation) JSPG body. This may not actually meet face to face very often.
• As now, JSPG policy should supplement local NGI policy, not replace it. JSPG policy should be the small set of rules and requirements to allow NGIs to interoperate, and more importantly allow international VOs to easily use resources across EGI, and indeed across the world.
• important to consult widely with sites and VOs, not just NGIs (NGIs may lead this consultation within their country). Formal adoption of policy should be by a suitable policy board (EGI Council?) and not JSPG itself, otherwise JSPG will become too policitical and this will stifle policy innovation.

The Grid Security Vulnerability Group (GSVG) in EGI

As the Grid progresses to the EGI stage and it's profile and extent expands it becomes ever more important to ensure that the Grid Software and Deployment is as secure and free from vulnerabilities as possible. The main purpose of the Grid Security Vulnerability Group is to eliminate exisiting vulnerabilities from the deployed infrastructure, primarily from the grid middleware, and prevent the introduction of new ones. The aim is to prevent Grid Security incidents.

In EGI, it has been stated that Middleware will be distributed as part of the Unified Middleware Distribution (UMD). The GSVG will be part of the EGI Security Operations, yet will need to interact strongly with development teams and the UMD co-ordination as well as with Security Operations. GSVG will draw members from both the operational teams and development teams, but will be situated in the Operational Security area in order that it should be recognised as a means of ensuring security of the deployed infrastructure and enforcing the responsbible disclosure strategy.

Issue Handling

A simple method whereby anyone can report a potential Grid Security Vulnerability issue found in the UMD distribution or the deployed infrastructure and be confident that the issue is investigated and handled in an appropriate manner will needed. The method will largely be based on what has been established in EGEE, with changes according to both lessons learnt and the EGI setup. The principle should remain that:

• Anyone can report an issue
• The Risk Assessment Team (RAT) carries out an investigation and Risk Assessment.
• A Target Date (TD) is set according to the Risk.
• An advisory is provided when the issue is resolved or on the Target Date, whichever is the sooner. This is considered to be 'responsible disclosure'.

The most important aspect of the GSVG issue handling is to provide a risk assessment, so that issues can be appropriately prioritized and fixed in a timely manner. Reporting to GSVG ensures that issues can be kept private while they are investigated and if appropriate fixed in a timely manner.

In EGI the GSVG will need to have defined contact points with each software provider from which the software is built. There also needs to be an expectation of turnaround time in response to the report of a vulnerability concerning that software, along with agreement that the Grid Security Vulnerability issue handling process will be applied to that software along with the responsible disclosure strategy. These should be part of the MoU with the provider. Additionally, if software providers find and fix vulnerabilities in their own software they should agree to provide the patched versions to the UMD and co-ordinate the release of patches and advisories with UMD/EGI.

• EGI-GSVG-2nd.jpg:
  

The GSVG chair along with 2-3 deputies will co-ordinate the running of the process. These will be supplied by various NGIs. A number of RAT members will also need to be supplied from the development teams, the NGI site administrators and deployment teams, or other security experts. This group of people will establish the exact methods and criteria for carrying out the handling process. This will both encourage people to join in with the process so that they can help establish the criteria, and provide a broad acceptance of the criteria across EGI.

This central GSVG issue handling process will also ensure a reasonable degree of Uniformity of the Risk Assessment and issue handling process across EGI.

GSVG Transition from EGEE to EGI

A description of the principles of the issue handling strategy in EGI will be produced, this should be approved by EGI management. This document can be written in 2009 and approval should take place before April 2010.

As the method for distributing software for EGI is established, through the UMD or whatever the method is, including the bug handling strategy, the details of the EGI issue handling process will be establised and documented. This can be provisionally drafted in 2009, but adjustment will need to be made as the actual methods become established.

When a software provider agrees to be part of the EGI distribution they should additionally

• Provide contact details for developers for investigating an issue
• Agree to a response time, and co-operation on the investigation of potential vulnerabilities
• Agree that issues are handling using the approved strategy including the responsible disclosure strategy
• Agree to co-ordinate the distrubution of patches with EGI if they themselves find and patch a vulnerability
• Decide whether they are able to provide manpower (e.g. in the form of a RAT person) to GSVG.

Once middleware is distributed by EGI/UMD any vulnerabilities in that middleware will be handled using the EGI strategy - i.e. the transition to EGI for vulnerability handling will happen as the transition to distribution from EGI happens. The speed of transition of the GSVG issue handling will largely depend on when software becomes distributed by EGI rather than by the current methods.

NGI's and sites will be invited to provide RAT members and/or co-ordination members to the GSVG.

Ensuring deployed middleware is secure

As well as handling specific vulnerabilities found, it is important to actively check that the deployed middleware is secure. This may be done by training some people and developing expertise in assessing code for vulnerabilities. This could also involve inviting people to find vulnerabilities, including possible peer recognition for those finding the most serious vulnerabilities.

Developer Training

There is an education role for GSVG within the developer community to improve the quality of the deployed software that also needs to be fulfilled. It is important to ensure developers are educated in secure and defensive coding in order to prevent the introduction of new vulnerabilities.