![]() |
WP4 Clearinghouse |
(Partner) (Project) (News) (Background) (Service) | |
eCSIRT.net > Service > Documents > WP4 Userguide |
The statistical processor for the type 1 & 2 statistics of the eCSIRT.net was implemented as an enhancement of the webserver of the existing communication infrastructure. All modules of the function are running on LINUX based plattforms and placed in a safe environment. The main components of the statistical processor are: |
![]() |
According to the specifications of the WP4 Clearinghouse Policy two web-forms were prepared for the type 1 and type 2 statistics. These forms were developed with the Common Gateway Interface, or CGI, a standard for external gateway programs to interface with HTTP information servers. The following Web-forms are available:
The processing of the statistical data is carried out on a fixed day each month automatically. In principle, the processing which is steered by a configuration file can be subdivided into three steps:
The results of the processing can be seen on the following pages:
Because of the sensitivity of the exchanged data some general requirements hold for the Clearinghouse Function. These are mostly concerned with the protection of integrity, authenticity and confidentiality. The submission of and access to the statistical data is managed using X.509-certificates and SSL/TLS-encrypted and authenticated connections. The management of X.509-certificates (eg. distribution of certificates, accepting of revocation requests) will be based on the data already collected in the TI accreditation framework. Therefore, the following information is needed for taking part in the statistics:
This information must be sent to the eCSIRT.net project management in a secure manner. In each case the responsible person receives as an answer a signed and encrypted e-mail with the following information:
Participation in the Clearinghouse Function is restricted to teams that either are:
All participating CSIRTs must sign the eCSIRT.net Code-of-Conduct and fill out the registration form.
The public statistics are publicly accesible. Teams submitting data for one of the types of statistics get access to the internal statistics of this type. The raw submitted data will not be made available.
After connection establishment and successful authentication at first general information has to be entered on each form.
General Data | |||
Time period of submitted data: |
The input of the corresponding time period is necessary so that later corrections of the values is possible. Against this the name of the team is stored automatically during the authentication process. By this it is guaranteed that no wrong data can be entered.
After entering the required data into the given web-form the data is first submitted and presented again to be checked for bugs. After checking the data has to be submitted again to be stored on the system. Further information to the data input can be taken from the following sections.
The following data fields were agreed for the collection of eCSIRT.net type 1 statistics (Version 2). During an internal review of WP4 it was generally felt that some of the data fields did not refer well enough to the data collected by most of the teams. Therefore a redefinition of some fields was carried out. The description of the data fields represents the common understanding after the internal review.
Incident and Report related data | Description: | ||
1) Total number of requests: | The number of all non-automated requests received by the team. These requests include as well all non-incident handling requests but no automatically generated messages (i.e. IDS) however. | ||
2) Incidents opened: | The number of all incidents opened that month. An opened incident announces activities which are carried out in reaction to an incident (also known as Incident Response). | ||
3) Incidents closed: | The number of all incidents closed that month. According to the definition of an opened incident the completion of the activities is announced by a closed incident. | ||
4) Inbound incident related communication: | The number of inbound communication contain all reports (Email, Fax, Phone, ...) recieved by a team which constitute part of an incident, counted at 2. | 5) Outbound incident related communication: | The number of all reports (Email, Fax, Phone, ...) sent by the team which constitute part of an incident, counted at 2, are understood as outbound communication. |
Organizations involved | |||
6) Organizations involved: | The number of all organisations, which were involved in the incidents counted at 3, each site should only be counted once per incident. | ||
Amounts of time spent | |||
7) Time spent: | The amount of time in hours spent for incident response. | ||
This classification scheme is used for the collection of eCSIRT.net type 2 statistical data.
Each Incident has one primary type (so the numbers given for primary type add up to the number of all incidents). However, additional or secondary incident types can happen in the context of an incident. But these aren't taken into account here.
Example: After a successful intrusion the attacker gains root privileges on a system. As a result of it he gets access to sensitive information. The primary type of this incident is an "intrusion" (incident class) with a "privileged account compromise" (incident type). All further events which are based on this intrusion should be not registered.
The following table shows the current used eCSIRT.net incident classes and types for type 2 statistics and gives some additional descriptions or examples:
Incident Class (mandatory input field) |
Incident Type (optional but desired input field) |
Description / Examples |
Abusive Content | Spam | or "Unsolicited Bulk Email", this means that the recipient has not granted verifiable permission for the message to be sent and that the message is sent as part of a larger collection of messages, all having an identical content. |
Harassment | Discreditation or discrimination of somebody (i.e. Cyberstalking) | |
Child/Sexual/Violence/... | Child Pornography, glorification of violence, ... | |
Malicious Code | Virus | Software that is intentionally included or inserted in a system for a harmful purpose. A user interaction is normally necessary to activate the code. |
Worm | ||
Trojan | ||
Spyware | ||
Dialer | ||
Information Gathering | Scanning | Attacks that send requests to a system to discover weak points. This includes also some kind of testing processes to gather information about hosts, services and accounts. Examples: fingerd, DNS querying, ICMP, SMTP (EXPN, RCPT, …). |
Sniffing | Observing and recording of network traffic (wiretapping). | |
Social Engineering | Gathering information from a human being in a non-technical way (e.g. lies, tricks, bribes, or threats). | |
Intrusion Attempts | Exploiting of known Vulnerabilities | An attempt to compromise a system or to disrupt any service by exploiting vulnerabilities with a standardised identifier such as CVE name (e.g. buffer overflow, backdoors, cross side scripting, etc.). |
Login attempts | Multiple login attempts (Guessing / cracking of passwords, brute force). | |
new attack signature | An attempt using an unknown exploit. | |
Intrusions | Privileged Account Compromise | A successful compromise of a system or application (service). This can have been caused remote by a known or new vulnerability, but also by an unauthorized local access. |
Unprivileged Account Compromise | ||
Application Compromise | ||
Availability | DoS | By this kind of an attack a system is bombarded with so many packets that the operations are delayed or the system crashes. Examples of a remote DoS are SYS- a. PING- flooding or E-mail bombing (DDoS: TFN, Trinity, etc.). However, the availability also can be affected by local actions (destruction, disruption of power supply, etc.). |
DDoS | ||
Sabotage | ||
Information Security | Unauthorised access to information | Besides a local abuse of data and systems the information security can be endangered by a successful account or application compromise. Furthermore attacks are possible that intercepts and access information during transmission (wiretapping, spoofing or hijacking). |
Unauthorised modification of information | ||
Fraud | Unauthorized use of resources | Using resources for unauthorized purposes including profit-making ventures (E.g. the use of e-mail to participate in illegal profit chain letters or pyramid schemes). |
Copyright | Selling or Installing copies of unlicensed commercial software or other copyright protected materials (Warez). | |
Masquerade | Type of attacks in which one entity illegitimately assumes the identity of another in order to benefit from it. | |
Other | All incidents which don't fit in one of the given categories should be put into this class. | If the number of incidents in this category increases, it is an indicator that the classification scheme must be revised. |
Note: The number of incident types is not fixed and should be enlarged any time if it seems necessary.
On the basis of the collected data of all participating teams the average value is calculated for each data field. Therefore every chart of the public statistics shows for example the average workload or the average number of handled incidents of each team in the respective month.
All available public statistics can be found here.
In contrast to the generalized public statistcs the charts of internal statistics contain more comprehensive information. According to the agreements of the Clearinghouse Policy the internal statistics provide detailed information about the workload of each team. As well information about the processed incidents are contained. All submitted data will be made accessible in anonymous form.
eCSIRT.net > Service > Documents > WP4 Userguide | |
(Partner) (Project) (News) (Background) (Service) |
![]() The European Computer Security Incident Response Team Network News | Sitemap | Imprint | Privacy Statement | Contact | Top Last changed: December 30, 2003 / JS Copyright © 2002-2003 by PRESECURE Consulting GmbH, Germany |
Signed with PGP!![]() ![]() |