tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4765

 
 
 

The Intrusion Detection Message Exchange Format (IDMEF)

Part 4 of 6, p. 79 to 103
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 79 
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

Top      Up      ToC       Page 80 
      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.

Top      Up      ToC       Page 81 
   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.

Top      Up      ToC       Page 82 
   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:

Top      Up      ToC       Page 83 
   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.

Top      Up      ToC       Page 84 
   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

Top      Up      ToC       Page 85 
      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.

Top      Up      ToC       Page 86 
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>

Top      Up      ToC       Page 87 
   </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>

Top      Up      ToC       Page 88 
       <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>

Top      Up      ToC       Page 89 
         </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

Top      Up      ToC       Page 90 
       </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">

Top      Up      ToC       Page 91 
       <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>

Top      Up      ToC       Page 92 
   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>

Top      Up      ToC       Page 93 
         </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>

Top      Up      ToC       Page 94 
           <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>

Top      Up      ToC       Page 95 
       <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>

Top      Up      ToC       Page 96 
             <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">

Top      Up      ToC       Page 97 
           <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>

Top      Up      ToC       Page 98 
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>

Top      Up      ToC       Page 99 
         <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>

Top      Up      ToC       Page 100 
           <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.

Top      Up      ToC       Page 101 
   <?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"

Top      Up      ToC       Page 102 
                    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>

Top      Up      ToC       Page 103 
       <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 RFC Part