Internet-Draft Wood, M.
Internet Engineering Task Force Internet Security Systems
Intrusion Detection Exchange Format Working Group September, 1999
Category: Informational
Intrusion Detection Message Exchange Requirements
<draft-ietf-idwg-requirements-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work
in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Distribution of this memo is unlimited.
This Internet Draft expires March 17, 2000.
1. Abstract
The purpose of the Intrusion Detection Exchange Format 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 communication, including the rationale for
those requirements. Scenarios are used to illustrate the
requirements.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [1].
3. Introduction
This document defines requirements for the Intrusion Detection Exchange
Format (IDEF), which is the intended work product of the Intrusion
Detection Exchange Format Working Group (IDWG). IDEF is planned to be
a standard format which automated Intrusion Detection Systems can use
for reporting events which they have deemed to be suspicious.
Wood Informational - March 17, 2000 1
3.1 Rationale
The reasons such a format should be useful are as follows:
1) A number of commercial and free Intrusion Detection Systems (IDS) are
available and more are coming onto the market 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 customers
will buy more than a single product. And customers will want to
observe the output of these products from a one or more manager(s). A
standard format for reporting events will simplify this task greatly.
2) Intrusions frequently involve multiple organizations as victims, or
multiple sites within the same organization. Typically, those sites
will use different ID systems. 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
3) The existence of a common format should allow components from
different ID systems to be integrated more readily. ID research
should be able to be integrated into commercial products more easily.
4) We feel that, in addition to enabling communication from an ID
analyzer to an ID manager, the IDEF notification system may also
enable communications between a variety of IDS components. However,
for the remainder of this document, we refer to the communications as
going from an analyzer to a manager.
All of these reasons suggest that a common format for reporting
suspicious events 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.
3.2 Intrusion Detection Terms
In order to make the rest of the requirements clearer, we define some
terms about typical intrusion detection systems. 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.
3.2.1 Activity:
Instantiations of 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 sessions, user activity, and
application events.
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).
3.2.2 Administrator:
The human with responsibility for the day-to-day maintenance and
management of organizational security. This individual may or may not
be the same person charged with the deployment of the intrusion
detection system and may or may not be the same person that is actually
Wood Informational - March 17, 2000 2
monitoring the output 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.
3.2.3 Alert:
A message from an analyzer to a manager that an event has been detected.
An alert typically contains information about the unusual activity that
was detected, as well as the specifics of the occurrence.
3.2.4 Analyzer:
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 ID systems, 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 IDEF message.
3.2.5 Data Source:
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.
3.2.6 Event:
The occurrence in the data source that is detected by the analyzer and
which may result in an IDEF alert being transmitted. For example, three
failed logins in 10 seconds might indicate a brute-force login attack.
3.2.7 IDS:
Intrusion detection system. Some combination of one or more of the
following components: sensor, analyzer, manager. No assumptions about
the architecture of the IDS are put forth in this document beyond the
definition found here.
3.2.8 Manager:
The ID component or process from which the security administrator
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.
3.2.9 Notification:
The method by which the IDS manager makes the operator aware of the
event occurrence. In many ID systems, 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.
3.2.10 Operator:
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.
Wood Informational - March 17, 2000 3
3.2.11 Response:
The actions taken in response to an event. Responses may be undertaken
automatically by some entity in the ID system 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.
3.2.12 Sensor:
The ID component that collects data from the data source. The
frequency of data collection will vary across IDS offerings.
3.2.13 Signature:
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 ID systems detect
intrusions.
3.2.14 Security Policy:
The predefined, formally documented statement which defines what
services are allowed to be transported across the monitored segment of
the network to support the business requirement. This includes, but it
not limited to, which hosts are to be denied external network access.
________
| |
| Data |_________ __________
| Source | Activity | |
|________| | | Operator |_________
| | | |
| |__________| |
. . . .\|/ . . . . . A |
. _____V___ . /|\ |
. | | . \ |
. | Sensor |__ . \ |
. | | | . Notification |
. |_________| Event . \ \|/
. A | _________ . \ V
. /|\ | | | . \ Response
. | --->| Analyzer|__ . | A
. | | | Alert | /|\
. | |_________| |. | |
.| . . . . . . . A . . .| | |
| /|\ \|/ | |
|________________| ____V___ | |
| | |__| |
| | Manager|_________|
| | |
| |________|
| A
Security /|\
_______________ | Policy__________|
| | |
| Administrator |__|
| |
|_______________|
Wood Informational - March 17, 2000 4
The diagram above illustrates the terms above and their relationships.
3.3 Architectural Assumptions
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 is
what IDEF proposes to standardize.
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 IDEF alerts is considered.
We try to make no further architectural assumptions than those just
stated. For example, the following points should not matter:
* Whether the sensor and the analyzer are integrated or separate.
* Whether the analyzer and manager are isolated, or embedded in some
large hierarchy or distributed mesh of components.
* Whether the manager actually notifies a human, takes action
automatically, or just analyzes incoming alerts and correlates them.
* A component might act as an analyzer with respect to one component,
but as a manager with respect to another.
3.4 Organization of this document.
Besides this requirements document, the IDWG working group should
produce two other documents. The first should describe a data format or
language for exchanging information about suspicious events. In this
document, we refer to that as the "data-format specification". The
second document 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. We refer to this as the
"communication specification".
Accordingly, the requirements here are partitioned into five sections
* The first of these contains general requirements that apply to all
aspects of the IDEF specification.
* The second section describes requirements on the formatting of IDEF
messages.
* The third section outlines requirements on the communications
mechanism used to move IDEF messages from the analyzer to the
manager.
* The fourth section contains requirements on the content and
semantics of the IDEF messages.
* The final section places requirements on IDEF event definitions and
the event definition process.
For each requirement, we attempt to state the requirement as clearly as
Wood Informational - March 17, 2000 5
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.
3.5 Document Impact on IDEF Designs
It is expected that proposed IDEF 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 IDEF
designs. It is recognized that the working group may use additional
metrics to evaluate competing IDEF designs.4. General Requirements4.1 The IDEF shall reference and use previously published RFCs where possible.
4.1.1 Rationale: 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 business to implement already defined and
accepted standards.
4.1.2 Scenario: IDEF specification proposals should rely heavily on
existing communications or encryption standards, where possible.
4.2 The IDEF must be able to operate in environments that contain IPv4
and IPv6 implementations.
4.2.1 Rationale: Since pure IPv4, hybrid IPv6/IPv4, and pure IPv6
environments are expected to exist within the timeframe of IDEF
implementations, the IDEF specification must support IPv6
and IPv4 environments.
4.2.2 Scenario: IDEF specification proposals should include detailed
descriptions of how they will operate in pure IPv4, pure IPv6, and
hybrid environments.
5. Message Format
The IDEF message format is intended to be independent of the IDEF
communications mechanism. Although use of the IDEF communications
mechanism whenever possible is recommended, other mechanisms may be
used when necessary.
5.1 IDEF message formats shall support full internationalization and localization.5.1.1 Rationale: Since network security and intrusion detection are areas that cross geographic, political, and cultural boundaries,
the IDEF messages must be formatted such that they can be
presented to an operator in a local language and adhering to local
presentation customs.
5.1.2 Scenario: An IDEF specification might include numeric event
identifiers. An IDEF 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.
5.2 The format of IDEF messages must support filtering and/or
aggregation of data by the manager.
Wood Informational - March 17, 2000 6
5.2.1 Rationale: Since it is anticipated that some managers may want to
perform filtering and/or data aggregation functions on IDEF
messages, the IDEF messages must be structured to facilitate these
operations.
5.2.2 Scenario: An IDEF specification proposal might recommend fixed
format messages with strong numerical semantics. This would lend
itself to high-performance filtering and aggegration by the
receiving station.
6. Communications Mechanism Requirements
6.1 The IDEF must support reliable transmission of messages.
6.1.1 Rationale: IDS managers often rely on receipt of data from IDS
analyzers to do their jobs effectively. Since IDS managers will
rely on IDEF messages for this purpose, it is important,
therefore, that IDEF messages be delivered reliably.
6.1.2 Scenario: The IDEF system might rely upon TCP reliability
mechanisms or might design its own reliable protocol for use with
UDP.
6.2 The IDEF must support transmission of messages between ID
components across firewall boundaries without compromising
security.
6.2.1 Rationale: Since it is expected that firewalls will often be
deployed between IDEF analyzers and their corresponding managers,
the ability to send IDEF messages through 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 conflating IDEF
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 IDEF traffic and other
kinds of traffic.
6.2.2 Scenario: One possible design is the use of TCP to convey IDEF
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 customer. 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.
6.3 The IDEF must support mutual authentication of the analyzer and
the manager to each other.
6.3.1 Rationale: Since the alert messages are used by a manager to
direct responses or further investigation related to the security
Wood Informational - March 17, 2000 7
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
based on authentication of the underlying communications
mechanism, for example, because of the risk that this
authentication process may be subverted or misconfigured.
6.3.2 Scenario: Analyzer process authenticates itself to manager process
via public key exchange or some other method. Manager process does
the same to the analyzer process.
6.4 The IDEF 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.
6.4.1 Rationale: IDEF 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.
6.4.2 Scenario: The IDEF system might offer two different encryption
modules, one using 168-bit keys and another using 56-bit keys.
6.5 The IDEF 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.
6.5.1 Rationale: IDEF 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.
6.5.2 Scenario: An integrity hash, such as the MD5 algorithm, might be
part of the IDEF design.
6.6 The IDEF communications mechanism should be able to ensure non-
repudiation of the origin of IDEF messages.
6.6.1 Rationale: Given that sensitive security information is being
exchanged with the IDEF, it is important that the humans operating
the system are able to associate messages with the originating
IDEF entity.
6.6.2 Scenario: If an attacker is able to inject IDEF messages
masquerading as a legitimate IDEF source, he can insert misleading
messages to divert the console operator's attention while
launching an attack.
Wood Informational - March 17, 2000 8
6.7 The IDEF communications mechanism should resist protocol denial of
service attacks.
6.7.1 Rationale: 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 the IDEF communications mechanism resist such denial of
service attacks.
6.7.2 Scenario: 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.,
IDEF 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 IDEF can resist such an attack, the probability that the
attacker will be stopped increases.
6.8 The IDEF communications mechanism should resist malicious
duplication of messages.
6.8.1 Rationale: A common way to impair the performance of secure
communications mechanisms is to duplicate the messages being
sent, even though you might not understand them, in an attempt
to confuse the receiver. It is desirable that the IDEF
communications mechanism resist such message duplication.
6.8.2 Scenario: At 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 IDEF resists
such message duplication, the probability that the attacker will
be stopped increases.
7. Message Content
7.1 The IDEF message must encompass all types of intrusion detection
mechanisms currently available as well as those expected to be
available in the future. These include, but are not limited to:
Signature-based detection systems
Anomaly-based detection systems
Correlation-based detection systems
Network-based detection systems
Host-based detection systems
Application-based detection systems
7.1.1 Rationale: There are many types of intrusion detection systems
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 systems report
different data that, in part, depends on their intrusion
detection methodology. All must be supported by this standard.
7.1.2 Scenario: An attacker invents a new attack. The profile-based
Wood Informational - March 17, 2000 9
system does not detect it. An anomaly-based system detects the
novel attack but it cannot provide an attack type in an alert
message.
7.2 The content of IDEF messages must contain the identified name of
the event if it is known. This name will be drawn from a
standardized list of events or will be an implementation-specific
name if the event identity has not yet been standardized. It is
not known how this list will be defined or updated, although
requirements on the creation of this list are presented in the
next section of this document.
7.2.1 Rationale: Given that this document presents requirements on
standardizing ID message formats so that an ID manager may
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.
7.2.2 Scenario: 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 may have
been different.
7.3 The IDEF message must be structured such that any associated
advisory authority, such as the CERT, can be inferred.
7.3.1 Rationale: This information is used by administrators to report
and fix problems.
7.3.2 Scenario: Attacker performs a well-known attack. A reference to
the appropriate CERT advisory is included in IDEF message since
the implementer has access to a list of CERT advisory numbers.
Operator uses this information to initiate repairs on the
vulnerable system.
7.4 The IDEF message must be able to reference additional detailed
data related to this specific underlying event. It is optional
for implementations to use this field.
7.4.1 Rationale: Operators may 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.
7.4.2 Scenario: Attacker attacks host and is detected by ID system.
IDEF message contains a pointer to a set of records that gives
access to system audit data.
7.5 The IDEF 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
Wood Informational - March 17, 2000 10
events, such as those launched/detected at the operating system
or application level.
7.5.1 Rationale: This will allow the operator to identify the source
and target of the event.
7.5.2 Scenario: Intruder launches a network attack against a DNS server
using a buffer overflow attack. The IDEF alert message indicates
the DNS server as the target and includes the source IP address
used to launch the attack.
7.6 The IDEF message must support the representation of different
types of device addresses.
7.6.1 Rationale: Devices involved in an intrusion may have addresses in
various levels of the network protocol hierarchy (e.g., level 2
and level 3 addresses). Additionally, the devices involved in an
intrusion event may use addresses that are not IP-centric.
7.6.2 Scenario: The IDS recognizes an intrusion on a particular device
and includes both the IP address and the MAC address of the
device in the IDEF 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 IDEF message. Another
situation involves analyzers in an ATM switch fabric which use
E.164 address formats.
7.7 The IDEF message must contain an indication of the possible
impact of this event on the target. The value of this field will
be drawn from a standardized list of values.
7.7.1 Rationale: 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.
7.7.2 Scenario: A buffer overflow attack is launched and detected by
the ID analyzer. The IDEF message may contain information that
this buffer overflow attack is of impact type "attempt to gain
root or administrator privilege" on the target system. The ID
operator may use this data to increase the priority of the
response.
7.8 The IDEF message must provide information about the automatic
actions taken by the analyzer in response to the event (if any).
7.8.1 Rationale: 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.
7.8.2 Scenario: The attacker launches the attack, the ID system detects
the attack and disables the user account performing the
suspicious activity. This suspension is for 10 minutes to allow
the operator time to investigate the suspicious activity. The
IDEF message contains this information.
Wood Informational - March 17, 2000 11
7.9 The IDEF message must include information which would make it
possible to later identify and locate the individual analyzer
which reported the event.
7.9.1 Rationale: 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.
7.9.2 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
may warrant a specific type of response. This might be
implemented as an IP address.
7.10 The IDEF message must be able to contain the identity of the
implementer and the tool that detected the event.
7.10.1 Rationale: Users may run multiple intrusion detection systems to
protect their enterprise. This data will help the systems
administrator determine which implementer and tool detected the
event.
7.10.2 Scenario: Tool X from implementer 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 tool X in his
decision regarding further action.
7.11 The IDEF 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 may not be available at all analyzers.
7.11.1 Rationale: Many ID systems contain thresholds to determine
whether or not to generate an alert. This may influence the
degree of confidence one has in the report or perhaps would
indicate the likelihood of the report being a false alarm.
7.11.2 Scenario: 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.
7.12 The IDEF message must be uniquely identifiable in that it can be
distinguished from other IDEF messages.
7.12.1 Rationale: An IDEF message may be sent by multiple
geographically-distributed analyzers at different times. A unique
identifier will allow an IDEF message to be identified
efficiently for data reduction and correlation purposes.
7.12.2 Scenario: The unique identifier may 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
Wood Informational - March 17, 2000 12
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.
7.13 The IDEF must support reporting alert creation date and time in
each event. The IDEF may support reporting the event detection
date and time in addition to the alert creation date and time.
7.13.1 Rationale: Time is important from both a reporting and
correlation point of view. Event detection time may differ from
the alert creation time as it may take some time to actually
generate the alert message given that an event has been detected.
If the sensing element can determine the time the event occurred
it is strongly encouraged to place that information in the alert
message as well.
7.13.2 Scenario: If an event is reported in the quiet hours of the
night, the operator may assign a higher priority to it than she
would to the same event reported in the busy hours of the day.
7.14 Time shall be reported as the localtime and time zone offset on
the system generating the message. [See RFC 1902 [2] for
guidelines on reporting time.] (supporting reporting across
multiple timezones and correlating across multiple timezones).
7.14.1 Rationale: For event correlation purposes, it is important that
the manager be able to normalize the events.
7.14.2 Scenario: 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 at roughly the same "time" and that they are part of the
same attack.
7.15 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.
7.15.1 Rationale: It is desirable that the IDEF have a long lifetime and
that implementations be suitable for use in a variety of
environments. Therefore, characteristics that limit the lifespan
of the IDEF (such as 2038 date representation limitation) must be
avoided.
7.15.2 Scenario: An IDEF implementation is built for a ruggedized,
focused environment and is expected to operate in this
environment with minimal upkeep for 50 years.
7.16 Time granularity in event messages shall not be specified by the
IDEF.
Wood Informational - March 17, 2000 13
7.16.1 Rationale: The IDEF cannot assume a certain clock granularity on
sensing elements, and so cannot impose any requirements on the
granularity of the event timestamps.
7.16.2 Scenario: One analyzer has a clock granularity of 1 millisecond
while another analyzer has a clock granularity of 1 second. Both
analyzers should be able to send compliant IDEF messages.
7.17 The IDEF message must support an extension mechanism used by
implementers to define implementation-specific data. The use of
this mechanism by the implementer is optional. This data contains
implementation-specific information determined by each
implementer. The implementer must indicate how to interpret these
extensions.
7.17.1 Rationale: Implementers may 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.
7.17.2 Scenario: The implementer passes back detailed information
specific to her product after it detects an event.
7.18 The semantics of the IDEF message must be well defined.
7.18.1 Rationale: Good semantics are key to understanding what the
message is trying to convey so there are no errors due to
confusion over exactly what the message means. Operators will
decide what action to take based on these messages, so it is
important that they can interpret them correctly.
7.18.2 Scenario: Without this requirement, the operator receives an IDEF
message and interprets it one way. The implementer who
constructed the message intended it to have a different meaning
from the operator's interpretation. The resulting corrective
action is, therefore, incorrect.
8. Event Definitions and the Event-Definition Process
8.1 The standard list of IDEF events must be extensible. As new events
are defined by the community and as new methods of detecting them
are available, the IDEF must be able to grow with the technology.
8.1.1 Rationale: New intrusions are rapidly created; some are variations
of existing intrusions and some are newly created intrusion
techniques. If IDEF is not extensible then the usefulness of the
standard will quickly diminish.
8.1.2 Scenario: A specific implementation creates a new attack
signature. Using the IDEF process, the implementer is able to
exhibit this signature quickly to the intrusion detection
community.
8.2 The IDEF itself must be extensible. As new ID technologies emerge
and as new information about events becomes available, the IDEF
message format must be able to include this new information.
Wood Informational - March 17, 2000 14
8.2.1 Rationale: As intrusion detection technology continues to evolve,
it is likely that additional information relating to detected
events will become available. The IDEF message format must be able
to be extended by a specific implementation to encompass this new
information.
8.2.2 Scenario: A new type of ID analyzer is built which is able to
identify the true login name of an attacker as well as the series
of system hops he's using to attack the target system. The
implementer should be able to include this new information in the
IDEF in the IDEF message.
8.3 The standard event definitions must be extensible by implementers
and administrators.
8.3.1 Rationale: The IDEF will specify the basic information for each
intrusion. To distinguish their offerings, different implementers
desire the ability to provide additional information beyond that
required for IDEF. Additionally, specific implementations may want
to use the IDEF for non-standard events.
8.3.2 Scenario: An IDS detects a new event for which there is yet no
IDEF standard name. The implementer of that IDS sends an IDEF
message using a private, implementation-specific name.
8.4 The process by which new events are defined and standardized must
be implementation-independent.
8.4.1 Rationale: The process for new event definition must not favor one
IDS implementation over another, otherwise a specific IDS
implementation may determine that making event information
available to the community has a negative effect on that
implementation and may elect not to do so.
8.4.2 Scenario: Implementer A discovers a new intrusion event and
forwards that information to the IDEF event process. Implementer A
must view this as a positive action.
9. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Case, J., McCloghrie, K., Rose, M., Waldbusser, S., "Structure of
Management Information for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1902, January 1996.
Acknowledgements:
The following individuals contributed substantially to this document and
should be recognized for their efforts. This document would not exist
without their help:
Mark Crosbie, Hewlett-Packard
David Curry, IBM Emergency Response Services
David Donahoo, Air Force Information Warfare Center
Wood Informational - March 17, 2000 15
Mike Erlinger, Harvey Mudd College
Fengmin Gong, Microcomputing Center of North Carolina
Dipankar Gupta, Hewlett-Packard
Glenn Mansfield, Cyber Solutions, Inc.
Jed Pickel, CERT Coordination Center
Stuart Staniford-Chen, Silicon Defense
Maureen Stillman, Nokia IP Telephony
Editor's Address:
Mark Wood
Internet Security Systems, Inc.
6600 Peachtree-Dunwoody Road
300 Embassy Row
Atlanta, GA 30328
Phone: +1 (678) 443-6147
E-mail: mark1@iss.net
Intrusion Detection Exchange Format Working Group:
The Intrusion Detection Exchange Format Working Group can be contacted
via the working group's mailing list (idwg-public@zurich.ibm.com) or
through its chairs:
Stuart Staniford-Chen
stuart@SiliconDefense.com
Silicon Defense
Mike Erlinger
mike@cs.hmc.edu
Harvey Mudd College
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. This
document and translations of it may be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist
in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed.
Wood Informational - March 17, 2000 16
Datatracker
Report a datatracker bug
draft-ietf-idwg-requirements-01
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4766.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |