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

WP5 Alert Policy

     
eCSIRT.net > Service > Documents > WP5 Alert Policy  
 

WP5 Alert Policy - Release 1.1

 

Topics

 

Introduction

The primary aim of the eCSIRT.net project is to improve the security of the European IT infrastructure. Therefore - in addition to the improvement of the cooperation in the areas of incident handling and incident statistics - the partners of the eCSIRT.net project will build up an early warning service within their community. By such a system a much faster exchange of important and time critical information about unusual events and attacks can be realized.

With an Alert Function - an infrastructure service to distribute early warnings - the CSIRTs participating in the service will gain valuable time they in turn can utilize to:

To achieve these benefits the Alert Function must not only distribute information to the participating CSIRTs in a timely fashion but only ensure other characteristics:

Purpose of this Document

This document, known as the Alert Policy, defines the binding framework for CSIRTs participating in the Alert Function.

Rules for access and use of the Alert Function are defined, based on the eCSIRT.net Code of Conduct that governs the overall cooperation of the participating CSIRTs.

The document will not address issues related to the further dissemination of alerts to any CSIRTís constituency. It is expected that suitable policies and procedures are established by some partners and made available to the broader CSIRT community through the eCSIRT.net project.

Document Structure

The second chapter will describe the basic requirements and technical means to participate in the Alert Function.

The exchange of information is detailed in the third chapter concentrating on the formats utilized and policies governing the type of information that is exchanged by the Alert Function.

The forth chapter will explain under which circumstances the Alert function should be used.

Finally, a complete listing of all necessary information, technical details, examples and templates will be specified in appendices.

 

Basic Requirements

Participation

Participation in the Alert Function is restricted to teams that either are:

All participating CSIRTs must sign the eCSIRT.net Code-of-Conduct.

Required contact information

For the participation in the Alert 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 Alert 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 Alert Function is listed in Appendix A.

However, each participating CSIRT must ensure the correctness of it's contact information in it's own interest, as otherwise the successful distribution of alerts cannot be guaranteed.

Responsibility

To prevent misuse or damage of the eCSIRT.net infrastructure, each participating Team is responsible to keep any information in confidence which is necessary to use the alert function. Each member of a team must be conscious of this responsibility.

Communication and Communication Security

Communication is critical to all aspects of incident response.

In order to guarantee reliability and to avoid an abuse of the system all communication channels between the teams have to be protected.

It must be guaranteed that for the Internet based communication confidentiality, integrity and authenticity is ensured.

For the out-of-band communication integrity and authenticity must be ensured.

Any further distribution of alerts within the participating CSIRTs is outside the scope of this policy.

Internet based communication

Each participating CSIRT must provide a functional email address.

Out-of-Band communication

Each participating CSIRT must provide a functional telephone number.

Security

Each participating CSIRT must support cryptographic techniques based on the OpenPGP and / or S/MIME standards.

A detailed description of acceptable cryptographic techniques can be gathered from the appendix B.1. This covers the use of cryptographic keys and their certification as well.

Management of Cryptographic Keys and Access Tokens

The management of cryptographic keys, 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 it's 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 distribution of alerts cannot be guaranteed.

A detailed description of public keys and certificates used by the eCSIRT.net project management are available from the appendix B.2.

 

Information Exchange

Information

In order to avoid attacks and incidents or limit the impact of any incident if an attack is probable, the reply to the following questions is most important:

Under the preservation of the confidentiality of customer data, the amount of information to be exchanged should be as extensive as possible.

Verification

There are high demands on the trustworthiness of the information distributed by any Alert Function. As any

participating CSIRTs will invest considerable resources based on the alerts received great care needs to be taken to avoid any false alarm. This is even more true as any wrong public statement or distributed false alerts towards a CSIRT constituency might endanger itís reputation.

Access to the Alert Function is restricted to CSIRTs which are trusted to verify any information distributed via the Alert Function in the most professional way. If a participating CSIRT feels that information must be distributed to other CSIRTs, but is unsure of itís correctness, this needs to be clearly stated.

Therefore, only reliable information supported by information received from the constituency or by other reliable sources or from its own knowledge (e.g. Intrusion Detection System) shall be used.

Format for Internet based communication

To simplify the cooperation between the participating CSIRTs and enable an efficient processing, a predefined and tailored incident reporting form must be used.

This form, called the Incident Alerting Profile, is a subset of the IODEF Incident Handling Profile agreed by the participants of the eCSIRT.net project. An exact definition can be gathered from the appendix C.

Format for Out-of-band communication

It doesn't seem necessary to provide an exact communication format for the spoken language. However, according to the event, answers to the questions introduced in section 3.1 should be given clearly. The duration of the report should not exceed two minutes.

Disclosure

In order to guarantee a fast processing and potential forwarding of alerts to potentially endangered organizations, alerts should not contain any private (user or site related) information.

In addition no embarrassing information should be contained.

All information which is taken into account for public release will be classified (see appendix D).

 

Use of the Alert Function

Use of the in-band function

A triggering of alerts is only justified when there is a legitimate interest of the participating CSIRTs.

This is generally only given by events with

Every receipt of an in-band alert must be confirmed by the receiver.

If the triggering of an alarm is carried out automatically, it must be made sure that it is in compliance with the policies and guidelines described and defined in this document.

Comment: Of course it is difficult to calculate the probability of occurrence and the potential endangering of an attack, but the basic idea should be visible. It is impossible to write down all cases. It must be the aim to find the golden mean and to avoid an inflationary use.

Use of the out-of-band function

This function shall be used only, if

The out-of-band function might be used in addition to the in-band function outside business hours to achieve a wide as possible dissemination.

In all cases the out-of-band function can be used as some sort of last resort if no other communication means are available.

[1] By the extension of the in-band alert function around the acknowledgement feature, the sender of an alert message can examine the distribution. If the alert message is not acknowledged by a certain time (one hour was mentioned), the originator can use the out-of-band function for the escalation of the alert. This is not an automatic process, the decision to take further action is in the responsibility of the originator.

 

Appendix A - Contact Information

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

Since eCSIRT.net is a Trial, every team must decide whether the alert function shall completely be integrated into the daily business (i.e.: the use of the official phone numbers and e-mail address). Therefore, by each team has to submit separately all necessary information for the alert function.

Inbound Internet Alerting will be based on email and cryptography. The goal is to distribute only authenticated and encrypted emails. Therefore, the following information is needed:

Out-of band Alerting will be based on the telephone system. Therefore, the following information is needed:

This information must be sent to the eCSIRT.net project management on a secure manner. In each case the responsible person receives as an answer a signed and encrypted e-mail with the following information:

Inbound Internet Alerting

Out-of band Alerting

 

Appendix B - Communication Security

Security Techniques

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 alert function will only distribute messages, which are protected sufficiently.

The eCSIRT.net internet based Alert Function supports security services based on OpenPGP[2] and S/MIME Standards. These two standards have gained broad acceptance and should cover the needs of each team and its constituency. Although both standards offer similar services, the two protocols have been different(see Table). Further, and more important, they have different formats for their certificates.

 

Service / Protocol OpenPGP / GnuPG S/MIME v3
Signature DSA(2048) DSA(2048)
Public Key El-Gamal(4096) DH(1024)
Encryption 3DES 3DES / (RC2)
Hash SHA-1 (160) SHA-1 (160)
Message Format binary, based on old PGP binary, CMS
Certificate Format binary, based on old PGP binary, X.509
Mime signed multipart/signed with ASCII amor multipart/signed CMS
Mime encryption multipart/encrypted application/pkcs-7-mime

Table: comparison between OpenPGP - S/MIME

Further assessment of the individual standards doesn't take place. Every team has the possibility to choose between one of the two standards which cover the requirements of the team and the constituency at the best. The complete description of both IETF standards can be found under www.ietf.org/rfc/. The following documents are relevant:

A choice of S/MIME capable e-mail clients (no claim to completeness):

A choice of e-mail clients with a PGP/GPG plug-in available (as well no claim to completeness):

Cryptographic keys and their certification

OpenPGP / GnuPG

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:

If no key is available which satisfies the boundary conditions, a new key must be produced[3]. 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).

X.509

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 form for submission of alerts). 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.

For encryption only cryptographic techniques may be used which have a minimal key length of 128 bits (3DES, IDEA, AES).

Access Tokens and their distribution

For use of the out-of-band alert function each team requires at least UID and PINs. These are issued exclusively by the project management. The application for participation in the alert 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 access information are confidential, the use of the alert 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.

Public keys and certificates used by the eCSIRT.net project management

OpenPGP / GnuPG

PRESECURE:

STELVIO:

X.509 Certification Authority

The certification authorities used for our services are signed by our ROOT certificate:

SSL Server Certificate

[2]There also exists the possibility of supporting older PGP versions. However, this should be taken into consideration only in exceptional cases.

[3]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)

 

Appendix C - IODEF Incident Alerting Profile

The alert profile is part of the eCSIRT.net WP2 Deliverable: Common Language. A detailed description of syntax and semantics can be gathered from the document mentioned before. In the following, the eCSIRT.net alert profile and examples are shown on how to apply the common language.

Alert Profile

    <IODEF-document version="">[4]
           <Incident purpose=" " restriction=" ">[5]
                <IncidentID name= " "></IncidentID>
                <IncidentData>
                        <Description> </Description>
                        <Assessment >
                                <Impact severity=" " type= " "   ></Impact>
                                <Confidence rating= " "></Confidence>
                        </Assessment>
                        <Method>
                                <Classification origin=" ">
                                      <name></name>
                                      <url></url>
                                </Classification>
                                <Description></Description>
                        <Method/>
                        <ReportTime></ReportTime>
                        <Contact role=" " type=" " >
                                <Name></Name>
                                <Telephone></Telephone>
                                <Fax></Fax>
                                <E-Mail></E-Mail>
                                <Timezone></Timezone>
                        </Contact>
                        <Expactation  priority=" " category= " "></Expactation>
                                <Description></Description>
                        <EventData>
                                <Description></Description>
                                <StartTime></StartTime>
                                <StopTime><StopTime/>
                                <DetectTime></DetectTime>
                                <Record>
                                      <RecordData></RecordData>
                                </Record>
                        </EventData>
                        <AdditionalData type =" " meaning=" "></AdditionalData>
                </IncidentData>
        </Incident>
    </IODEF-Document>

Note the nesting of EventData structures is not supported in this profile.

Alert Profile Example[6]

    <IODEF-document version=" 1.0">
           <Incident purpose="warning " restriction="default ">
                <IncidentID name= "ABC-CERT">ABC-CERT-2003-00107<IncidentID/>
                <IncidentData>
                        <Description>
                            We are receiving information of new worm activity. The
                            worm probes port 1434 UDP and tries to infect SQL server systems.
                        </Description>
                        <Assessment >
                                <Impact severity="high" type="dos"></Impact>
                                <Confidence rating= "high"></Confidence>
                        </Assessment>
                        <Method>
                                <Classification origin="other">
                                       <name>ms02-061</name>
                                       <url>http://www.microsoft.com/technet/security/bulletin/</url>
                                </Classification>
                                <Description>
                                    This worm uses a buffer overflow in the SQL
                                    server resolution service. The worm sends a
                                    carefully crafted packet to port 1434 UDP to
                                    break the stack and execute the worm's own code
                                    on the system. The worm then uses the keep alive
                                    mechanism within SQL server to launch a Denial
                                    of service attack. Systems that record IP addresses
                                    are seeing totally random source and destination ports.
                                </Description>
                        <Method/>
                        <ReportTime>2003-01-03T11:25-00:00</ReportTime>
                        <Contact role="irt " type="organisation">
                                <Name>ABC_CERT</>Name>
                                <Telephone>+49 40 12345678</Telephone>
                                <Fax>+49 40 12345679</Fax>
                                <E-Mail>abc-cert@ecsirt.net</E-MAIL>
                                <Timezone>UTC+01:00</Timezone>
                        </Contact>
                        <Expactation category="other">
                                <Description>Inform constituency</Description>
                                <Description>
                                    The only advice offered at present is to block
                                    all traffic on ports: 445 TCP 1434 UDP Disable
                                    the SQL server from having multiple clients Ensure
                                    that all patches are up to date, specifically
                                    Microsoft 02-039 and 03-001
                                 </Description>
                        </Expactation>
                        <EventData>
                                <Description>
                                    Windows 2000: all versions.
                                    Windows NT: All versions.
                                    MS SQL server:  2000 only.
                                    MS .NET framework 1.0.
                                </Description>
                        </EventData>
                        <AdditionalData type ="string" meaning="eCSIRT.net IODEF Profile Version 1.0">
                                eCSIRT.net IODEF Profile Version 1.0
                        </AdditionalData>
                        <AdditionalData type ="string">
                            There may also be a DDoS attack masking itself alongside
                            the SQL worm which probes port 445 (this part is unconfirmed).
                            Systems currently affected are three root DNS servers and several ISPs.
                        </AdditionalData>
                </IncidentData>
        </Incident>
    </IODEF-Document>

[4]In this description only the classes and attributes necessary for IODEF or regarded as necessary for the profile are listed .

[5]This attribute has to be understood as global in this profile.

[6]In this example we used contents of a UNIRAS report from January 2003.

 

Classification of Information

The classification scheme of information is taken from the RFC2350 (IETF category: "Best current practise"). In our opinion the classification scheme is absolutely applicable also for eCSIRT.net. Only the section statistics was changed, further insignificant changes of the source serve only for the better understanding in the eCSIRT.net context.

Any information which will be taken into account for a release must be classified with the following scheme:

 

Appendix E - Revision History

 

eCSIRT.net > Service > Documents > WP5 Alert Policy  
     
eCSIRT.net 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!This page is digitally signed with PGP! eCSIRT.net