requirement
Click on the red underlined text to get to the source
...
This document defines requirements for the Intrusion Detection
Message Exchange Format (IDMEF) [5 ...
... IDSs) [4] could 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
...
... communication protocols. If IDWG determines that a new communication
protocol is necessary, the requirements in this document can be used
to evaluate proposed solutions.
...
...
o 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.
...
...
In order to make the rest of the requirements clearer, we define some
terms about typical IDSs. These terms are presented in alphabetical
...
... network or
on particular hosts to support the organization's requirements. This
includes, but is not limited to, which hosts are to be denied
...
...
The Trust Model is not specified as a requirement, but is rather left
to the choice of the IDMEF Communication Protocol, i.e., a design
...
... decision. What is specified are individual security-related
requirements; see Section 5.
We try to make no further architectural assumptions ...
...
Besides this requirements document, the IDWG should produce two other
documents. The first should describe a data format ...
... 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 ...
... IDMEF Communication Protocol).
Accordingly, the requirements here are partitioned into four
sections:
...
... sections:
o The first of these contains general requirements that apply to all
aspects of the IDMEF specification (Section 3).
...
... IDMEF specification (Section 3).
o The second section describes requirements on the formatting of
IDMEF messages (Section 4).
...
... IDMEF messages (Section 4).
o The third section outlines requirements on the communications
mechanism, IDP, used to move IDMEF ...
... the manager (Section 5).
o The final section contains requirements on the content and
semantics of the IDMEF ...
... IDMEF messages (Section 6).
For each requirement, we attempt to state the requirement as clearly
...
... 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 ...
... 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
...
... 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 ...
... General Requirements ...
... Message Format Requirements ...
... transport mechanism without changing the IDMEF
format. The goal behind this requirement is to ensure a clean
separation between semantics and communication mechanisms.
...
... Message Content Requirements ...
... 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 ...
...
Given that this document presents requirements on standardizing ID
message formats so that an ID manager is able to receive alerts ...
... 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 ...
... 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 ...
... 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
...
... 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
...
... 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 ...
... 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
...
...
Without this requirement, the operator receives an IDMEF message and
interprets it one way. The implementor ...
... This document does not treat security matters, except that Section 5
specifies security requirements for the protocols to be developed.
...
... Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. ...