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:Security challenges

From EGIWiki
Revision as of 15:10, 18 May 2011 by Dfouosso (talk | contribs)
Jump to navigation Jump to search


| Mission | Members | Contacts
| Incident handling | Alerts | Monitoring | Security challenges | Procedures | Dissemination



Security challenges: what is expecting from sites ?

What is important to bear in mind ?

The sites contacted for a challenge are asked to follow the normal security incident response procedure, and react exactly as if the incident was real, with the two following exceptions:

      1. No sanctions must be applied against the Virtual
         Organization (VO) that was used to submit the job.

      2. All "multi-destination" alerts must be addressed to
         the e-mail list which has been designated for the test:

              ssc-monitor@zwaan.nikhefhousing.nl

         DO NOT use:
                     abuse@egi.eu

         for Security Service Challenges. Instead, insert the
         originally intended "multi-destination" address(es) in
         the body of your message.

What is the normal security incident response procedure?

PLEASE REMIND THAT FOR THE CHALLENGE
THE PROCEDURE IS APPLIED WITH RESTRICTIONS
STATED IN THE PREVIOUS SECTION

The site checklist for incident response procedure is :

Checklist-screenshot.png

More informations about EGI security procedures ( flowchart, formal document, ... ) can be found here : https://wiki.egi.eu/wiki/EGI_CSIRT:Policies

Information to be gathered at the sites

For an initial response and first directions answers to the following questions might be useful.

  • NETWORK:
- Are there any other suspicious connections open? If so to which IPs

- Is network monitoring data (e.g. netflows) available?
  • CONTAINMENT:
- Does the process belong to a batch job or an interactive login?

- From where was the login/job submission done?

- In case it is a Grid-Job, the following questions are important:
   -To which VO is the user/certificate affiliated?

   - Which grid-certificates (DN) are involved in this test-incident?
   # Example: DN-1: CN=John Doe, O=<SomeInstitute>,O=<Something>, ..."

- Since when were the jobs running?
# Example: YYYY:MM:DD hh:mm
Date:


The sites should provide the security teams asap with this information at latest within one working day. The time needed to pass this information to EGI-CSIRT by replying to the alarm mail will be measured and evaluated. Replying to the alarm mail will automatically use the above sketched RTIR system.

Evaluation - Report generation

We distinguish between 1) Measurable per site operations:

  1. initial feedback: 4h
  2. found malicious job/processes/stop them: 4h
  3. ban problematic certificate: 8h
  4. contain the malicious binary and sent it to the incident-coordinator: 24h

These will be measured by the ssc-monitor and the points the sites get are calculated according to the formula stated on the wiki page. Times are relative to the alarm to the site, we try to make sure that the alarms will be send during office-hours (09:00 - 18:00, local time). The target times might change, will be in the final version on the wiki page.

2) Collaborative investigations: Since we want to achieve cross site communication, and possibly collaboration on the malware forensics the evaluation schema has changed accordingly. I..e Network forensics are needed, but we don't measure this, since due to the overall SSC set-up, most of this information should already be available to the "more western" sites relative to the initially alarmed sites.

ban/unban of the pilot-job-submitter DN is based on local policies. It will not be measured, but a statement on the decision, whether to ban/unban the pilot-job-submitter or not, is expected.

Security challenges: how is it operated ?

Objectives

The goal of the EGI-CSIRT Security Drills, is to investigate whether sufficient information is available to be able conduct an audit trace as part of an incident response, and to ensure that appropriate communications channels are available.

Tools

A framework has been developped to automate the operation of EGI security challenges.

The release of may 2011 contains: the panda framework for job submission, a prototype of the new EGI-CSIRT ticketing system based on RTIR.

More informations about the framework are given below.

Post processing, clean up

As part of the incident handling, Grid authorizations may have been withdrawn from the DN that was used to submit the job. When the incident response procedure is complete, the test operator will explicitly request restoration of any such authorizations to their original state.

De-briefing

When the challenge has been completed on a representative number of Sites, the test operator will ask for de-briefing input from the participating Sites. Material submitted will be used to edit a report. The report will be circulated to the contributors for comments before being presented to the EGI-CSIRT.

Security Drills Framework

RT-IR: Alerting - Reporting - Communication

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