Subject: proposed IDMEF modifications (Message 3 of 4: action)

From: Cynthia McLain <[email-masked]>
Date: Wed, 24 Oct 2001 08:39:07 -0400

2. Action
=========

In early versions of the IDMEF data model, "Alert" had an attribute
named "reaction" which was described as "The countermeasure that was
applied to the attack" [1]. This attribute was subsequently removed.
In the most recent IDMEF document, the "reaction" attribute reappeared
as "action" which is described as "The action taken by the analyzer
(if any) in response to the event(s) that led up to the alert" [2].
In both cases the attribute is represented as free-form text.

It is foreseeable that Managers will be developed to process the action
information, either so they avoid taking actions that have already been
taken or to display the defensive measures already in place to the
system users. Because the action information will likely be processed
by an automated system, a more structured representation of the action
information will facilitate that analysis.

To provide a more structured representation of response information,
it is proposed that an "Action" element be defined and added as a
sub-element of "Alert" in lieu of the "action" attribute. Zero or more
"Action" elements would be allowed. The description of the action could
be represented as a string or as XML. This strategy provides more
information than using a single string and enables assigning attributes
to the "Action" element as more experience with actions is acquired in
the future.

In XML, the "Action" element would be added to the "Alert" element
as follows:

<!ELEMENT Alert (
    Analyzer, CreateTime, DetectTime?, AnalyzerTime?, Source*,
    Target*, Classification+, Action*, (ToolAlert | OverflowAlert |
    CorrelationAlert)?, AdditionalData*
)>

++++ Action element ++++

The Action element could be represented in XML as follows:

<!ELEMENT Action (
    description
)>
<!ATTLIST Action 
    ident               CDATA                   '0'
    category            %attvals.actcat;        'other'
    description_type    %attvals.desctype;      'string'

Where the attributes are  defined as follows:

<!--
 | Values for the Action.description_type attribute.
 -->
<!ENTITY % attvals.desctype "
   ( string | xml )
">

<!--
 | Values for the Action.category attribute.
 -->
<!ENTITY % attvals.actcat "
   ( other | block-installed | notification-sent | taken-offline )
">

The description element is parsed character data in either
string or xml format. The XML for the description is:

<!ELEMENT description   (#PCDATA)>

The Action class is composed of one class:

description
    One. A description of the action taken.

The Action class has three attributes:

ident
    Optional. A unique identifier for this action.

category
    Optional. The general category into which the action falls.

    Rank  Keyword            Description
    ----  -------            -----------
     0    other              Some action category other than the ones
provided.
     1    block-installed    An attempt was made to block further
attacks
                             from the identified source. Could be a
block
                             of the IP address or a block of a
particular
                             user.
     2    notification-sent  A notification was sent to an administrator
                             via e-mail, pager, etc. Does not include
                             transmission of this Alert.
     3    taken-offline      A system, computer, or user was taken off
line,
                             as when the computer is shut down or a user
is
                             logged off.

description_type
    Optional. The format of the Action description.

    Rank  Keyword            Description
    ----  -------            -----------
     0    string             The description is in a string.
     1    xml                The description is in XML.

Example Alert
=============

A. BIDS bottleneck verification alert using
draft-ietf-idwg-idmef-04.txt.
-------------------------------------------------------------------------
Notes: IP addresses, NTP timestamps, and other numeric values are bogus.
       A | appears at the beginning of lines that will be affected by
       the proposed modifications.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE IDMEF-Message PUBLIC "-//IETF//DTD RFCxxxx IDMEF v0.5//EN"
 "idmef-message.dtd">

 <IDMEF-message version="0.5">
|  <Alert impact="successful-admin" action="logout+disable">
     <Analyzer analyzerid="bids-123.123.123.123">
       <Node category="unknown">
         <name>mcs-001</name>
         <Address category="ipv4-addr">
           <address>123.123.123.123</address>
         </Address>
       </Node>
       <Process>
         <name>bids</name>
         <pid>12345</pid>
         <path>/usr/local/sbin</path>
         <arg>-r</arg>
       </Process>
     </Analyzer>
     <CreateTime ntpstamp="0x12345678.0x87654321">
       2001-08-14T21:21:32Z
     </CreateTime>
     <DetectTime ntpstamp="0x12345678.0x87654321">
       2001-08-14T21:21:21Z
     </DetectTime>
     <Source spoofed="no">
       <Node>
         <location>console</location>
         <Address category="ipv4-addr">
           <address>123.123.123.123</address>
         </Address>
       </Node>
     </Source >
     <Target decoy="no">
       <Node>
         <location>local</location>
         <Address category="ipv4-addr">
           <address>123.123.123.123</address>
         </Address>
       </Node>
       <User category="os-device">
         <UserId type="original-user">
           <number>456</number>
         </UserId>
         <UserId type="current-user">
           <name>root</name>
           <number>0</number>
         </UserId>
         <UserId type="user-privs">
           <number>0</number>
         </UserId>
       </User>
       <Process>
         <name>eject</name>
         <path>/usr/bin/eject</path>
         <pid>12345</pid>
         <arg>exploit</arg>
       </Process>
     </Target >
     <Classification origin="vendor-specific">
       <name>U2S shell - normal user has obtained unauthorized
super-user shell<
/name>
       <url>file://</url>
     </Classification>
|    <AdditionalData type="string" meaning="action">
|      Logout user
|    </AdditionalData>
|    <AdditionalData type="string" meaning="action">
|      Disable user
|    </AdditionalData>
   </Alert>
 </IDMEF-message>

B. BIDS bottleneck verification alert using draft-ietf-idwg-idmef-04.txt
   with modifications.
------------------------------------------------------------------------
Notes: IP addresses, NTP timestamps, and other numeric values are bogus.
       A | appears at the beginning of lines affected by the proposed
       modifications.

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE IDMEF-Message PUBLIC "-//IETF//DTD RFCxxxx IDMEF
v0.5-modified//EN"
 "idmef-message.dtd">

 <IDMEF-message version="0.5">
|  <Alert impact="successful-admin">
     <Analyzer analyzerid="bids-123.123.123.123">
       <Node category="unknown">
         <name>mcs-001</name>
         <Address category="ipv4-addr">
           <address>123.123.123.123</address>
         </Address>
       </Node>
       <Process>
         <name>bids</name>
         <pid>12345</pid>
         <path>/usr/local/sbin</path>
         <arg>-r</arg>
       </Process>
     </Analyzer>
     <CreateTime ntpstamp="0x12345678.0x87654321">
       2001-08-14T21:21:32Z
     </CreateTime>
     <DetectTime ntpstamp="0x12345678.0x87654321">
       2001-08-14T21:21:21Z
     </DetectTime>
     <Source spoofed="no">
       <Node>
         <location>console</location>
         <Address category="ipv4-addr">
           <address>123.123.123.123</address>
         </Address>
       </Node>
     </Source >
     <Target decoy="no">
       <Node>
         <location>local</location>
         <Address category="ipv4-addr">
           <address>123.123.123.123</address>
         </Address>
       </Node>
       <User category="os-device">
         <UserId type="original-user">
           <number>456</number>
         </UserId>
         <UserId type="current-user">
           <name>root</name>
           <number>0</number>
         </UserId>
         <UserId type="user-privs">
           <number>0</number>
         </UserId>
       </User>
       <Process>
         <name>eject</name>
         <path>/usr/bin/eject</path>
         <pid>12345</pid>
         <arg>exploit</arg>
       </Process>
     </Target >
     <Classification origin="vendor-specific">
       <name>U2S shell - normal user has obtained unauthorized
super-user shell<
/name>
       <url>file://</url>
     </Classification>
|    <Action category="taken-offline" description_type="string">
|      <description>Logout User (fred)</description>
|    </Action>
|    <Action category="block-installed" description_type="string">
|      <description>Disable User (fred)</description>
|    </Action>
   </Alert>
 </IDMEF-message>

-----------------------------------------------------------------------
References:

[1] Debar, H. M. Huang, and D. Donahoo, "Intrusion Detection Exchange
       Format Data Model", draft-ietf-idwg-data-model-02.txt, March 7,
2000.

[2] Curry, D. and H. Debar, "Intrusion Detection Message Exchange
      Format Data Model and Extensible Markup Language (XML) Document
      Type Definition", draft-ietf-idwg-idmef-xml-04.txt, September 18,
2001.