Logo of the European Computer Security Incident Response Team Network (eCSIRT.net)

WP5 Alert Function

eCSIRT.net > Service > Documents > WP5 Alert Policy  

WP5 Alert Function: internet based communication




System description

The internet based alert function of the eCSIRT.net was implemented as an enhancement of the existing communication infrastructure. All modules of the alert function are running on LINUX based plattforms and placed in a safe environment. The main components of the internet based alert function are:

Mailing List

The essential reasons for the decision to use a mailing list for the alert function instead of a web based solution were:

For the administration oft the eCSIRT.net alert mailing list Mailman, the Mailing List Manager of the GNU Project, is used. Mailman is free software for managing electronic mail discussion and e-newsletter lists, distributed under the GNU General Public License. Mailman provides a couple of web-based features (e.g. subscribing and unsubscribing to a list). But in this case we have to deal with a closed user groupand a seperate registration is required. Therefore a user cannot subscribe or unsubscribe himself to the mailing list, this is done exclusively by the eCSIRT.net management.

E-mail Gateway

According to the alert policy the support of e-mail security services is absolutely mandatory in order to guarantee confidentiality and authenticity for any communication over the Internet. Furthermore the following conditions should be satisfied:

At present Open Source Software which fulfills these requirements is not available so that commercial products had to be taken into account. However, a sponsor could be won for the project whose product the given requirements more than fulfilled. The SecureMail Gateway provided by bone labs operates as Proxy-Server. In this case the standardized SMTP protocol is the only interface to available mail-servers, so that the Gateway can be integrated without problems into an existing email-infrastructure. The essential features which are used by the alert function are:

Mode of operation

The security policy of the SecureMail Gateway only accepts incoming mail which is encrypted and signed and which was sent by a registered team. Therefore it is insignificant, whether the message is protected with S/MIME or OpenPGP (GnuPG). After the message was decrypted and the sender verified, the message is forwarded to the list manager. In the last step all messages received from the list manager will be signed and encrypted by the SecureMail Gateway. If a X.509 certificate of a team is available, the message is protected according the S/MIME standard, otherwise the PGP standard is applied.


According to the specifications of the WP5 alert Policy a couple of web-forms for the input of alert messages was developed. This forms were developed with the Common Gateway Interface, or CGI, a standard for external gateway programs to interface with HTTP information servers. The following user-interface is available:

In the following step an IODEF-XML object is generated from the entered data. For the IODEF processing the "Incident Handling Shell (IHSH)" is used. This tool bases on the results of AirCERT, a work done at the CERT Coordination Center (CERT/CC). For further information, please follow the links on the IODEF product list. Besides the IODEF object an ASCII representation is also created. Finally both objects are embedded in a MIME message and transmitted to the mailing list.

Acknowledgement function

After the first experiences with the in-band alert function it was recognized that a confirmation of the receipt of a message would be very helpful regarding the use of the out-of-band function. Therefore this functionality was implemented afterwards. This function was also realized on the basis of Web-forms. The technical realization corresponds to the description before.

During the generation of an alert message with the WP5 alert web-form a corresponding data object is produced on the server. This object can be modified or watched with corresponding web-forms. A detailed description of the function under the point of view of a user can be taken from the following chapter.



For the participation in this service only low technical requirements have to be fulfilled: just a functional email address and a corresponding OpenPGP-Key or X.509 certificate.

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). A detailed description of the procedure is available from eCSIRT.net WP5 Alert Policy.

If all prerequisites are fullfilled, a team is put on the alert exchange list by the eCSIRT.net project management. To be able to send a report to the alert exchange list, the following information is given to each registered team:


Participation in the Alert 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.


User Guide

Sending an alert can be carried out in two different ways:



The exchange of information, the message format (IODEF Alert Profile and in particular the aspects of communication security was described in the WP5 Alert Policy. The integration of the alert function into a Incident Handling System or other workflows lies in the responsibility of every participating team so that no guideline is required in this place.

Remark: Only signed and encrypted messages will be accepted by the eCSIRT.net Alert Exchange List.



For all teams which haven't integrated the alert function into their Incident Handling System yet a web-form is offered for drawing up and distributing alerts. The WP5 Alert Form is made available only within the eCSIRT.net Intranet.

In order to access the protected area of the eCSIRT.net Web-server a two-way authentication with Client and Server Certificate is necessary. Furthermore the communication is protected with SSL.

If desired, the X.509 certificate (team certificate) and the secret key will be generated by the eCSIRT.net-CA and submitted to the teams using OpenPGP encryption and authentication (details will be given in the WP5 Alert Policy).

The Alert Form:

Description of the input fields:

Area Field Type Description / Example IODEF
Incident Restriction Checkbox Indicates the disclosure guidelines. In this profile this attribute is used globally.
The default value is "eCSIRT.net" or in words: all particpating teams.
Incident (attribute)
Incident-ID Text unique identifier assigned by the team that generated the document. The name of the team is added automatically.
Example: the input "0816" will be expand to "DFN-CERT-0816".
Description Text A shortdescription of the incident.
Example: "A buffer overrun vulnerability exists in the part of the Windows ...".
Affected Plattforms Systems Listboxes Predefined system classification - to the support of the user EventData-->Description
Other Systems Text For systems which are not contained in the choice and for additional information (e.g. Version, Patchlevel, ...) EventData-->Description
Software Listboxes Predefined software classification - to the support of the user EventData-->Description
Other Software Text For software which is not contained in the choice and for additional information (e.g. Version, Patchlevel, ...) EventData-->Description
Assessment Type Listbox The type of impact.
Permissible values are: "admin, dos, file, recon, user, none, unkown and other".
The default value is "unknown."
IncidentData-->Assessment--> Impact(attr)
Severity Listbox An estimate of the relative severity of the activity. Permissible values are: "high, medium, low".
No default value is given.
IncidentData-->Assessment--> Impact(attr)
Confidence Listbox The confidence the CSIRT has in its assessment. Permissible values are: "high, medium, low".
No default value is given.
IncidentData-->Assessment--> Confidence(attr)
Method Origin Listbox The name of the database to which the reference is being made. Permissible values are: "bugtraqid, cve, certcc, vendor, local and other ".
No default value is given.
IncidentData-->Method--> Classification(attr)
Name Text The name of the reference in the origin attribute. IncidentData-->Method--> Classification
URL Text URL to additional information about the vulnerability or exposure referenced by the name. IncidentData-->Method--> Classification
Description Text A description of the methodology used in the incident (attack vector). IncidentData-->Method--> Description
Recommendation Description Text A description of the possible action options preventing a possible attack. IncidentData-->Expectation--> Description
Expectation Category Checkbox The type of action requested. Permissible values are: "inform constituency, inform public and other".
The default value is "inform constituency (other)"
Description Text Expected action to be performed by the recipient of the alert. IncidentData-->Expectation--> Description
Description   Text A free-form textual description of the event (e.g. origin/source of the attack, how can the attack be detected etc.). EventData-->Description
StartTime DateTime Timestamp for the start of the attack.
Example for all "time fields": 2003-08-28T13:35+00:00
StopTime DateTime Timestamp for the end of the attack. EventDate-->StopTime
DetectTime DateTime Timestamp of when the attack was first detected. EventData-->DetectTime
AdditionalData   Text Any information which otherwise cannot be represented in the data model. IncidentData-->AdditionalData

The following fields will be filled out automatically.

IODEF Document Version String Version 1.0 IODFF-Document(attribute)
Incident Purpose String "warning" - the purpose of the IODEF document. Incident(attribute)
Name String Name (Handle) of the team Incident-->IncidentID(attr)
Contact Role String "irt" - the CSIRT involved in handling the incident. IncidentData-->Contact(attr)
Type String "organisation" - the type of Contact being provided. IncidentData-->Contact(attr)
Name String e.g. "PRESECURE Computer Emergency Response Team" IncidentData-->Contact--> Name
RegistryHandle String e.g. "PRE-CERT" IncidentData-->Contact--> RegistryHandle
Email String e.g. "precert@pre-secure.de" IncidentData-->Contact--> Email
Telephone String e.g. " +49 40 808077800 " IncidentData-->Contact--> Telephone
Fax String e.g. " +49 40 808077877 " IncidentData-->Contact--> Fax
  ReportTime DateTime e.g. "2003-08-28T13:35+00:00" IncidentData-->ReportTime

The following fields are mandatory and must be filled out properly:

A detailed description of the eCSIRT.net IODEF Profile can be gathered from the eCSIRT.net WP2 Deliverable "Common Language Secification".

Example Output

By the WP5-alert-form a MIME-message is prepared which contains two parts:

ASCII representation

The security info of the message shows that the incoming message wasn't signed and encrypted. In this case it is acceptable because the web server and the mail gateway are connected directly. Alerts which weren't generated by the web-form are only processed if the message was signed and encrypted properly. The next image shows a corresponding security info:

XML coded IODEF document


Acknowledgement function

If the alert message was generated with the WP5 Alert Form, the following link is contained in the alert message:

Please follow the link to acknowledge the receipt of the alert

Each team can acknowledge the receipt of the alert message by simply clicking on the link. Apart from the acknowledgement of the receipt of the message the possibility exists to enter some remarks. The following image shows the corresponding web-form:

The inventor of the message as well as every other participating team can query the current status of the alert message with the following web-form any time.

For example: the input with an Incident_ID: "DFN-CERT-0816" delivers the following:


Related Documents


Revision History


eCSIRT.net > INTRAnet > WP5 Alert Policy  
eCSIRT.net eCSIRT.net
The European Computer Security Incident Response Team Network
News | Sitemap | Imprint | Privacy Statement | Contact | Top
Last changed: Dec 30, 2003 / JS
Copyright © 2002-2003 by PRESECURE Consulting GmbH, Germany
Signed with PGP!This page is digitally signed with PGP! eCSIRT.net