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.

Difference between revisions of "EGI CSIRT:SMG"

From EGIWiki
Jump to navigation Jump to search
Line 1: Line 1:
{{egi-csirt-team-header|Security Monitoring Group}}
{{egi-csirt-team-header|Security Monitoring Group}}


== Objective==
== Long-term Objectives==
Security monitoring is a key component to security. It may enable the service managers to prevent, detect and contain security incidents as well as to detect weak spots in the infrastructure before they get misused. The EGI CSIRT contributes to security monitoring by developing a monitoring tools, promoting existing tools, performing security tests against the sites and providing advisories about deployment and usage of the tools.
Security monitoring is a key component to security. The EGI CSIRT works to
provide the EGI security staff with tools and procedures to detect and
contain security incidents as well as weaknesses that could lead to a
compromise. In doing so, the EGI CSIRT collaborates closely with the sites
and NGI, however it does not provide replacements for site and NGI level
monitoring. Even though the results developed are primarily ment for EGI,
they should be designed and developed so that they could be utilized on the
site and/or NGI level as well.


== Goals of security monitoring ==
The EGI CSIRT strives to collect various information from the
The EGI CSIRT strives to provide both high-level overviews summarizing current status and detailed information about particular issues identified in the infrastructure. While closely collaborating with the NGIs and sites, the EGI CSIRT does not provide a replacement for site and NGI level monitoring, however, the EGI CSIRT will recommend a basic set of monitoring tools that the NGIs and sites can use for security monitoring. In addition, the EGI CSIRT operates its own monitoring tools collecting information from the sites. The probes used are not intrusive and do not attempt to circumvent any security mehanisms and are not resource intensive. Results collected by these probes are only available to the EGI CSIRT members and communicated to the appropriate site security contacts.
infrastructure, even using own probes and sensors or by combining results
generated by other systems (e.g., accounting) on different levels of the
infrastructure. The data collected will be evaluated based on current needs
and risks, and alarms raised accordingly. The security monitoring system
will provide both high-level overview to get a quick notion about the
infrastructure as well as a sufficient level of details necessary to sort
out security issues detected. The system will archive and evaluate history
to follow and forecast trends in security.


Main tasks of the activity:
Security monitoring will also provide mechanisms and tools to assist inincident containment, for example to gather important log records.
* Patch management using [http://pakiti.sf.net/ Pakiti]
Information about users' activities will be used to identify last actions
* Tracing activities of the users
performed by a user to e.g. estimate the sites possibly infected. A way of
* Integration with Nagios
(semi)automated processing of alerts and warnings issued by the EGI security
* Security monitoring dashboard
groups will be investigate and possibly developed.
 
In order to accomplish the objectives, the EGI CSIRT will develop own tools,
mainly to grid specific areas and use existing tools if possible and adviseon their usage. Developed probes are not intrusive and do not attempt tocircumvent any security mehanisms and are not resource intensive. Results
collected by these probes are only available to the EGI CSIRT members and
communicated to the appropriate site security contacts. We will also provide recommendations and advisories to the sites and NGI as to how to combine
existing technologies to provide efficient local security monitoring. When
applicable, collaboration will be established with similar groups of NREN
CSIRTs.
 
== Tasks ==
The lists of action at each task are not definite and will be discussed further
 
=== Monitoring of security patches using [http://pakiti.sf.net/ Pakiti] ===
* finer access control, e.g., based on information from GOC DB
* Generating statistics and reports
* Tagging of and notifications (alarms) about severe vulnerabilities
* Producing OVAL format for EGI advisories (e.g. SVG ones) and their processing
* Support NGIs in setting a local instances of Pakiti
* Integration with existing monitoring frameworks (Nagios)
* Pakiti server verification
* Integration with dashboards, UI improvements
* Operation of the EGI Pakiti server at CESNET
 
=== Security monitoring with Nagios ===
* Development of new probes (based on risk analysis and experience with previous incidents)
* Support for short-lived "dynamic" probes (if needed) (a procedure and template for a quick introduction of new "volatile" probes testing some very particular characteristics, which needs a fast reaction
* guides, docs for NGIs/sites
* operation of the CSIRT Nagios instance at GRNET
* Handling of results (raising alarms, sending notifications, access control to results, ...)
* Integration of security probes with standard Nagios (securing results, ...)
* Integration with dashboards
* Evaluation of results from multiple different sources
* Aggregating security alerts in a single place
 
=== Tracing users ===
* Tools to collect information about users from multiple sources (L&B, accounting, logs)
* Evaluation of this data to trace users' last steps on demand
* Evaluating log records produced by grid middleware (including checking that components logs appropriate information)
 
=== Site level tools ===
* recommendation for setting up a central syslog server
* specification of filters for the syslog
* (semi)automatic processing of EGI security advisories (checking logs for IP addresses, DNs, ...)
* best practises for log maintanence
 
=== Security Dashboard ===
* providing a single place to overwiew current status, history and provide additional details
* integration with existing EGI dashboards and appropriate frameworks will be evaluated


== Persons ==
== Persons ==

Revision as of 16:00, 12 July 2010

EGI-CSIRT wiki

public team pages| Incident Response Task Force (IRTF) | Security Drills Group (SDG) | Security Monitoring Group (SMG) |
public pages | Mission | Incident reporting | Dissemination | Alerts | Operational notices | Monitoring | Security challenges | Policies | Contacts |

Security Monitoring Group


Long-term Objectives

Security monitoring is a key component to security. The EGI CSIRT works to provide the EGI security staff with tools and procedures to detect and contain security incidents as well as weaknesses that could lead to a compromise. In doing so, the EGI CSIRT collaborates closely with the sites and NGI, however it does not provide replacements for site and NGI level monitoring. Even though the results developed are primarily ment for EGI, they should be designed and developed so that they could be utilized on the site and/or NGI level as well.

The EGI CSIRT strives to collect various information from the infrastructure, even using own probes and sensors or by combining results generated by other systems (e.g., accounting) on different levels of the infrastructure. The data collected will be evaluated based on current needs and risks, and alarms raised accordingly. The security monitoring system will provide both high-level overview to get a quick notion about the infrastructure as well as a sufficient level of details necessary to sort out security issues detected. The system will archive and evaluate history to follow and forecast trends in security.

Security monitoring will also provide mechanisms and tools to assist inincident containment, for example to gather important log records. Information about users' activities will be used to identify last actions performed by a user to e.g. estimate the sites possibly infected. A way of (semi)automated processing of alerts and warnings issued by the EGI security groups will be investigate and possibly developed.

In order to accomplish the objectives, the EGI CSIRT will develop own tools, mainly to grid specific areas and use existing tools if possible and adviseon their usage. Developed probes are not intrusive and do not attempt tocircumvent any security mehanisms and are not resource intensive. Results collected by these probes are only available to the EGI CSIRT members and communicated to the appropriate site security contacts. We will also provide recommendations and advisories to the sites and NGI as to how to combine existing technologies to provide efficient local security monitoring. When applicable, collaboration will be established with similar groups of NREN CSIRTs.

Tasks

The lists of action at each task are not definite and will be discussed further

Monitoring of security patches using Pakiti

  • finer access control, e.g., based on information from GOC DB
  • Generating statistics and reports
  • Tagging of and notifications (alarms) about severe vulnerabilities
  • Producing OVAL format for EGI advisories (e.g. SVG ones) and their processing
  • Support NGIs in setting a local instances of Pakiti
  • Integration with existing monitoring frameworks (Nagios)
  • Pakiti server verification
  • Integration with dashboards, UI improvements
  • Operation of the EGI Pakiti server at CESNET

Security monitoring with Nagios

  • Development of new probes (based on risk analysis and experience with previous incidents)
  • Support for short-lived "dynamic" probes (if needed) (a procedure and template for a quick introduction of new "volatile" probes testing some very particular characteristics, which needs a fast reaction
  • guides, docs for NGIs/sites
  • operation of the CSIRT Nagios instance at GRNET
  • Handling of results (raising alarms, sending notifications, access control to results, ...)
  • Integration of security probes with standard Nagios (securing results, ...)
  • Integration with dashboards
  • Evaluation of results from multiple different sources
  • Aggregating security alerts in a single place

Tracing users

  • Tools to collect information about users from multiple sources (L&B, accounting, logs)
  • Evaluation of this data to trace users' last steps on demand
  • Evaluating log records produced by grid middleware (including checking that components logs appropriate information)

Site level tools

  • recommendation for setting up a central syslog server
  • specification of filters for the syslog
  • (semi)automatic processing of EGI security advisories (checking logs for IP addresses, DNs, ...)
  • best practises for log maintanence

Security Dashboard

  • providing a single place to overwiew current status, history and provide additional details
  • integration with existing EGI dashboards and appropriate frameworks will be evaluated

Persons

Coordinator

  • Daniel Kouril (kouril@ics.muni.cz), Czech Republic NGI

Participants

class="sortable"
Name NGI Home Organization Effort Available (PM)
David O'Callaghan Irland NGI TCD
Christos Triantafyllidis Greek NGI
Jinny Chien - ASGC
Daniel Kouril Czech Republic NGI CESNET
Michal Prochazka Czech Republic NGI CESNET
Dusan Vudragovic Serbia NGI AEGIS
Angela Poschlad German NGI KIT
Bartlomiej Balcerek Poland NGI WCSS (CYFRONET) 4
Emir Imamagic Croatia NGI
Riccardo Brunetti Italy NGI INFN
Guiseppe Misurelli Italy NGI INFN
Dorine Fouossong France NGI
Feyza Eryol TR NGI TUBITAK-ULAKBIM
Retrieved from "https://wiki.egi.eu/w/index.php?title=EGI_CSIRT:SMG&oldid=1655"