Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

EGI CSIRT:Central emergency suspension

From EGIWiki
Revision as of 10:58, 4 July 2013 by Sveng (talk | contribs)
Jump to navigation Jump to search

Meetings, Minutes

06.11.2013 Editorial Access/Management/Maintenance of the suspension list content.

Tasks / Subtasks

The following table provides status information on the Subtasks/Milestones

Task
Description
Partner
Target Date
Finished
MS1
Repository providing emergency suspension information in Argus policy format and in plain text.(existing Central Argus Server at CERN)
The following components are needed:
1. Interface to edit the suspension list, access limited to EGI-CSIRTs IRTF and WLCG security
2. Server that provides the suspension list in plain text, access to the suspension information limited to named individuals with the proper role in GOC-DB
3. Central Argus Server
CERN
June 2013
X  %
MS2
Interface to GOC-DB that provides role based information on who is allowed to access the emergency suspension information.
STFC
June 2013
X  %
MS 3
Tools that securely download the emergency suspension information
This Task depends on MS1 and MS2
During test phase current Argus sites already using the CERN Argus server should not need additional intervention.
The tool set for non Argus sites consists of:
1. Croned Download mechanism of the suspension information from the repository set up in MS1
2. Example processor to implement suspension information in fabric management tool quattor
FOM
August 2013
X  %
MS4
Testing/Monitoring, first tests will be done within 1 week after MS-3, no fixed end date though, since progress will be monitored
FOM
September 2013
X  %


Sites using the Central Argus Server at CERN

Romain should have this information

Status Argus implementation in EMI/UMD Middelware services

The functionality of the Argus implementation in EMI3/UMD is currently tested in the stage rollout by Joao Pinta. The results of his tests can be found at: Middleware argus interoperability

Central emergency suspension procedure

The document describing the central emergency suspension procedure is available at EGI CSIRT Operational Procedure for Compromised Certificates. This document is currently in DRAFT it will be finished in May and presented at the May OMB, requesting approval by OMB.

Argus Deployment Scenario


Project Description as approved by Management

The concept of ther emergency suspension framework was presented at the February OMB meeting

Implementation and testing of emergency suspension in the European Grid Infrastructure

Project leader: FOM (NGI_NL) Project partners: FOM (NGI_NL), STFC (NGI_UK)

Overview of the Proposed Technical Activity and its Strategic Impact

An emergency suspension facility would bring an important contribution to EGI’s strategic goal operating a secure infrastructure. Therefore all EGI users as well as the resource center admins would be the beneficiaries of this work.

This mini-project addresses the problem, that it is currently not possible for EGI to reliably suspend/ban a user DN from the infrastructure. Various Security-Service-Challenges have shown that, even under optimal conditions (office hours) approximately one quarter of the sites don't properly suspend a reported DN from their infrastructure. One problem here is that the current mechanism relies on the availability of technical experts at every site. In global projects like EGI where the resources are managed during office hours, time critical operations (like suspending a compromised account) which need to be reliably executed at all resource centers in a timely manner -also out of office hours-, should be automated. The main strategic and technical outcome here would be to have distributed operations automatized, and initialized from a central instance. In particular it should be possible to achieve a more efficient access management for security purposes. The progress towards a more efficient access management for security purposes can be monitored with the framework developed for the Security-Service-Challenges. The monitoring will contain "number of vulnerable services" over "time", which is expected to be reduced in course of this project. For this monitoring no contributions from the sites will be needed.


Technical workplan Development of emergency suspension information deployment tools to cover mechanisms to process and retrieve the emergency suspension information in different ways and formats, consists of the following tasks:

  1. Repository providing emergency suspension information. (CERN)
  2. Tools that process the emergency suspension information so that it can also be used by services which are not ARGUS aware. (CERN)
  3. Tools that securely download the emergency suspension information (1 week, FOM)
  4. Interface to GOC-DB that provides role based information on who is allowed to access the emergency suspension information. (2 weeks, STFC)
  5. Testing (1 week, FOM, this will consist of several rounds) 6. Documentation. (FOM)

At the beginning of the mini project the currently deployed ARGUS infrastructure would be used to develop and test the needed tools. After successful tests it might be needed to modify the ARGUS server deployment, as described in the following points.

Design phase

Sites and services that are Argus aware can use the emergency suspension policies provided by the central Argus service at CERN, via a site local Argus server or a NGI Argus server, which in turn retrieve the emergency suspension policies from the central Argus instance at CERN. During the test phase, selected sites can directly use the central Argus Server at CERN. In addition, for peer grids, services or sites which are not ARGUS-aware a central repository is needed, serving the emergency suspension list in a generic file format to authorised entities. A tool will be made available to the sites that automatically fetches the emergency suspension list and triggers further action in case the content of the file has changed. Depending on the sites set up the emergency suspension information be used by processing and deploying the downloaded file with the help of the local fabric management system.

Development and deployment phase

This phase includes all the necessary components identified during the first phase: A translation script to produce a generic ban list querying the central EGI ARGUS. A repository to be accessed only by authorised entities to download the list produced by the script. Once the developed tools are available, they must be deployed centrally to be available for the EGI resource centres.

During this phase the project will also develop a set of documentation and best practices to automatically propagate the emergency suspension list to the services. An example configuration using the fabric management system quattor for processing the emergency suspension file and deploying it to the local systems will be given.

Testing/Monitoring

Test the infrastructure and monitor the deployment progress The testing and monitoring phase starts when the emergency supsension information distribution mechanism is deployed at the participating EGI sites, and the documentation and best practices have been disseminated. EGI-CSIRT will use the security monitoring framework to test if the automated central banning is working as expected and to detect eventual problems.

This is a continuous activity that should bring, in one year time, 80% of the participating sites automatically performing emergency user suspensions.

Documentation The documentation will consist of man pages for the developed tools, in particular for those deployed at the sites which will fetch the ban list. Further documentation, in form of wiki guides, will cover instructions for the sites on how to obtain the emergency suspension list and selected examples on how to use these for a few basic services, e.g. for import into a fabric management tool for sites/services that do not use Argus. The use and deployment of the Argus server at the site level we consider to be sufficiently documented. In addition, a service guide for the central-emergency-suspension- service operator will be available.

Milestones
MS-1 (CERN)

- Repository providing emergency suspension information. (CERN) - Tools that process the emergency suspension information so that it can also be used by services which are not ARGUS aware. (CERN)

MS-2 (STFC)

- Interface to GOC-DB that provides role based information on who is allowed to access the emergency suspension information. (2 weeks, STFC)

MS-3 (FOM, depends on MS-1,2)

- Tools that securely download the emergency suspension information (1 week, FOM)

MS-4 (FOM, depends on MS-3)

- Testing/Monitoring, first tests will be done within 1 week after MS-3, no fixed end date though, since progress will be monitored

MS-5 (FOM)

- Documentation (1 week FOM)


Project budget

Name Affiliation Effort contributed (PM) Direct Cost Indirect cost EC contribution
Sven Gabriel, David Groep FOM
0.5 2,500 € 1,500€ 2,675€
TBC STFC STFC
0.5
2,505€ 2,630€ 2,680€
Total
1
5,005€ 4,130€ 5,355€