|
WP4 Clearinghouse Policy |
| (Partner) (Project) (News) (Background) (Service) | |
| eCSIRT.net > Service > Documents > WP4 Clearinghouse Policy |
One of the goals of the eCSIRT.net project is to raise the awareness and understanding of the work of CSIRTs in the general public and among the CSIRTs. Therefore - in addition to the exchange of incident related data between CSIRTs - incident statistics will be made available to the participating teams and, in a generalized and sanitized way, to the public. These statistics will provide valuable information about incidents handled by the participating teams and about the general hazard level of internet connected systems.
In the eCSIRT.net project three types of statistics will be created:
The exchange of data needs to meet the requirements of the participating teams concerning the privacy and confidentiality of the exchanged data.
Each team may choose the kind of statistics to participate in, however as much data as possible should be provided.
The clearinghouse policy defines the binding frame for the exchange and publishing of statistical data founded on the eCSIRT.net Code of Conduct. Rules for providing and accessing the collected data and the statistics are established and the necessary procedures for publishing sanitized statistics to the public are defined.
The basic requirements and technical means to participate in the Clearinghouse Function are presented in the next chapter.
Chapter 3 describes the level of detail of the collected data and the procedures of collection and publishing the data.
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.
Participation in the Clearinghouse Function is restricted to teams that either are:
partner of the eCSIRT.net project
liaisons of the eCSIRT.net project
TI accredidated teams
All participating CSIRTs must sign the eCSIRT.net Code-of-Conduct. 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.
For the participation in the Clearinghouse Function, the provision of detailed information about a team is required. The correctness of the most important contact information is ensured either by the TI accreditation framework or by the eCSIRT.net project management (for partners and liaisons). But the Clearinghouse Function has additional requirements which are not (yet) met by the TI accreditation framework, therefore each participating CSIRT will be asked to provide an extended set of contact information. All information that is needed for the Clearinghouse Function is listed in appendix A. However, each participating CSIRT must ensure the correctness of its contact information in its own interest, as otherwise the successful submission of statistical data and access to the collected data cannot be guaranteed.
To generate the proposed types of statistics the collection of data from each participating team is necessary. The collection and processing of the data will be carried out on the eCSIRT.net server so the data has to be transferred using internet based communication.
The accuracy of the transferred information is crucial for the statistics so confidentiality, integrity and authenticity must be guaranteed using cryptographic techniques.
Each participating CSIRT must support cryptographic techniques based on the SSL/TLS standards. A detailed description of the used cryptographic techniques can be gathered from the appendix B.1. This covers the use of certificates as well.
The management of certificates as well as other access tokens like PINs and/or passwords are handled by the eCSIRT.net project management. Each participating CSIRT must ensure the correctness of its public keys / certificates and assist in the key management efforts including key certification based on direct communication with the eCSIRT.net project management. If no actual public keys / certificates are available, the successful participation cannot be guaranteed. A detailed description of public keys and certificates used by the eCSIRT.net project management are available in appendix B.2.
This chapter specifies the necessary data to be exchanged and the technical mechanisms to achieve this.
For the three different types of statistics different kinds of data have to be provided to the statistic processor:
Given the sensitiveness of the collected data and the implications to the reputation of the participating teams and the eCSIRT.net project the data has to be collected using authenticated and encrypted channels to prevent abuse of the system. The submission of data and the access to any internal results is restricted to participating CSIRTs.
The exchange of data needs to meet the requirements of the participating teams concerning the privacy and confidentiality of the exchanged data.
For the manually submitted data the authentication and encryption of the transferred data is sufficient.
For the exchanged incident information based on the common language, the same consideration applies.
For the automatically collected data for the general hazard statistics, different methods can be used to increase the amount of data and the level of detail a team is willing to submit (eg. argus data or already prepared statistics). Bilateral agreements for the submission of additional data are not subject of this policy.
Further disclosure of the internal data requires explicit permission from the submitting team(s).
For the participation in the Clearinghouse Function, the provision of detailed information about a team is required. The basic set of information a team without a TI level-2 accreditation has to submit the mandatory information set of the TI accreditation framework to the eCSIRT.net project management.
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:
In order to guarantee confidentiality, integrity and authenticity of Internet based communication the support of email security services is absolutely necessary. In practical operation the use of the following security services is mandatory:
The management and transport of cryptographic material (eg. distribution of keys, submission of revocation requests) for the Clearinghouse Function is based on email using OpenPGP and S/MIME standards. These two standards have gained broad acceptance and should cover the needs of each team and its constituency.
The submission of the statistical data and the access to the generated statistics are secured using SSL/TLS encryption and authentication. For the different types of statistics the following procedures apply:
At using PGP, eCSIRT.net will accept every key which has been signed by TI (formal key-signing for level-2 teams). The keys from a participating team, which doesn't have the TI level 2 status, will be signed by the project management. The following conditions are valid:
It is recommended that the signing individual team member's keys should be done by the team representatives to establish a link of trust.)
If no key is available which satisfies the boundary conditions, a new key must be produced1. After key generation make a printout on paper of your key's data (the usual: user-id, key-id, key-type, key-size, created and expiry data and its fingerprint in hexadecimal format) and take it with you to a meeting with eCSRIT.net staff. Please make sure that the public key is accessible via a PGP keyserver or take along a copy on a mobile data medium (USB sticks are fine).
For the personal identification a valid national passport or EU ID-card is needed. While the printouts (with the keys data) are signed in presence of eCSIRT.net staff, the passport or the ID-card will be checked. This is the way to authenticate a personal key or a team key or both.
After this the key(s) and the printout(s) will be checked. If everything is in order, the printout(s) will be signed by hand by eCSIRT.net staff. As soon as possible the keys will be signed, then updated on a PGP keyserver and on the eCSIRT.net restricted website.
For encryption only cryptographic techniques may be used which have a minimal key length of 128 bits (3DES, IDEA, AES).
For use of S/MIME and SSL/TLS for secure communication the eCSIRT.net CA issues X.509 client certificates to the partners. Each participating team gets a X.509 certificate (team certificate) for access to the private parts of the eCSIRT.net website (including the forms for submission of data as well as the collected data and the generated non-public statistics). The certificate and the secret key will be generated by the eCSIRT.net-CA and submitted to the teams using OpenPGP encryption and authentication. The certificate and secret key have to be integrated into the browsers by the team members. Keylengths, algorithms and validity periods of the certificates will be chosen according to the actual needs. Revocation of a certificate requires the team to send a PGP signed message to the project management.
The application for participation in the clearinghouse function can be carried out by e-mail. The information mentioned in appendix A must be transmitted to the project management. The access information is sent out in the same way.
Because the application for participation and the accessed information are confidential, the use of the clearinghouse function is possible only after the certification of the communication keys has taken place.
If the application for an access token isn't made by the representative of the team, then the eCSIRT.net project management has to be informed by the representative before. Should it be necessary to provide access information for other services, the application and delivery of the necessary information will be done according to this method. Additional requests as for revocation of certificates require a valid signed message from the responsible person to the project management.
The key material for the IDS sensors is provided on a preconfigured medium that enables the distributed software to transmit data in an authenticated and encrypted way. Distribution of this medium requires authentication by the according team certificate. Additional requests as for revocation of certificates require a valid signed message from the responsible person to the project management. A new medium will then be created and distributed.
PRESECURE:
STELVIO:
The certification authorities used for our services are signed by our ROOT certificate:
SSL Server Certificate
[1] Please, take all usual precautions when doing so (e.g. offline creation of key, chose secure passphrase, store key in a safe place preferably not online and make sure you have a backup of the keyrings).
This classification scheme is used for the collection of statistical data - Type 2 Incident Information.
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.
Note: The number of incident types is not fixed and should be enlarged any time if it seems necessary.
The following table shows the current used eCSIRT.net incident classes and types 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. |
Many thanks to Jimmy Arvidsson, Telia CERTCC. This classification scheme is based on his Incident Taxonomy.
| eCSIRT.net > Service > Documents > WP4 Clearinghouse Policy | |
| (Partner) (Project) (News) (Background) (Service) |
 eCSIRT.net
The European Computer Security Incident Response Team Network News | Sitemap | Imprint | Privacy Statement | Contact | Top Last changed: January 9, 2004 / AL Copyright © 2002-2003 by PRESECURE Consulting GmbH, Germany |
Signed with PGP! 
|