Security drills framework

From EGIWiki
Revision as of 16:40, 16 October 2012 by Krakow (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Security Drills Framework

The Security Drills Framework is basically a web application consisting of four major functional blocks.

Communication:

The communication during SSCs is done with RT-IR, a ticketing system (RT) with extensions for Incident-Response (IR) teams. Here several modifications had to be done to integrate with the EGI infrastructure, as for example interfacing with the GOC-DB, which contains the Resource-Centre contact information

Job Submission:

There are various job submission methods used in EGI,involving different middleware services and access control mechanisms.

The standard method would be using glite services to send a job to either via a Workload Management Systm (WMS) or directly to a CREAM-CE Ssc-mon-components.png

RT-IR: Alerting - Reporting - Communication

The Security Drills Framework is basically a web application consisting of four major functional blocks. Communication: The comminication during SSCs is done with RT-IR, a ticketing system (RT) with extensions for Incident-Response (IR) teams. Here several modifications had to be done to integrate with the EGI infrastructure, as for example interfacing with the GOC-DB, which contains the Resource-Center contact information. In the following picture it is shown the workflow diagram of how a EGI CSIRT member will proceed to handle an SSC5 incident.

Workflow-SSC.png

This SSC5 workflow diagram is a subset of the EGI-CSIRT Incident-Response flowchart, adapted for using RTIR in the handling process of the SSC5 class incidents. As you can see the SSC Launcher is opening a Incident and a Investigation for alarming a site about an issue that has been found at a particular site. According to our poicies and following the EGI Incident Response Procedure, the site should react promptly, and try to discover the activities on the sites resources related to the reported incident. As soon as all required information is gathered, the site security officer should report this information back to EGI- and NGI-CSIRT, as its NGI Security officer will be on the Cc of the Investigation, the site will be able to ask for help, in case of its needs. The NGI-Security officer should take care that the proper actions are taken at the sites in his NGI and that the information flow to/from EGI-CSIRT is working properly.

Analysing the information sent by the site, the EGI-CSIRT Incident-Handler will take the proper actions for mitigating the incident, and solving it. For example, the EGI-CSIRT member could contact the CERT responsible for the WMS (a site hosting this service, or a VO running a VO-Job-submission-framework) to determine if the malicious job run at the site, was also submitted to other Grid sites of the EGI, and possibly other Grid infrastructures. In case of yes, the EGI-CSIRT Incident-Handler will be contact the likely affected sites and its NGI-Security-Officer, asking to react accordingly. He/She could also ask for taking the needed actions for bouncing the DN of the job from the VO. In a real case scenario all sites would be asked to check for activities related to a particular user certificate and adapt their user management settings accordingly.

Job Submission

Job status and Security Operations Monitoring