RFC 4765
The Intrusion Detection Message Exchange Format (IDMEF)
Pages: 157
Experimental
Experimental
Part 4 of 6 – Pages 79 to 103
5. Extending the IDMEF
As intrusion detection systems evolve, the IDMEF data model and DTD will have to evolve along with them. To allow new features to be added as they are developed, both the data model and the DTD can be extended as described in this section. As these extensions mature, they can then be incorporated into future versions of the specification.5.1. Extending the Data Model
There are two mechanisms for extending the IDMEF data model, inheritance and aggregation: o Inheritance denotes a superclass/subclass type of relationship where the subclass inherits all the attributes, operations, and
relationships of the superclass. This type of relationship is
also called a "is-a" or "kind-of" relationship. Subclasses may
have additional attributes or operations that apply only to the
subclass and not to the superclass.
o Aggregation is a form of association in which the whole is related
to its parts. This type of relationship is also referred to as a
"part-of" relationship. In this case, the aggregate class
contains all of its own attributes and as many of the attributes
associated with its parts as required and specified by occurrence
indicators.
Of the two mechanisms, inheritance is preferred, because it preserves
the existing data model structure and also preserves the operations
(methods) executed on the classes of the structure.
Note that the rules for extending the IDMEF DTD (see below) set
limits on the places where extensions to the data model may be made.
5.2. Extending the IDMEF DTD
There are two ways to extend the IDMEF DTD:
1. The AdditionalData class (see Section 4.2.4.6) allows
implementors to include arbitrary "atomic" data items (integers,
strings, etc.) in an Alert or Heartbeat message. This approach
SHOULD be used whenever possible. See Section 7.4 and
Section 7.5.
2. The AdditionalData class allows implementors to extend the IDMEF
DTD with additional DTD "modules" that describe arbitrarily
complex data types and relationships. The remainder of this
section describes this extension method.
To extend the IDMEF DTD with a new DTD "module", the following steps
MUST be followed:
1. The document declaration MUST define a DTD location that defines
the namespace and contains the location of the extension DTD, and
then reference that namespace.
2. Multiple extensions may be included by defining multiple
namespaces and DTD locations, and referencing them.
3. Extension DTDs MUST declare all of their elements and attributes
in a separate XML namespace. Extension DTDs MUST NOT declare any
elements or attributes in the "idmef" or default namespaces.
4. Extensions MUST only be included in IDMEF Alert and Heartbeat
messages under an <AdditionalData> element whose "type" attribute
contains the value "xml". For example:
In this example, the "vendorco" namespace is defined and then
referenced, causing the DTD for the extension to be read by the XML
parser.
<idmef:IDMEF-Message version="1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:idmef="http://iana.org/idmef"
xmlns:vendorco="http://vendor.com/idmef"
xsi:schemaLocation="http://vendor.com/idmef http://v.com/vidmef.xsd">
<idmef:Alert messageid="...">
...
<idmef:AdditionalData type="xml" meaning="VendorExtension">
<idmef:xml>
<vendorco:TestVendor a="attribute of example"
xmlns:vendorco="http://vendor.com/idmef"
xsi:schemaLocation="http://vendor.com/idmef http://v.com/vidmef.xsd">
<vendorco:content>content element of example</vendorco:content>
</vendorco:TestVendor>
</idmef:xml>
</idmef:AdditionalData>
</idmef:Alert>
</idmef:IDMEF-Message>
See Section 7.8 for another example of extending the IDMEF DTD.
6. Special Considerations
This section discusses some of the special considerations that must
be taken into account by implementors of the IDMEF.
6.1. XML Validity and Well-Formedness
It is expected that IDMEF-compliant applications will not normally
include the IDMEF DTD itself in their communications. Instead, the
DTD will be referenced in the document type definition in the IDMEF
message. Such IDMEF documents will be well-formed and valid as
defined in [3].
Other IDMEF documents will be specified that do not include the
document prolog (e.g., entries in an IDMEF-format database). Such
IDMEF documents will be well-formed but not valid.
Generally, well-formedness implies that a document has a single element that contains everything else (e.g., "<Book>") and that all the other elements nest nicely within each other without any overlapping (e.g., a "chapter" does not start in the middle of another "chapter"). Validity further implies that not only is the document well-formed, but it also follows specific rules (contained in the Document Type Definition) about which elements are "legal" in the document, how those elements nest within other elements, and so on (e.g., a "chapter" does not begin in the middle of a "title"). A document cannot be valid unless it references a DTD. XML processors are required to be able to parse any well-formed document, valid or not. The purpose of validation is to make the processing of that document (what's done with the data after it's parsed) easier. Without validation, a document may contain elements in nonsense order, elements "invented" by the author that the processing application doesn't understand, and so forth. IDMEF documents MUST be well-formed. IDMEF documents SHOULD be valid whenever both possible and practical.6.2. Unrecognized XML Tags
On occasion, an IDMEF-compliant application may receive a well- formed, or even well-formed and valid, IDMEF message containing tags that it does not understand. The tags may be either: o Recognized as "legitimate" (a valid document), but the application does not know the semantic meaning of the element's content; or o Not recognized at all. IDMEF-compliant applications MUST continue to process IDMEF messages that contain unknown tags, provided that such messages meet the well- formedness requirement of Section 6.1. It is up to the individual application to decide how to process (or ignore) any content from the unknown elements(s).6.3. Analyzer-Manager Time Synchronization
Synchronization of time-of-day clocks between analyzers and managers is outside the scope of this document. However, the following comments and suggestions are offered:
1. Whenever possible, all analyzers and managers should have their
time-of-day clocks synchronized to an external source such as NTP
[7] or SNTP [8] Global Positioning System (GPS), Geosynchronous
Operational Environmental Satellite (GOES), NIST radio station
WWV clocks, or some other reliable time standard.
2. When external time synchronization is not possible, the IDMEF
provides the <AnalyzerTime> element, which may be used to perform
rudimentary time synchronization (see below).
3. IDMEF-compliant applications SHOULD permit the user to enable/
disable the <AnalyzerTime> method of time synchronization as a
configuration option.
A number of caveats apply to the use of <AnalyzerTime> for time
synchronization:
1. <AnalyzerTime> works best in a "flat" environment where analyzers
report up to a single level of managers. When a tree topology of
high-level managers, intermediate relays, and analyzers is used,
the problem becomes more complex.
2. When intermediate message relays (managers or otherwise) are
involved, two scenarios are possible:
* The intermediaries may forward entire IDMEF messages, or may
perform aggregation or correlation, but MUST NOT inject delay.
In this case, time synchronization is end-to-end between the
analyzer and the highest-level manager.
* The intermediaries may inject delay, due to storage or
additional processing. In this case, time synchronization
MUST be performed at each hop. This means each intermediary
must decompose the IDMEF message, adjust all time values, and
then reconstruct the message before sending it on.
3. When the environment is mixed, with some analyzers and managers
using external time synchronization and some not, all managers
and intermediaries must perform <AnalyzerTime> synchronization.
This is because determining whether or not compensation is
actually needed between two parties rapidly becomes very complex,
and requires knowledge of other parts of the topology.
4. If an alert can take alternate paths, or be stored in multiple
locations, the recorded times may be different depending on the
path taken.
The above being said, <AnalyzerTime> synchronization is probably
still better than nothing in many environments. To implement this
type of synchronization, the following procedure is suggested:
1. When an analyzer or manager sends an IDMEF message, it should
place the current value of its time-of-day clock in an
<AnalyzerTime> element. This should occur as late as possible in
the message transmission process, ideally right before the
message is "put on the wire".
2. When a manager receives an IDMEF message, it should compute the
difference between its own time-of-day clock and the time in the
<AnalyzerTime> element of the message. This difference should
then be used to adjust the times in the <CreateTime> and
<DetectTime> elements (NTP timestamps should also be adjusted).
3. If the manager is an intermediary and sends the IDMEF message on
to a higher-level manager, and hop-by-hop synchronization is in
effect, it should regenerate the <AnalyzerTime> value to contain
the value of its own time-of-day clock.
6.4. NTP Timestamp Wrap-Around
From [8]:
Note that, since some time in 1968 (second 2,147,483,648) the most
significant bit (bit 0 of the integer part) has been set and that
the 64-bit field will overflow some time in 2036 (second
4,294,967,296). Should NTP or SNTP be in use in 2036, some
external means will be necessary to qualify time relative to 1900
and time relative to 2036 (and other multiples of 136 years).
There will exist a 200-picosecond interval, henceforth ignored,
every 136 years when the 64-bit field will be 0, which by
convention is interpreted as an invalid or unavailable timestamp.
IDMEF-compliant applications MUST NOT send a zero-valued NTP
timestamp unless they mean to indicate that it is invalid or
unavailable. If an IDMEF-compliant application must send an IDMEF
message at the time of rollover, the application should wait for 200
picoseconds until the timestamp will have a non-zero value.
Also from [8]:
As the NTP timestamp format has been in use for the last 17 years,
it remains a possibility that it will be in use 40 years from now
when the seconds field overflows. As it is probably inappropriate
to archive NTP timestamps before bit 0 was set in 1968, a
convenient way to extend the useful life of NTP timestamps is the
following convention:
If bit 0 is set, the UTC time is in the range 1968-2036 and UTC
time is reckoned from 0h 0m 0s UTC on 1 January 1900.
If bit 0 is not set, the time is in the range 2036-2104 and UTC
time is reckoned from 6h 28m 16s UTC on 7 February 2036.
Note that when calculating the correspondence, 2000 is not a leap
year. Note also that leap seconds are not counted in the
reckoning.
IDMEF-compliant applications in use after 2036-02-07T06:28:16Z MUST
adhere to the above convention.
6.5. Digital Signatures
Standard XML digital signature processing rules and syntax are
specified in [13]. XML Signatures provide integrity, message
authentication, and/or signer authentication services for data of any
type, whether located within the XML that includes the signature or
elsewhere.
The IDMEF requirements document [2] assigns responsibility for
message integrity and authentication to the communications protocol,
not the message format. However, in situations where IDMEF messages
are exchanged over other, less secure protocols, or in cases where
the digital signatures must be archived for later use, the inclusion
of digital signatures within an IDMEF message itself may be
desirable.
Specifications for the use of digital signatures within IDMEF
messages are outside the scope of this document. However, if such
functionality is needed, use of the XML Signature standard is
RECOMMENDED.
7. Examples
The examples shown in this section demonstrate how the IDMEF is used
to encode alert data. These examples are for illustrative purposes
only, and do not necessarily represent the only (or even the "best")
way to encode these particular alerts. These examples should not be
taken as guidelines on how alerts should be classified.
7.1. Denial-of-Service Attacks
The following examples show how some common denial-of-service attacks could be represented in the IDMEF.7.1.1. The "teardrop" Attack
Network-based detection of the "teardrop" attack. This shows the basic format of an alert. <?xml version="1.0" encoding="UTF-8"?> <idmef:IDMEF-Message xmlns:idmef="http://iana.org/idmef" version="1.0"> <idmef:Alert messageid="abc123456789"> <idmef:Analyzer analyzerid="hq-dmz-analyzer01"> <idmef:Node category="dns"> <idmef:location>Headquarters DMZ Network</idmef:location> <idmef:name>analyzer01.example.com</idmef:name> </idmef:Node> </idmef:Analyzer> <idmef:CreateTime ntpstamp="0xbc723b45.0xef449129"> 2000-03-09T10:01:25.93464-05:00 </idmef:CreateTime> <idmef:Source ident="a1b2c3d4"> <idmef:Node ident="a1b2c3d4-001" category="dns"> <idmef:name>badguy.example.net</idmef:name> <idmef:Address ident="a1b2c3d4-002" category="ipv4-net-mask"> <idmef:address>192.0.2.50</idmef:address> <idmef:netmask>255.255.255.255</idmef:netmask> </idmef:Address> </idmef:Node> </idmef:Source> <idmef:Target ident="d1c2b3a4"> <idmef:Node ident="d1c2b3a4-001" category="dns"> <idmef:Address category="ipv4-addr-hex"> <idmef:address>0xde796f70</idmef:address> </idmef:Address> </idmef:Node> </idmef:Target> <idmef:Classification text="Teardrop detected"> <idmef:Reference origin="bugtraqid"> <idmef:name>124</idmef:name> <idmef:url>http://www.securityfocus.com/bid/124</idmef:url> </idmef:Reference> </idmef:Classification> </idmef:Alert>
</idmef:IDMEF-Message>7.1.2. The "ping of death" Attack
Network-based detection of the "ping of death" attack. Note the identification of multiple targets, and the identification of the source as a spoofed address. NOTE: The URL has been cut to fit the IETF formating requirements. <?xml version="1.0" encoding="UTF-8"?> <idmef:IDMEF-Message version="1.0" xmlns:idmef="http://iana.org/idmef"> <idmef:Alert messageid="abc123456789"> <idmef:Analyzer analyzerid="bc-sensor01"> <idmef:Node category="dns"> <idmef:name>sensor.example.com</idmef:name> </idmef:Node> </idmef:Analyzer> <idmef:CreateTime ntpstamp="0xbc71f4f5.0xef449129"> 2000-03-09T10:01:25.93464Z </idmef:CreateTime> <idmef:Source ident="a1a2" spoofed="yes"> <idmef:Node ident="a1a2-1"> <idmef:Address ident="a1a2-2" category="ipv4-addr"> <idmef:address>192.0.2.200</idmef:address> </idmef:Address> </idmef:Node> </idmef:Source> <idmef:Target ident="b3b4"> <idmef:Node> <idmef:Address ident="b3b4-1" category="ipv4-addr"> <idmef:address>192.0.2.50</idmef:address> </idmef:Address> </idmef:Node> </idmef:Target> <idmef:Target ident="c5c6"> <idmef:Node ident="c5c6-1" category="nisplus"> <idmef:name>lollipop</idmef:name> </idmef:Node> </idmef:Target> <idmef:Target ident="d7d8"> <idmef:Node ident="d7d8-1"> <idmef:location>Cabinet B10</idmef:location> <idmef:name>Cisco.router.b10</idmef:name> </idmef:Node> </idmef:Target>
<idmef:Classification text="Ping-of-death detected">
<idmef:Reference origin="cve">
<idmef:name>CVE-1999-128</idmef:name>
<idmef:url>http://www.cve.mitre.org/cgi-bin/
cvename.cgi?name=CVE-1999-128</idmef:url>
</idmef:Reference>
</idmef:Classification>
</idmef:Alert>
</idmef:IDMEF-Message>
7.2. Port Scanning Attacks
The following examples show how some common port scanning attacks
could be represented in the IDMEF.
7.2.1. Connection to a Disallowed Service
Host-based detection of a policy violation (attempt to obtain
information via "finger"). Note the identification of the target
service, as well as the originating user (obtained, e.g., through RFC
1413 [11]).
<?xml version="1.0" encoding="UTF-8"?>
<idmef:IDMEF-Message version="1.0"
xmlns:idmef="http://iana.org/idmef">
<idmef:Alert messageid="abc123456789">
<idmef:Analyzer analyzerid="bc-sensor01">
<idmef:Node category="dns">
<idmef:name>sensor.example.com</idmef:name>
</idmef:Node>
</idmef:Analyzer>
<idmef:CreateTime ntpstamp="0xbc72541d.0x00000000">
2000-03-09T18:47:25+02:00
</idmef:CreateTime>
<idmef:Source ident="a123">
<idmef:Node ident="a123-01">
<idmef:Address ident="a123-02" category="ipv4-addr">
<idmef:address>192.0.2.200</idmef:address>
</idmef:Address>
</idmef:Node>
<idmef:User ident="q987-03" category="os-device">
<idmef:UserId ident="q987-04" type="target-user">
<idmef:name>badguy</idmef:name>
</idmef:UserId>
</idmef:User>
<idmef:Service ident="a123-03">
<idmef:port>31532</idmef:port>
</idmef:Service>
</idmef:Source>
<idmef:Target ident="z456">
<idmef:Node ident="z456-01" category="nis">
<idmef:name>myhost</idmef:name>
<idmef:Address ident="z456-02" category="ipv4-addr">
<idmef:address>192.0.2.50</idmef:address>
</idmef:Address>
</idmef:Node>
<idmef:Service ident="z456-03">
<idmef:name>finger</idmef:name>
<idmef:port>79</idmef:port>
</idmef:Service>
</idmef:Target>
<idmef:Classification text="Portscan">
<idmef:Reference origin="vendor-specific">
<idmef:name>finger</idmef:name>
<idmef:url>http://www.vendor.com/finger</idmef:url>
</idmef:Reference>
<idmef:Reference origin="vendor-specific"
meaning="general documentation">
<idmef:name>Distributed attack</idmef:name>
<idmef:url>http://www.vendor.com/distributed</idmef:url>
</idmef:Reference>
</idmef:Classification>
</idmef:Alert>
</idmef:IDMEF-Message>
7.2.2. Simple Port Scanning
Network-based detection of a port scan. This shows detection by a
single analyzer; see Section 7.5 for the same attack as detected by a
correlation engine. Note the use of <portlist> to show the ports
that were scanned.
<?xml version="1.0" encoding="UTF-8"?>
<idmef:IDMEF-Message version="1.0"
xmlns:idmef="http://iana.org/idmef">
<idmef:Alert messageid="abc123456789">
<idmef:Analyzer analyzerid="hq-dmz-analyzer62">
<idmef:Node category="dns">
<idmef:location>Headquarters Web Server</idmef:location>
<idmef:name>analyzer62.example.com</idmef:name>
</idmef:Node>
</idmef:Analyzer>
<idmef:CreateTime ntpstamp="0xbc72b2b4.0x00000000">
2000-03-09T15:31:00-08:00
</idmef:CreateTime>
<idmef:Source ident="abc01">
<idmef:Node ident="abc01-01">
<idmef:Address ident="abc01-02" category="ipv4-addr">
<idmef:address>192.0.2.200</idmef:address>
</idmef:Address>
</idmef:Node>
</idmef:Source>
<idmef:Target ident="def01">
<idmef:Node ident="def01-01" category="dns">
<idmef:name>www.example.com</idmef:name>
<idmef:Address ident="def01-02" category="ipv4-addr">
<idmef:address>192.0.2.50</idmef:address>
</idmef:Address>
</idmef:Node>
<idmef:Service ident="def01-03">
<idmef:portlist>5-25,37,42,43,53,69-119,123-514
</idmef:portlist>
</idmef:Service>
</idmef:Target>
<idmef:Classification text="simple portscan">
<idmef:Reference origin="vendor-specific">
<idmef:name>portscan</idmef:name>
<idmef:url>http://www.vendor.com/portscan</idmef:url>
</idmef:Reference>
</idmef:Classification>
</idmef:Alert>
</idmef:IDMEF-Message>
7.3. Local Attacks
The following examples show how some common local host attacks could
be represented in the IDMEF.
7.3.1. The "loadmodule" Attack
Host-based detection of the "loadmodule" exploit. This attack
involves tricking the "loadmodule" program into running another
program; since "loadmodule" is set-user-id "root", the executed
program runs with super-user privileges. Note the use of <User> and
<Process> to identify the user attempting the exploit and how he's
doing it.
<?xml version="1.0" encoding="UTF-8"?>
<idmef:IDMEF-Message version="1.0"
xmlns:idmef="http://iana.org/idmef">
<idmef:Alert messageid="abc123456789">
<idmef:Analyzer analyzerid="bc-fs-sensor13">
<idmef:Node category="dns">
<idmef:name>fileserver.example.com</idmef:name>
</idmef:Node>
<idmef:Process>
<idmef:name>monitor</idmef:name>
<idmef:pid>8956</idmef:pid>
<idmef:arg>monitor</idmef:arg>
<idmef:arg>-d</idmef:arg>
<idmef:arg>-m</idmef:arg>
<idmef:arg>idmanager.example.com</idmef:arg>
<idmef:arg>-l</idmef:arg>
<idmef:arg>/var/logs/idlog</idmef:arg>
</idmef:Process>
</idmef:Analyzer>
<idmef:CreateTime ntpstamp="0xbc7221c0.0x4ccccccc">
2000-03-09T08:12:32.3-05:00
</idmef:CreateTime>
<idmef:Source ident="a1a2">
<idmef:User ident="a1a2-01" category="os-device">
<idmef:UserId ident="a1a2-02"
type="original-user">
<idmef:name>joe</idmef:name>
<idmef:number>13243</idmef:number>
</idmef:UserId>
</idmef:User>
<idmef:Process ident="a1a2-03">
<idmef:name>loadmodule</idmef:name>
<idmef:path>/usr/openwin/bin</idmef:path>
</idmef:Process>
</idmef:Source>
<idmef:Target ident="z3z4">
<idmef:Node ident="z3z4-01" category="dns">
<idmef:name>fileserver.example.com</idmef:name>
</idmef:Node>
</idmef:Target>
<idmef:Classification text="Loadmodule attack"
ident="loadmodule">
<idmef:Reference origin="bugtraqid">
<idmef:name>33</idmef:name>
<idmef:url>http://www.securityfocus.com</idmef:url>
</idmef:Reference>
</idmef:Classification>
</idmef:Alert>
</idmef:IDMEF-Message>
The Intrusion Detection System (IDS) could also indicate that the
target user is the "root" user, and show the attempted command; the
alert might then look like:
<?xml version="1.0" encoding="UTF-8"?>
<idmef:IDMEF-Message version="1.0"
xmlns:idmef="http://iana.org/idmef">
<idmef:Alert messageid="abc123456789">
<idmef:Analyzer analyzerid="bc-fs-sensor13">
<idmef:Node category="dns">
<idmef:name>fileserver.example.com</idmef:name>
</idmef:Node>
<idmef:Process>
<idmef:name>monitor</idmef:name>
<idmef:pid>8956</idmef:pid>
<idmef:arg>monitor</idmef:arg>
<idmef:arg>-d</idmef:arg>
<idmef:arg>-m</idmef:arg>
<idmef:arg>idmanager.example.com</idmef:arg>
<idmef:arg>-l</idmef:arg>
<idmef:arg>/var/logs/idlog</idmef:arg>
</idmef:Process>
</idmef:Analyzer>
<idmef:CreateTime ntpstamp="0xbc7221c0.0x4ccccccc">
2000-03-09T08:12:32.3-05:00
</idmef:CreateTime>
<idmef:Source ident="a1a2">
<idmef:User ident="a1a2-01" category="os-device">
<idmef:UserId ident="a1a2-02" type="original-user">
<idmef:name>joe</idmef:name>
<idmef:number>13243</idmef:number>
</idmef:UserId>
</idmef:User>
<idmef:Process ident="a1a2-03">
<idmef:name>loadmodule</idmef:name>
<idmef:path>/usr/openwin/bin</idmef:path>
</idmef:Process>
</idmef:Source>
<idmef:Target ident="z3z4">
<idmef:Node ident="z3z4-01" category="dns">
<idmef:name>fileserver.example.com</idmef:name>
</idmef:Node>
<idmef:User ident="z3z4-02" category="os-device">
<idmef:UserId ident="z3z4-03" type="target-user">
<idmef:name>root</idmef:name>
<idmef:number>0</idmef:number>
</idmef:UserId>
</idmef:User>
<idmef:Process ident="z3z4-04">
<idmef:name>sh</idmef:name>
<idmef:pid>25134</idmef:pid>
<idmef:path>/bin/sh</idmef:path>
</idmef:Process>
</idmef:Target>
<idmef:Classification text="Loadmodule attack"
ident="loadmodule">
</idmef:Classification>
</idmef:Alert>
</idmef:IDMEF-Message>
Note that the identification of the classification is used.
7.3.2. The "phf" Attack
Network-based detection of the "phf" attack. Note the use of the
<WebService> element to provide more details about this particular
attack.
<?xml version="1.0" encoding="UTF-8"?>
<idmef:IDMEF-Message version="1.0"
xmlns:idmef="http://iana.org/idmef">
<idmef:Alert messageid="abc123456789">
<idmef:Analyzer analyzerid="bc-sensor01">
<idmef:Node category="dns">
<idmef:name>sensor.example.com</idmef:name>
</idmef:Node>
</idmef:Analyzer>
<idmef:CreateTime ntpstamp="0xbc71e980.0x00000000">
2000-03-09T08:12:32-01:00
</idmef:CreateTime>
<idmef:Source ident="abc123">
<idmef:Node ident="abc123-001">
<idmef:Address ident="abc123-002"
category="ipv4-addr">
<idmef:address>192.0.2.200</idmef:address>
</idmef:Address>
</idmef:Node>
<idmef:Service ident="abc123-003">
<idmef:port>21534</idmef:port>
</idmef:Service>
</idmef:Source>
<idmef:Target ident="xyz789">
<idmef:Node ident="xyz789-001" category="dns">
<idmef:name>www.example.com</idmef:name>
<idmef:Address ident="xyz789-002"
category="ipv4-addr">
<idmef:address>192.0.2.100</idmef:address>
</idmef:Address>
</idmef:Node>
<idmef:Service>
<idmef:port>8080</idmef:port>
<idmef:WebService>
<idmef:url>
http://www.example.com/cgi-bin/phf?/etc/group
</idmef:url>
<idmef:cgi>/cgi-bin/phf</idmef:cgi>
<idmef:http-method>GET</idmef:http-method>
</idmef:WebService>
</idmef:Service>
</idmef:Target>
<idmef:Classification text="phf attack">
<idmef:Reference origin="bugtraqid">
<idmef:name>629</idmef:name>
<idmef:url>
http://www.securityfocus.com/bid/629
</idmef:url>
</idmef:Reference>
</idmef:Classification>
</idmef:Alert>
</idmef:IDMEF-Message>
7.3.3. File Modification
Host-based detection of a race condition attack. Note the use of the
<File> to provide information about the files that are used to
perform the attack.
<?xml version="1.0" encoding="UTF-8"?>
<idmef:IDMEF-Message version="1.0"
xmlns:idmef="http://iana.org/idmef">
<idmef:Alert>
<idmef:Analyzer analyzerid="bids-192.0.2.1"
ostype="Linux"
osversion="2.2.16-3">
<idmef:Node category="hosts">
<idmef:name>etude</idmef:name>
<idmef:Address category="ipv4-addr">
<idmef:address>192.0.2.1</idmef:address>
</idmef:Address>
</idmef:Node>
</idmef:Analyzer>
<idmef:CreateTime ntpstamp="0xbc71e980.0x00000000">
2000-03-09T08:12:32-01:00
</idmef:CreateTime>
<idmef:Source spoofed="no">
<idmef:Node>
<idmef:location>console</idmef:location>
<idmef:Address category="ipv4-addr">
<idmef:address>192.0.2.1</idmef:address>
</idmef:Address>
</idmef:Node>
</idmef:Source>
<idmef:Target decoy="no">
<idmef:Node>
<idmef:location>local</idmef:location>
<idmef:Address category="ipv4-addr">
<idmef:address>192.0.2.1</idmef:address>
</idmef:Address>
</idmef:Node>
<idmef:User category="os-device">
<idmef:UserId type="original-user">
<idmef:number>456</idmef:number>
</idmef:UserId>
<idmef:UserId type="current-user">
<idmef:name>fred</idmef:name>
<idmef:number>456</idmef:number>
</idmef:UserId>
<idmef:UserId type="user-privs">
<idmef:number>456</idmef:number>
</idmef:UserId>
</idmef:User>
<idmef:File category="current" fstype="tmpfs">
<idmef:name>xxx000238483</idmef:name>
<idmef:path>/tmp/xxx000238483</idmef:path>
<idmef:FileAccess>
<idmef:UserId type="user-privs">
<idmef:name>alice</idmef:name>
<idmef:number>777</idmef:number>
</idmef:UserId>
<idmef:permission perms="read" />
<idmef:permission perms="write" />
<idmef:permission perms="delete" />
<idmef:permission perms="changePermissions" />
</idmef:FileAccess>
<idmef:FileAccess>
<idmef:UserId type="group-privs">
<idmef:name>user</idmef:name>
<idmef:number>42</idmef:number>
</idmef:UserId>
<idmef:permission perms="read" />
<idmef:permission perms="write" />
<idmef:permission perms="delete" />
</idmef:FileAccess>
<idmef:FileAccess>
<idmef:UserId type="other-privs">
<idmef:name>world</idmef:name>
</idmef:UserId>
<idmef:permission perms="noAccess" />
</idmef:FileAccess>
<idmef:Linkage category="symbolic-link">
<idmef:name>passwd</idmef:name>
<idmef:path>/etc/passwd</idmef:path>
</idmef:Linkage>
</idmef:File>
</idmef:Target>
<idmef:Classification text="DOM race condition">
<idmef:Reference origin="vendor-specific">
<idmef:name>DOM race condition</idmef:name>
<idmef:url>file://attack-info/race.html
</idmef:url>
</idmef:Reference>
</idmef:Classification>
</idmef:Alert>
</idmef:IDMEF-Message>
7.4. System Policy Violation
In this example, logins are restricted to daytime hours. The alert
reports a violation of this policy that occurs when a user logs in a
little after 10:00 pm. Note the use of <AdditionalData> to provide
information about the policy being violated.
<?xml version="1.0" encoding="UTF-8"?>
<idmef:IDMEF-Message version="1.0"
xmlns:idmef="http://iana.org/idmef">
<idmef:Alert messageid="abc123456789">
<idmef:Analyzer analyzerid="bc-ds-01">
<idmef:Node category="dns">
<idmef:name>dialserver.example.com</idmef:name>
</idmef:Node>
</idmef:Analyzer>
<idmef:CreateTime ntpstamp="0xbc72e7ef.0x00000000">
2000-03-09T22:18:07-05:00
</idmef:CreateTime>
<idmef:Source ident="s01">
<idmef:Node ident="s01-1">
<idmef:Address category="ipv4-addr">
<idmef:address>127.0.0.1</idmef:address>
</idmef:Address>
</idmef:Node>
<idmef:Service ident="s01-2">
<idmef:port>4325</idmef:port>
</idmef:Service>
</idmef:Source>
<idmef:Target ident="t01">
<idmef:Node ident="t01-1" category="dns">
<idmef:name>mainframe.example.com</idmef:name>
</idmef:Node>
<idmef:User ident="t01-2" category="os-device">
<idmef:UserId ident="t01-3" type="current-user">
<idmef:name>louis</idmef:name>
<idmef:number>501</idmef:number>
</idmef:UserId>
</idmef:User>
<idmef:Service ident="t01-4">
<idmef:name>login</idmef:name>
<idmef:port>23</idmef:port>
</idmef:Service>
</idmef:Target>
<idmef:Classification text="Login policy violation">
<idmef:Reference origin="user-specific">
<idmef:name>out-of-hours activity</idmef:name>
<idmef:url>http://my.company.com/policies
</idmef:url>
</idmef:Reference>
</idmef:Classification>
<idmef:AdditionalData type="date-time"
meaning="start-time">
<idmef:date-time>2000-03-09T07:00:00-05:00</idmef:date-time>
</idmef:AdditionalData>
<idmef:AdditionalData type="date-time"
meaning="stop-time">
<idmef:date-time>2000-03-09T19:30:00-05:00</idmef:date-time>
</idmef:AdditionalData>
</idmef:Alert>
</idmef:IDMEF-Message>
7.5. Correlated Alerts
The following example shows how the port scan alert from Section 7.2.2 could be represented if it had been detected and sent from a correlation engine, instead of a single analyzer. <?xml version="1.0" encoding="UTF-8"?> <idmef:IDMEF-Message version="1.0" xmlns:idmef="http://iana.org/idmef"> <idmef:Alert messageid="abc123456789"> <idmef:Analyzer analyzerid="bc-corr-01"> <idmef:Node category="dns"> <idmef:name>correlator01.example.com</idmef:name> </idmef:Node> </idmef:Analyzer> <idmef:CreateTime ntpstamp="0xbc72423b.0x00000000"> 2000-03-09T15:31:07Z </idmef:CreateTime> <idmef:Source ident="a1"> <idmef:Node ident="a1-1"> <idmef:Address ident="a1-2" category="ipv4-addr"> <idmef:address>192.0.2.200</idmef:address> </idmef:Address> </idmef:Node> </idmef:Source> <idmef:Target ident="a2"> <idmef:Node ident="a2-1" category="dns"> <idmef:name>www.example.com</idmef:name> <idmef:Address ident="a2-2" category="ipv4-addr"> <idmef:address>192.0.2.50</idmef:address> </idmef:Address> </idmef:Node> <idmef:Service ident="a2-3"> <idmef:portlist>5-25,37,42,43,53,69-119,123-514 </idmef:portlist> </idmef:Service> </idmef:Target> <idmef:Classification text="Portscan"> <idmef:Reference origin="vendor-specific"> <idmef:name>portscan</idmef:name> <idmef:url>http://www.vendor.com/portscan</idmef:url> </idmef:Reference> </idmef:Classification> <idmef:CorrelationAlert> <idmef:name>multiple ports in short time</idmef:name> <idmef:alertident>123456781</idmef:alertident> <idmef:alertident>123456782</idmef:alertident>
<idmef:alertident>123456783</idmef:alertident>
<idmef:alertident>123456784</idmef:alertident>
<idmef:alertident>123456785</idmef:alertident>
<idmef:alertident>123456786</idmef:alertident>
<idmef:alertident analyzerid="a1b2c3d4">987654321
</idmef:alertident>
<idmef:alertident analyzerid="a1b2c3d4">987654322
</idmef:alertident>
</idmef:CorrelationAlert>
</idmef:Alert>
</idmef:IDMEF-Message>
7.6. Analyzer Assessments
Host-based detection of a successful unauthorized acquisition of root
access through the eject buffer overflow. Note the use of
<Assessment> to provide information about the analyzer's evaluation
of and reaction to the attack.
<?xml version="1.0" encoding="UTF-8"?>
<idmef:IDMEF-Message version="1.0"
xmlns:idmef="http://iana.org/idmef">
<idmef:Alert>
<idmef:Analyzer analyzerid="bids-192.0.2.1">
</idmef:Analyzer>
<idmef:CreateTime ntpstamp="0xbc71e980.0x00000000">
2000-03-09T08:12:32-01:00
</idmef:CreateTime>
<idmef:Source spoofed="no">
<idmef:Node>
<idmef:location>console</idmef:location>
<idmef:Address category="ipv4-addr">
<idmef:address>192.0.2.1</idmef:address>
</idmef:Address>
</idmef:Node>
</idmef:Source>
<idmef:Target decoy="no">
<idmef:Node>
<idmef:location>local</idmef:location>
<idmef:Address category="ipv4-addr">
<idmef:address>192.0.2.1</idmef:address>
</idmef:Address>
</idmef:Node>
<idmef:User category="os-device">
<idmef:UserId type="original-user">
<idmef:number>456</idmef:number>
</idmef:UserId>
<idmef:UserId type="current-user">
<idmef:name>root</idmef:name>
<idmef:number>0</idmef:number>
</idmef:UserId>
<idmef:UserId type="user-privs">
<idmef:number>0</idmef:number>
</idmef:UserId>
</idmef:User>
<idmef:Process>
<idmef:name>eject</idmef:name>
<idmef:pid>32451</idmef:pid>
<idmef:path>/usr/bin/eject</idmef:path>
<idmef:arg>\x90\x80\x3f\xff...\x08/bin/sh</idmef:arg>
</idmef:Process>
</idmef:Target>
<idmef:Classification
text="Unauthorized administrative access">
<idmef:Reference origin="vendor-specific">
<idmef:name>Unauthorized user to superuser</idmef:name>
<idmef:url>file://attack-info/u2s.html</idmef:url>
</idmef:Reference>
</idmef:Classification>
<idmef:Assessment>
<idmef:Impact severity="high" completion="succeeded"
type="admin"/>
<idmef:Action category="notification-sent">
page
</idmef:Action>
<idmef:Action category="block-installed">
disabled user (fred)
</idmef:Action>
<idmef:Action category="taken-offline">
logout user (fred)
</idmef:Action>
<idmef:Confidence rating="high"/>
</idmef:Assessment>
</idmef:Alert>
</idmef:IDMEF-Message>
7.7. Heartbeat
This example shows a Heartbeat message that provides "I'm alive and
working" information to the manager. Note the use of
<AdditionalData> elements, with "meaning" attributes, to provide some
additional information.
<?xml version="1.0" encoding="UTF-8"?>
<idmef:IDMEF-Message version="1.0"
xmlns:idmef="http://iana.org/idmef">
<idmef:Heartbeat messageid="abc123456789">
<idmef:Analyzer analyzerid="hq-dmz-analyzer01">
<idmef:Node category="dns">
<idmef:location>Headquarters DMZ Network</idmef:location>
<idmef:name>analyzer01.example.com</idmef:name>
</idmef:Node>
</idmef:Analyzer>
<idmef:CreateTime ntpstamp="0xbc722ebe.0x00000000">
2000-03-09T14:07:58Z
</idmef:CreateTime>
<idmef:AdditionalData type="real" meaning="%memused">
<idmef:real>62.5</idmef:real>
</idmef:AdditionalData>
<idmef:AdditionalData type="real" meaning="%diskused">
<idmef:real>87.1</idmef:real>
</idmef:AdditionalData>
</idmef:Heartbeat>
</idmef:IDMEF-Message>
7.8. XML Extension
The following example shows how to extend the IDMEF DTD. In the
example, the VendorCo company has decided it wants to add geographic
information to the Node class. To do this, VendorCo creates a
Document Type Definition or DTD that defines how their class will be
formatted:
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:vendorco="http://vendor.com/idmef"
targetNamespace="http://vendor.com/idmef"
elementFormDefault="qualified" >
<xsd:annotation>
<xsd:documentation>
Intrusion Detection Message Exchange Format (IDMEF) Extension
for geographic information
</xsd:documentation>
</xsd:annotation>
<xsd:complexType name="NodeGeoType">
<xsd:sequence>
<xsd:element name="latitude"
type="xsd:string" />
<xsd:element name="longitude"
type="xsd:string" />
<xsd:element name="elevation"
type="xsd:string"
minOccurs="0"
maxOccurs="1" />
</xsd:sequence>
<xsd:attribute name="node-ident"
type="xsd:integer"
use="required"/>
</xsd:complexType>
<xsd:element name="NodeGeography" type="vendorco:NodeGeoType" />
</xsd:schema>
The VendorCo:NodeGeography class will contain the geographic data in
three aggregate classes, VendorCo:latitude, VendorCo:longitude, and
VendorCo:elevation. To associate the information in this class with
a particular node, the "VendorCo:node-ident" attribute is provided;
it must contain the same value as the "ident" attribute on the
relevant Node element.
To make use of this DTD now, VendorCo follows the rules in
Section 5.2 and defines a parameter entity called "x-vendorco" within
the Document Type Definition, and then references this entity. In
the alert, the VendorCo elements are included under the
AdditionalData element, with a "type" attribute of "xml", as shown
below.
<?xml version="1.0" encoding="UTF-8"?>
<idmef:IDMEF-Message version="1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:idmef="http://iana.org/idmef"
xmlns:vendorco="http://v.com/idmef"
xsi:schemaLocation="http://v.com/idmef http://v.com/geo.xsd">
<idmef:Alert messageid="abc123456789">
<idmef:Analyzer analyzerid="hq-dmz-analyzer01">
<idmef:Node category="dns">
<idmef:location>Headquarters DMZ Network</idmef:location>
<idmef:name>analyzer01.example.com</idmef:name>
</idmef:Node>
</idmef:Analyzer>
<idmef:CreateTime ntpstamp="0xbc723b45.0xef449129">
2000-03-09T10:01:25.93464-05:00
</idmef:CreateTime>
<idmef:Source ident="a1b2c3d4">
<idmef:Node ident="a1b2c3d4-001" category="dns">
<idmef:name>badguy.example.net</idmef:name>
<idmef:Address ident="a1b2c3d4-002" category="ipv4-net-mask">
<idmef:address>192.0.2.50</idmef:address>
<idmef:netmask>255.255.255.255</idmef:netmask>
</idmef:Address>
</idmef:Node>
</idmef:Source>
<idmef:Target ident="d1c2b3a4">
<idmef:Node ident="d1c2b3a4-001" category="dns">
<idmef:Address category="ipv4-addr-hex">
<idmef:address>0xde796f70</idmef:address>
</idmef:Address>
</idmef:Node>
</idmef:Target>
<idmef:Classification text="Teardrop">
<idmef:Reference origin="bugtraqid">
<idmef:name>124</idmef:name>
<idmef:url>http://www.securityfocus.com/bid/124</idmef:url>
</idmef:Reference>
</idmef:Classification>
<idmef:AdditionalData type="xml" meaning="node geo info">
<idmef:xml>
<vendorco:NodeGeography
xmlns:vendorco="http://vendor.com/idmef"
xsi:schemaLocation="http://v.com/idmef http://v.com/geo.xsd"
vendorco:node-ident="a1b2c3d4-001">
<vendorco:latitude>38.89</vendorco:latitude>
<vendorco:longitude>-77.02</vendorco:longitude>
</vendorco:NodeGeography>
</idmef:xml>
</idmef:AdditionalData>
</idmef:Alert>
</idmef:IDMEF-Message>
(next page on part 5)