New Req ID
Mike Erlinger <[email protected]> Wed, 23 Oct 2002 09:52:17 -0700
| Newsgroups | gmane.ietf.idwg |
|---|---|
| Message-ID | <[email protected]> |
A new Requirements ID is attached. It contains changes recommended by the IESG. Namely: Change section 6.17, Message Extensions, to indicate that such extensions CANNOT affect interoperability Change section 6.19, Message Extensions, to indicate that such extensions CANNOT affect interoperability Add a Reference Section and some related anchors mike -- Mike Erlinger, Professor and Chair Computer Science www: http://www.cs.hmc.edu/~mike email: [email protected] smail: Computer Science Dept., Harvey Mudd College, 301 E. 12th Street, Claremont, CA, 91711 909-621-8912, FAX: 909-607-8364
10.xml
(text/plain, 52 KB)
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<rfc ipr="full2026" docName="draft-ietf-idwg-requirements-10">
<front>
<title abbrev="Requirements">Intrusion Detection Message Exchange
Requirements</title>
<author initials="M." surname="Wood" fullname="Mark Wood">
<organization>Internet Security Systems, Inc</organization>
<address>
<postal>
<street>6303 Barfield Road</street>
<city>Atlanta</city> <region>GA</region>
<code>30328</code> <country>US</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="M.A." surname="Erlinger" fullname="Michael A. Erlinger">
<organization>Harvey Mudd College</organization>
<address>
<postal>
<street>Computer Science Dept</street>
<street>301 East 12th Street</street>
<city>Claremont</city> <region>CA</region>
<code>91711</code> <country>US</country>
</postal>
<email>[email protected]</email>
<uri>http://www.cs.hmc.edu/</uri>
</address>
</author>
<date day="22" month="October" year="2002" />
<area>Security</area>
<workgroup>Intrusion Detection Working Group</workgroup>
<keyword>Internet Draft</keyword>
<keyword>IDMEF</keyword>
<abstract>
<t>The purpose of the Intrusion Detection Exchange Format Working
Group (IDWG) is to
define data formats and exchange procedures for sharing
information of interest to intrusion detection and response
systems, and to the management systems which may need to interact
with them. This Internet-Draft describes the high-level
requirements for such a communication mechanism, including
the rationale for
those requirements where clarification is needed. Scenarios are
used to illustrate some requirements.
</t>
</abstract>
</front>
<middle>
<section anchor="convention" title="Conventions Used in This Document">
<t>This is not an IETF standards track document
<xref target="RFC2026" />
and thus the keywords
MUST, MUST NOT, SHOULD, and MAY are NOT as in
<xref target="RFC2119">RFC 2119,</xref>
but rather:
<list style="symbols">
<t>MUST: This word, or the terms "REQUIRED" or "SHALL", means that
the described behavior or characteristic is an absolute
requirement for a proposed IDWG specification.
</t>
<t>MUST NOT: This phrase, or the phrase "SHALL NOT", means that the
described behavior or characteristic is an absolute prohibition of
a proposed IDWG specification.
</t>
<t>SHOULD: This word, or the adjective "RECOMMENDED", means that
there may exist valid reasons in particular circumstances for a
proposed IDWG specification to ignore described behavior or
characteristics.
</t>
<t>MAY: This word, or the adjective "OPTIONAL", means that described
behavior or characteristics are truly optional for a proposed
IDWG specification. One proposed
specification may choose to include the described behavior or
characteristic while another proposed specification may omit the
same behavior or characteristic.
</t>
</list>
</t>
</section>
<section anchor="intro" title="Introduction">
<t>This document defines requirements for the Intrusion Detection Message
Exchange Format (IDMEF), which is the intended work product of the Intrusion
Detection Exchange Format Working Group (IDWG). IDMEF is planned to be
a standard format which automated Intrusion Detection Systems (IDS)
<xref target="RFC2828" /> can use
for reporting what they have deemed to be suspicious or of interest.
This document also specifies requirements for a communication protocol
for communicating IDMEF. As chartered IDWG, has the responsibility to
first evaluate existing communication protocols before choosing to
specify a new one. Thus the requirements in this document can be used
to evaluate existing communication protocols.
If IDWG determines that a new communication protocol is necessary,
the requirements in this document can be used to evaluate proposed
solutions.
</t>
<section title ="Rationale for IDMEF">
<t>The reasons such a format should be useful are as follows:
<list style="numbers">
<t>A number of commercial and free Intrusion Detection Systems are
available and more are becoming available all the time. Some products
are aimed at detecting intrusions on the network, others are aimed at
host operating systems, while still others are aimed at applications.
Even within a given category, the products have very different
strengths and weaknesses. Hence it is likely that users will deploy
more than a single product, and users will want to observe the output
of these products from one or more manager(s). A standard format for
reporting will simplify this task greatly.
</t>
<t> Intrusions frequently involve multiple organizations as victims, or
multiple sites within the same organization. Typically, those sites
will use different IDSs. It would be very helpful to correlate
such distributed intrusions across multiple sites and administrative
domains. Having reports from all sites in a common format would
facilitate this task.
</t>
<t> The existence of a common format should allow components from
different IDSs to be integrated more readily.
Thus, Intrusion Detection (ID) research
should migrate into commercial products more easily.
</t>
<t> In addition to enabling communication from an ID
analyzer to an ID manager, the IDMEF notification system may also
enable communication between a variety of IDS components. However,
for the remainder of this document, we refer to the communication as
going from an analyzer to a manager.
</t>
</list>
</t>
<t> All of these reasons suggest that a common format for reporting
anything deemed
suspicious should help the IDS market to grow and innovate more
successfully, and should result in IDS users obtaining better results
from deployment of ID systems.
</t>
</section>
<section title ="Intrusion Detection Terms">
<t>In order to make the rest of the requirements clearer, we define some
terms about typical IDSs. These terms are
presented in alphabetical order. The diagram at the end of this section
illustrates the relationships of some of the terms defined herein.
</t>
<section title ="Activity:">
<t>Elements of the data source or occurrences within the data source that
are identified by the sensor or analyzer as being of interest to the
operator. Examples of this include (but are not limited to) network
session showing unexpected telnet activity, operating system log file
entries showing a user attempting to access files to which he is not
authorized to have access, application log files showing persistent
login failures, etc.
</t>
<t>Activity can range from extremely serious occurrences (such as an
unequivocally malicious attack) to less serious occurrences (such as
unusual user activity that's worth a further look) to neutral
activity (such as user login).
</t>
</section>
<section title ="Administrator:">
<t>The human with overall responsibility for setting
the security policy of
the organization, and, thus, for decisions about deploying and
configuring the IDS. This may or may not be the same person as the
operator of the IDS. In some organizations, the administrator is
associated with the network or systems administration groups. In other
organizations, it's an independent position.
</t>
</section>
<section title ="Alert:">
<t>A message from an analyzer to a manager that an event of interest
has been detected.
An alert typically contains information about the unusual activity that
was detected, as well as the specifics of the occurrence.
</t>
</section>
<section title ="Analyzer:">
<t>The ID component or process that analyzes the data collected by the
sensor for signs of unauthorized or undesired activity or for events
that might be of interest to the security administrator. In many
existing IDSs, the sensor and the analyzer are part of the same
component. In this document, the term analyzer is used generically to
refer to the sender of the IDMEF message.
</t>
</section>
<section title ="Data Source:">
<t>The raw information that an intrusion detection system uses to detect
unauthorized or undesired activity. Common data sources include (but
are not limited to) raw network packets, operating system audit logs,
application audit logs, and system-generated checksum data.
</t>
</section>
<section title ="Event:">
<t>The occurrence in the data source that is detected by the sensor
and
which may result in an IDMEF alert being transmitted. For example, 'N'
failed logins in 'T' seconds might indicate a brute-force login attack.
</t>
</section>
<section title ="IDS:">
<t>Intrusion detection system. Some combination of one or more of the
following components: sensor, analyzer, manager.
</t>
</section>
<section title ="Manager">
<t>The ID component or process from which the operator
manages the various
components of the ID system. Management functions typically include (but
are not limited to) sensor configuration, analyzer configuration, event
notification management, data consolidation, and reporting.
</t>
</section>
<section title ="Notification:">
<t>The method by which the IDS manager makes the operator aware of the
alert occurrence
and thus the event.
In many IDSs, this is done via the display of a
colored icon on the IDS manager screen, the transmission of an e-mail or
pager message, or the transmission of an SNMP trap, although other
notification techniques are also used.
</t>
</section>
<section title ="Operator:">
<t>The human that is the primary user of the IDS manager. The operator
often monitors the output of the ID system and initiates or recommends
further action.
</t>
</section>
<section title ="Response:">
<t>The actions taken in response to an event. Responses may be undertaken
automatically by some entity in the IDS architecture or may be
initiated by a human. Sending a notification to the operator is a very
common response. Other responses include (but are not limited to)
logging the activity, recording the raw data (from the data source) that
characterized the event, terminating a network, user, or application
session, or altering network or system access controls.
</t>
</section>
<section title ="Sensor:">
<t>The ID component that collects data from the data source. The
frequency of data collection will vary across IDS offerings.
The sensor is setup to
forward events to the analyzer.
</t>
</section>
<section title ="Signature:">
<t>A rule used by the analyzer to identify interesting activity to the
security administrator. Signatures represent one of the mechanisms
(though not necessarily the only mechanism) by which IDSs
detect
intrusions.
</t>
</section>
<section title ="Security Policy:">
<t>The predefined, formally documented statement which defines what
activities are allowed to take place on an organization's network or on
particular hosts to support the organization's requirements. This
includes, but is not limited to, which hosts are to be denied external
network access.
</t>
</section>
</section>
<figure>
<artwork>
________
| | --------
| Data |_________ ________| | __________
| Source | Activity |Sensor | | |
|________| | |________| | Operator |_______
| | |__________| |
\|/ Event A |
_____V___ | /|\ |
| | | \ |
| Sensor |__ | Notification |
|_________| Event | \ \|/
A | V_________ \ V
/|\ | | | \ Response
| --->| Analyzer|__ | A
| | | Alert | /|\
| |_________| | | |
| A | | |
| /|\ \|/ | |
|________________| ____V___ | |
| | |_| |
| | Manager|_________|
| |________|
| A
Security /|\
_______________ | Policy__________|
| | |
| Administrator |__|
|_______________|
</artwork>
<postamble>
The diagram above illustrates the terms above and their relationships.
Not every IDS will have all of these separate
components exactly as shown. Some IDSs will combine these
components into a single module; some will have multiple instances
of these modules.
</postamble>
</figure>
<section title="Architectural Assumptions">
<t>In this document, as defined in the terms above, we assume that an
analyzer determines somehow that a suspicious event has been seen by a
sensor, and sends an alert to a manager. The format of that alert and
the method of communicating it are what IDMEF proposes to standardize.
</t>
<t>For the purposes of this document, we assume that the analyzer and
manager are separate components, and that they are communicating
pairwise across a TCP/IP network. No other form of communication
between these entities is contemplated in this document, and no other
use of IDMEF alerts is considered. We refer to the communication
protocol that communicates IDMEF as the IDMEF Communication Protocol (IDP).
</t>
<t>The Trust Model is not specified as a requirement, but is rather
left to the choice of the IDMEF communications protocol, i.e., a
design decision. What is
specified are individual security related requirements,
<xref target="communicationsProtocol" />.
</t>
<t>We try to make no further architectural assumptions than those just
stated. For example, the following points should not matter:
<list style="symbols">
<t>Whether the sensor and the analyzer are integrated or separate.
</t>
<t>Whether the analyzer and manager are isolated, or embedded in some
large hierarchy or distributed mesh of components.
</t>
<t>Whether the manager actually notifies a human, takes action
automatically, or just analyzes incoming alerts and correlates them.
</t>
<t>Whether a component might act as an analyzer with respect to one
component, while also acting as a manager with respect to another.
</t>
</list>
</t>
</section>
<section title="Organization of This Document">
<t>Besides this requirements document, the IDWG should
produce two other documents. The first should describe a data format or
language for exchanging information about suspicious events. In this,
the requirements
document, we refer to that document as the "data-format specification".
The
second document
to be produced should identify existing IETF protocols that are best
used for conveying the data so formatted, and explain how to package
this data in those existing formats or the document should specify a
new protocol.
We refer to this as the
IDP (IDMEF Communication Protocol).
</t>
<t>Accordingly, the requirements here are partitioned into four sections
<list style="symbols">
<t> The first of these contains general requirements that apply to all
aspects of the IDMEF
specification <xref target="generalRequirements" />.
</t>
<t> The second section describes requirements on the formatting of IDMEF
messages <xref target="messageFormat" />.
</t>
<t> The third section outlines requirements on the communications
mechanism, IDP, used to move IDMEF messages from the analyzer to the
manager <xref target="communicationsProtocol" />.
</t>
<t> The final section contains requirements on the content and
semantics of the IDMEF
messages <xref target="messageContent" /> .
</t>
</list>
</t>
<t>For each requirement, we attempt to state the requirement as clearly as
possible without imposing an idea of what a design solution should be.
Then we give the rationale for why this requirement is important, and
state whether this should be an essential feature of the specification,
or is beneficial but could be lacking if it is difficult to fulfill.
Finally, where it seems necessary, we give an illustrative scenario. In
some cases, we include possible design solutions in the scenario. These
are purely illustrative.
</t>
</section>
<section title="Document Impact on IDMEF Designs">
<t>It is expected that proposed IDMEF designs will, at a minimum, satisfy
the requirements expressed in this document. However, this document will
be used only as one of many criteria in the evaluation of various IDMEF
designs and proposed communication protocols.
It is recognized that the working group may use additional
metrics to evaluate competing IDMEF designs and/or communication
protocols.
</t>
</section>
</section>
<section anchor="generalRequirements" title="General Requirements">
<section title="Use of Existing RFCs">
<t>The IDMEF SHALL reference and use previously published RFCs where
possible.
</t>
<section title = "Rationale:">
<t>The IETF has already completed a great deal of research
and work into the areas of networks and security. In the interest
of time, it is smart to use already defined and accepted
standards.
</t>
</section>
</section>
<section title="IPv4 and IPv6">
<t>The IDMEF specification MUST take into account that
IDMEF should be
able to operate in environments that contain IPv4 and IPv6
implementations.
</t>
<section title = "Rationale:">
<t>Since pure IPv4, hybrid IPv6/IPv4, and pure IPv6
environments are expected to exist within the time frame of IDMEF
implementations, the IDMEF specification MUST support IPv6
and IPv4 environments.
</t>
</section>
</section>
</section>
<section anchor="messageFormat" title="Message Format Requirements">
<t>The IDMEF message format is intended to be independent of the IDMEF
communications protocol (IDP). It should be possible to use a completely
different transport mechanism without changing the IDMEF format. The
goal behind this requirement is to ensure a clean separation between
semantics and communication mechanisms. Obviously the IDMEF communication
protocol is recommended.
</t>
<section title="Internationalization and Localization">
<t>IDMEF message formats SHALL support full internationalization and
localization.
</t>
<section title = "Rationale:">
<t> Since network security and intrusion detection are
areas that cross geographic, political, and cultural boundaries,
the IDMEF messages MUST be formatted such that they can be
presented to an operator in a local language and adhering to local
presentation customs.
</t>
</section>
<section title = "Scenario:">
<t>An IDMEF specification might include numeric event
identifiers. An IDMEF implementation might translate these numeric
event identifiers into local language descriptions. In cases where
the messages contain strings, the information might be represented
using the ISO/IEC IS 10646-1 character set and encoded using the
UTF-8 transformation format to facilitate internationalization
<xref target="RFC2277" />.
</t>
</section>
</section>
<section title="Message Filtering and Aggregation">
<t>The format of IDMEF messages MUST support filtering and/or
aggregation of data by the manager.
</t>
<section title = "Rationale:">
<t>Since it is anticipated that some managers might want
to perform filtering and/or data aggregation functions on IDMEF
messages, the IDMEF messages MUST be structured to facilitate these
operations.
</t>
</section>
<section title = "Scenario:">
<t>An IDMEF specification proposal might recommend fixed
format messages with strong numerical semantics. This would lend
itself to high-performance filtering and aggregation by the
receiving station.
</t>
</section>
</section>
</section>
<section anchor="communicationsProtocol" title="IDMEF Communications Protocol
(IDP) Requirements">
<section title="Reliable Message Transmission">
<t>The IDP MUST support reliable transmission of messages.
</t>
<section title = "Rationale:">
<t>IDS managers often rely on receipt of data from IDS
analyzers to do their jobs effectively. Since IDS managers will
rely on IDMEF messages for this purpose, it is important that IDP
deliver IDMEF messages reliably.
</t>
</section>
</section>
<section title="Interaction with Firewalls">
<t>The IDP MUST support transmission of messages between ID
components across firewall boundaries without compromising
security.
</t>
<section title = "Rationale:">
<t>Since it is expected that firewalls will often be
deployed between IDMEF capable analyzers and their corresponding
managers,
the ability to relay messages via proxy
or other suitable mechanism across firewalls
is necessary.
Setting up this communication MUST NOT require changes to the
intervening firewall(s) that weaken the security of the protected
network(s). Nor SHOULD this be achieved by mixing IDMEF
messages with other kinds of traffic (e.g., by overloading the
HTTP POST method) since that would make it difficult for an
organization to apply separate policies to IDMEF traffic and other
kinds of traffic.
</t>
</section>
<section title = "Scenario:">
<t>One possible design is the use of TCP to convey IDMEF
messages. The general goal in this case is to avoid opening
dangerous inbound "holes" in the firewall. When the manager is
inside the firewall and the analyzers are outside the firewall,
this is often achieved by having the manager initiate an outbound
connection to each analyzer. However, it is also possible to
place the manager outside the firewall and the analyzers on the
inside; this can occur when a third-party vendor (such as an ISP)
is providing monitoring services to a user. In this case, the
outbound connections would be initiated by each analyzer to the
manager. A mechanism that permits either the manager or the
analyzer to initiate connections would provide maximum flexibility
in manager and analyzer deployment.
</t>
</section>
</section>
<section title="Mutual Authentication">
<t>The IDP MUST support mutual authentication of the analyzer and
the manager to each other. Application-layer authentication
is required irrespective of the underlying transport layer.
</t>
<section title = "Rationale:">
<t>Since the alert messages are used by a manager to
direct responses or further investigation related to the security
of an enterprise network, it is important that the receiver have
confidence in the identity of the sender and that the sender have
confidence in the identity of the receiver. This is peer-to-peer
authentication of each party to the other. It MUST NOT be
limited to authentication of the underlying communications
mechanism, for example, because of the risk that this
authentication process might be subverted or misconfigured.
</t>
</section>
</section>
<section title="Message Confidentiality">
<t>The IDP MUST support confidentiality of the message content
during message exchange. The selected design MUST be capable of
supporting a variety of encryption algorithms and MUST be
adaptable to a wide variety of environments.
</t>
<section title = "Rationale:">
<t>IDMEF messages potentially contain extremely sensitive
information (such as passwords) and would be of great interest to
an intruder. Since it is likely some of these messages will be
transmitted across uncontrolled network segments, it is important
that the content be shielded. Furthermore, since the legal
environment for encryption technologies is extremely varied and
changes often, it is important that the design selected be capable
of supporting a number of different encryption options and be
adaptable by the user to a variety of environments.
</t>
</section>
</section>
<section title="Message Integrity">
<t>The IDP MUST ensure the integrity of the message content. The
selected design MUST be capable of supporting a variety of
integrity mechanisms and MUST be adaptable to a wide variety of
environments.
</t>
<section title = "Rationale:">
<t>IDMEF messages are used by the manager to direct action
related to the security of the protected enterprise network. It is
vital for the manager to be certain that the content of the
message has not been changed after transmission.
</t>
</section>
</section>
<section title="Per-source Authentication">
<t>The IDP MUST support separate authentication keys for each sender.
If symmetric algorithms are used, these keys would need to be
known to the manager it is communicating with.
</t>
<section title = "Rationale:">
<t>Given that sensitive security information is being
exchanged via the IDMEF, it is important that the manager can
authenticate each analyzer sending alerts.
</t>
</section>
</section>
<section title="Denial of Service">
<t>The IDP SHOULD resist protocol denial of service attacks.
</t>
<section title = "Rationale:">
<t>A common way to defeat secure communications systems is
through resource exhaustion. While this does not corrupt valid
messages, it can prevent any communication at all. It is desirable
that IDP resist such denial of service attacks.
</t>
</section>
<section title = "Scenario:">
<t>An attacker penetrates a network being defended by an
IDS. Although the attacker is not certain that an IDS is present,
he is certain that application-level encrypted traffic (i.e.,
IDMEF traffic) is being exchanged between components on the network
being attacked. He decides to mask his presence and disrupt the
encrypted communications by initiating one or more flood events.
If the IDP can resist such an attack, the probability that the
attacker will be stopped increases.
</t>
</section>
</section>
<section title="Message Duplication">
<t>The IDP SHOULD resist malicious duplication of messages.
</t>
<section title = "Rationale:">
<t>A common way to impair the performance of secure
communications mechanisms is to duplicate the messages being
sent, even though the attacker might not understand them, in an
attempt to confuse the receiver. It is desirable that the IDP
resist such message duplication.
</t>
</section>
<section title = "Scenario:">
<t>An attacker penetrates a network being defended by an
IDS. The attacker suspects that an IDS is present and quickly
identifies the encrypted traffic flowing between system components
as being a possible threat. Even though she cannot read this
traffic, she copies the messages and directs multiple copies at
the receiver in an attempt to confuse it. If the IDP resists
such message duplication, the probability that the attacker will
be stopped increases.
</t>
</section>
</section>
</section>
<section anchor="messageContent" title="Message Content Requirements">
<section title="Detected Data">
<t>There are many different types of IDSs,
such as those based on: signatures, anomalies, correlation,
network monitoring, host monitoring, or application monitoring.
The IDMEF design MUST strive to accommodate these diverse
approaches by concentrating on conveying *what* an IDS has
detected, rather than *how* it detected it.
</t>
<section title = "Rationale:">
<t>Rationale: There are many types of IDSs
that analyze a variety of data sources. Some are profile based
and operate on log files, attack signatures etc. Others are
anomaly based and define normal behavior and detect deviations
from the established baseline. Each of these IDSs reports
different data that, in part, depends on their intrusion
detection methodology. All MUST be supported by this standard.
</t>
</section>
</section>
<section title="Event Identity">
<t>The content of IDMEF messages MUST contain the identified
name of
the event (event identity) if it is known.
This name MUST be drawn from a
standardized list of events (if available)
or will be an implementation-specific
name if the event identity has not yet been standardized. It is
not known how this standardized list will be defined or updated.
Requirements on the creation of this list are beyond our
efforts. Other groups within the security arena are
investigating the creation of such lists.
</t>
<section title = "Rationale:">
<t>Given that this document presents requirements on
standardizing ID message formats so that an ID manager is able to
receive alerts from analyzers from multiple implementations, it
is important that the manager understand the semantics of the
reported events. There is, therefore, a need to identify known
events and store information concerning their methods and
possible fixes to these events. Some events are well known and
this recognition can help the operator.
</t>
</section>
<section title = "Scenario:">
<t>Intruder launches an attack that is detected by two
different analyzers from two distinct implementations. Both
report the same event identity to the ID manager, even though the
algorithms used to detect the attack by each analyzer might have
been different.
</t>
</section>
</section>
<section title="Event Background Information">
<t>The IDMEF message design MUST include information, which the
sender should provide, that allows a receiver to locate background
information on the kind of event that is being reported in the
alert.
</t>
<section title = "Rationale:">
<t>This information is used by administrators to report
and fix problems.
</t>
</section>
<section title = "Scenario:">
<t>Attacker performs a well-known attack. A reference to a
URL to background information on the attack is included in the
IDMEF message. The operator uses this information to initiate
repairs on the vulnerable system.
</t>
</section>
</section>
<section title="Additional Data">
<t>The IDMEF message MUST be able to reference additional detailed
data related to this specific underlying event. It is OPTIONAL
for implementations to use this field. No requirements are placed
on the format or content of this field. It is expected that this
will be defined and described by the implementor.
</t>
<section title = "Rationale:">
<t>Operators might want more information on specifics of
an event. This field, if filled in by the analyzer, MAY point
to additional or more detailed information about the event.
</t>
</section>
</section>
<section title="Event Source and Target Identity">
<t>The IDMEF message MUST contain the identity of the source of the
event and target component identifier if it is known. In the case
of a network-based event, this will be the source and destination
IP address of the session used to launch the event. Note that the
identity of source and target will vary for other types of
events, such as those launched/detected at the operating system
or application level.
</t>
<section title = "Rationale:">
<t>This will allow the operator to identify the source
and target of the event.
</t>
</section>
</section>
<section title="Device Address Types">
<t>The IDMEF message MUST support the representation of different
types of device addresses.
</t>
<section title = "Rationale:">
<t>A Device is a uniquely addressable element on the network.
(i.e., not limited to computers or networks nor
a specific level of the network protocol hierarchy).
Additionally, devices involved in
an intrusion event might use addresses that are not IP-centric.
</t>
</section>
<section title = "Scenario:">
<t>The IDS recognizes an intrusion on a particular device
and includes both the IP address and the MAC address of the
device in the IDMEF message. In another situation, the IDS
recognizes an intrusion on a device which has only a MAC address
and includes only that address in the IDMEF message. Another
situation involves analyzers in an ATM switch fabric which use
E.164 address formats.
</t>
</section>
</section>
<section title="Event Impact">
<t>The IDMEF message MUST contain an indication of the possible
impact of this event on the target. The IDMEF design document
MUST define the scope of this value.
</t>
<section title = "Rationale:">
<t>Information concerning the possible impact of the
event on the target system provides an indication of what the
intruder is attempting to do and is critical data for the
operator to perform damage assessment. Not all systems will be
able to determine this, but it is important data to transmit for
those systems that can. This requirement places no requirements
on the list itself (e.g., properties of the list, maintenance,
etc.), rather the requirement only specifies that the IDMEF
must contain a field for specifying the impact and that the IDMEF
must define the scope of such values.
</t>
</section>
</section>
<section title="Automatic Response">
<t>The IDMEF message MUST provide information about the automatic
actions taken by the analyzer in response to the event (if any).
</t>
<section title = "Rationale:">
<t>It is very important for the operator to know if
there was an automated response and what that response was. This
will help determine what further action to take, if any.
</t>
</section>
</section>
<section title=" Analyzer Location">
<t>The IDMEF message MUST include information which would make it
possible to later identify and locate the individual analyzer
which reported the event.
</t>
<section title = "Rationale:">
<t>The identity of the detecting analyzer often proves to
be a valuable piece of data to have in determining how to respond
to a particular event.
</t>
</section>
<section title = "Scenario:">
<t>Scenario: One interesting scenario involves the progress of an
intrusion event throughout a network. If the same event is
detected and reported by multiple analyzers, the identity of the
analyzer (in the case of a network-based analyzer) might provide
some indication of the network location of the target systems and
might warrant a specific type of response. This might be
implemented as an IP address.
</t>
</section>
</section>
<section title="Analyzer Identity">
<t>The IDMEF message MUST be able to contain the identity of the
implementor and the analyzer that detected the event.
</t>
<section title = "Rationale:">
<t>Rationale: Users might run multiple IDSs
to protect their enterprise. This data will help the systems
administrator determine which implementor and analyzer
detected the event.
</t>
</section>
<section title = "Scenario:">
<t>Analyzer X from implementor Y detects a potential
intrusion. A message is sent reporting that it found a potential
break-in with X and Y specified. The operator is therefore able
to include the known capabilities or weaknesses of analyzer X
in his
decision regarding further action.
</t>
</section>
</section>
<section title="Degree of Confidence">
<t>The IDMEF message MUST be able to state the degree of confidence
of the report. The completion of this field by an analyzer is
OPTIONAL, as this data might not be available at all analyzers.
</t>
<section title = "Rationale:">
<t>Many IDSs contain thresholds to determine
whether or not to generate an alert. This might influence the
degree of confidence one has in the report or perhaps would
indicate the likelihood of the report being a false alarm.
</t>
</section>
<section title = "Scenario:">
<t>The alarm threshold monitor is set at a low level to
indicate that an organization wants reports on any suspicious
activity, regardless of the probability of a real attack. The
degree of confidence measure is used to indicate if this is a low
probability or high probability event.
</t>
</section>
</section>
<section title="Alert Identification">
<t>The IDMEF message MUST be uniquely identifiable in that it can be
distinguished from other IDMEF messages.
</t>
<section title = "Rationale:">
<t>An IDMEF message might be sent by multiple
geographically-distributed analyzers at different times. A unique
identifier will allow an IDMEF message to be identified
efficiently for data reduction and correlation purposes.
</t>
</section>
<section title = "Scenario:">
<t>The unique identifier might consist of a unique
originator identifier (e.g. IPv4 or IPv6 address) concatenated
with a unique sequence number generated by the originator. In a
typical IDS deployment, a low-level event analyzer will log the
raw sensor information into, e.g., a database while analyzing
and reporting results to higher levels. In this case, the unique
raw message identifier can be included in the result message as
supporting evidence. Higher level analyzers can later use this
identifier to retrieve the raw message from the database if
necessary.
</t>
</section>
</section>
<section title="Alert Creation Date and Time ">
<t>The IDMEF MUST support reporting alert creation date and time in
each event, where the creation date and time refer to the date
and time that the analyzer decided to create an alert.
The IDMEF MAY support additional dates and times, such as
the date and time the
event reference by the alert began.
</t>
<section title = "Rationale:">
<t>Time is important from both a reporting and
correlation point of view.
Event onset time might differ from the alert creation time
because it might take some time for the sensor to accumulate
information about a monitored activity before generating the
event, and additional time for the analyzer to receive the event
and create an alert. The event onset time is therefore more
representative of the actual time that the reported activity
began than is the alert creation time.
</t>
</section>
<section title = "Scenario:">
<t>If an event is reported in the quiet hours of the
night, the operator might assign a higher priority to it than she
would to the same event reported in the busy hours of the day.
Furthermore, an event (like a lengthy port scan) may take place
over a long period of time and it would be useful for the
analyzer to report the time of the alert as well as the time the
event began.
</t>
</section>
</section>
<section title="Time Synchronization">
<t>Time SHALL be reported such that events from multiple analyzers
in different time zones can be received by the same manager and
that the local time at the analyzer can be inferred.
</t>
<section title = "Rationale:">
<t>For event correlation purposes, it is important that
the manager be able to normalize the time information reported
in the IDMEF alerts.
</t>
</section>
<section title = "Scenario:">
<t>A distributed ID system has analyzers located in
multiple timezones, all reporting to a single manager. An
intrusion occurs that spans multiple timezones as well as
multiple analyzers. The central manager requires sufficient
information to normalize these alerts and determine that all were
reported near the same "time" and that they are part of the
same attack.
</t>
</section>
</section>
<section title="Time Format">
<t>The format for reporting the date MUST be compliant with all
current standards for Year 2000 rollover, and it MUST have
sufficient capability to continue reporting date values past the
year 2038.
</t>
<section title = "Rationale:">
<t>It is desirable that the IDMEF have a long lifetime and
that implementations be suitable for use in a variety of
environments. Therefore, characteristics that limit the lifespan
of the IDMEF (such as 2038 date representation limitation) MUST be
avoided.
</t>
</section>
</section>
<section title="Time Granularity and Accuracy">
<t>Time granularity and time accuracy in event messages SHALL NOT be
specified by the IDMEF.
</t>
<section title = "Rationale:">
<t>The IDMEF cannot assume a certain clock granularity on
sensing elements, and so cannot impose any requirements on the
granularity of the event timestamps. Nor can the IDMEF assume that
the clocks being used to timestamp the events have a specified
accuracy.
</t>
</section>
</section>
<section title="Message Extensions">
<t>The IDMEF message MUST support an extension mechanism used by
implementors to define implementation-specific data. The use of
this mechanism by the implementor is OPTIONAL. This data contains
implementation-specific information determined by each
implementor. The implementor MUST indicate how to interpret these
extensions, although there are no specific requirements placed on
how implementors describe their implementation-specific
extensions. The lack or presence of such message extensions
for implementation-specific data
MUST NOT break interoperation.
</t>
<section title = "Rationale:">
<t>Implementors might wish to supply extra data such as
the version number of their product or other data that they
believe provides value added due to the specific nature of their
product. Implementors may publish a document or web site
describing their extensions; they might also use an in-band
extension mechanism that is self-describing. Such extensions
are not a license to break the interoperation of IDMEF messages.
</t>
</section>
</section>
<section title="Message Semantics ">
<t>The semantics of the IDMEF message MUST be well defined.
</t>
<section title = "Rationale:">
<t>Good semantics are key to understanding what the
message is trying to convey so there are no errors. Operators
will decide what action to take based on these messages, so it is
important that they can interpret them correctly.
</t>
</section>
<section title = "Scenario:">
<t>Without this requirement, the operator receives an IDMEF
message and interprets it one way. The implementor who
constructed the message intended it to have a different meaning
from the operator's interpretation. The resulting corrective
action is, therefore, incorrect.
</t>
</section>
</section>
<section title="Message Extensibility">
<t>The IDMEF itself MUST be extensible. As new ID technologies emerge
and as new information about events becomes available, the IDMEF
message format MUST be able to include this new information.
Such message extensibility must occur in such a manner that
interoperability is NOT impacted.
</t>
<section title = "Rationale:">
<t>As intrusion detection technology continues to evolve,
it is likely that additional information relating to detected
events will become available. The IDMEF message format MUST be able
to be extended by a specific implementation to encompass this new
information. Such extensions
are not a license to break the interoperation of IDMEF messages.
</t>
</section>
</section>
</section>
<section anchor="sec" title="Security Considerations">
<t>
This document does not treat security matters, except that Section 5
specifies
security requirements for the protocols to be developed.
</t>
</section>
</middle>
<back>
<references title='Informative References'>
<?rfc include="reference.RFC.2026" ?>
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2277" ?>
<?rfc include="reference.RFC.2828" ?>
</references>
<section title="History of Significant Changes" anchor="changes">
<t>The RFC Editor should remove this section and its corresponding TOC
references prior to publication.</t>
<section title="Significant Changes Since requirements-09">
<t>
Change section 6.17, Message Extensions, to indicate that
such extensions CANNOT affect interoperability
</t>
<t>
Change section 6.19, Message Extensions, to indicate that
such extensions CANNOT affect interoperability
</t>
<t>
Add a Reference Section and some related anchors
</t>
</section>
</section>
<section anchor="ack" title="Acknowledgements">
<t>The following individuals contributed substantially to this document and
should be recognized for their efforts. This document would not exist
without their help:
<list style="empty">
<t>Mark Crosbie, Hewlett-Packard</t>
<t>David Curry, IBM Emergency Response Services</t>
<t>David Donahoo, Air Force Information Warfare Center</t>
<t>Mike Erlinger, Harvey Mudd College</t>
<t>Fengmin Gong, Microcomputing Center of North Carolina</t>
<t>Dipankar Gupta, Hewlett-Packard</t>
<t>Glenn Mansfield, Cyber Solutions, Inc.</t>
<t>Jed Pickel, CERT Coordination Center</t>
<t>Stuart Staniford-Chen, Silicon Defense</t>
<t>Maureen Stillman, Nokia IP Telephony</t>
</list>
</t>
</section>
</back>
</rfc>