ID Message Exchange Format Working Group Glenn Mansfield INTERNET-DRAFT Cyber Solutions Inc. draft-glenn-id-notification-mib-04.txt November 20,2000 Intrusion Detection Message MIB Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines the contents of messages that will be exchanged among intrusion detection systems when an intrusion is detetcted. Expires: May 19, 2001 [Page 1] Internet Draft November 20, 2000 Table of Contents 1. The SNMP Network Management Framework ......................... 3 2. The Intrusion Detection Message Exchange Model ................ 4 3. MIB Model for ID Message Exchanges ............................ 5 4. MIB design .................................................... 6 5. The Intrusion Detection Message MIB ........................... 7 6. Intellectual Property .........................................37 7. Acknowledgements ..............................................37 8. References ....................................................38 Security Considerations ...........................................40 Authors' Addresses ................................................41 Full Copyright Statement ..........................................42 Expires: May 19, 2001 [Page 2] Internet Draft November 20, 2000 1. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [RFC2571]. o Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. o Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. o Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905]. o A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine Expires: May 19, 2001 [Page 3] Internet Draft November 20, 2000 readable information is not considered to change the semantics of the MIB. 2. The Intrusion detection model. An Intrusion Detection system (ID1) generally comprises an Analyzer which scans Data Sources for signs of intrusions. When it detects a sign or a signature, an event occurs. The analyzer then sends a Message or Alert to the Manager(s). Managers in turn may exchange Messages or Alerts for cooperative or collaborative purposes. ID Message Exchange Model ========================= ............................................................. ID1 : : +------------+------------+ +----------------+ : | | | | | : | | |Message | | : | DataSource | Analyzer |---------->| Manager | : | | ..........|Alert | | : | | : Event | | | : +------------+------------+ +--------X-------+ : ID1 | : Message/| ID2 : Alert | : | : | : +--------X-------+ : | | : | | : | Manager | : | | : | | : +----------------+ : Expires: May 19, 2001 [Page 4] Internet Draft November 20, 2000 3. MIB Model for ID Message Exchanges. In Intrusion detection and management, the communication between the different components of the system will essentially be event based. Presumably, some components (analysers or agents) will be assigned the tasks for watching some data-sources and looking out for signs of (attepmpted) intrusions or attacks. In case any such sign is detected it is brought to the notice of the Manager. The Manager will then take the appropriate action which may involve relaying the notification and/or carrying out further investigation by talking to peers, higher level managers and/or the entity that originated the notification. The investigation carried out by the manager will possibly involve getting o more information on some of the fields that are present in the messages from the agents. [Maybe using Http, ftp ] o more host-related information on the circumstances under which the intrusion/attack was detected - this may involve fetching further information from the various MIBs of the entity that originated the notification. o more network-related information on the circumstances under which the intrusion/attack was detected - this may involve fetching further information from the various MIBs of the relevant network entities in the network The notification to the manager will take the form of an inform- request. There may be several types of notifications. The constraint on a notification is its size. It is desirable that the packet carrying the notification is not fragmented at the IP level. The MIB defined in this document covers the portion which is specific to the Intrusion Detection Message itself. The other components of information that may be of relevance to the investigation will probably be found in the various MIBs defined. If they are absent then newer MIBs will have to be defined. Expires: May 19, 2001 [Page 5] Internet Draft November 20, 2000 4. MIB design. The basic design principle has been to keep the MIB as simple as possible. The generic requirements on the ID Alert messages are o ID Alerts should contain the minimum information required by the manager to assess the situation correctly and to take appropriate defensive or investigative steps. o ID Alerts, if carried in UDP datagrams, should not be too large as to require IP fragmentation. [If SNMP is used as the the application protocol, some managers may not accept SNMP-PDUs that are larger than 484 bytes.] An additional requirement is to retain the similarity of this MIB with the XML-DTD as the primary objective of this MIB is to map Alerts in XML to corresponding SMI objects which can be communicated to SNMP-entities. The MIB comprises of the idAlertObjects described below. o The idAlertObjects subtree defines the objects that are used in the notifications. This contains objects of three categories (i) Objects pertaining to the Alert originator (ii) A table in which each row represents details pertaining to an Alert (iii)Supplementary tables - idTimeTable - idDTimeTable - idAnTimeTable - idClassificationTable - idSourceTable - idTargetTable - idToolAlertTable - idOverflowAlertTable - idCorrelationAlertTable - idAdditionalDataTable - idArgumentsTable - idUserTable - idProcessTable - idAddressTable - idNodeTable - idAnalyzerTable - idEnvironmentTable - idServiceTable Expires: May 19, 2001 [Page 6] Internet Draft November 20, 2000 5. The Intrusion Detection Message MIB. INTRUSION-DETECTION-ALERT-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, Counter32, Gauge32, OBJECT-TYPE, OBJECT-IDENTITY, IpAddress, mib-2 FROM SNMPv2-SMI DateAndTime, TimeStamp FROM SNMPv2-TC SnmpAdminString FROM SNMP-FRAMEWORK-MIB MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF URLString FROM NETWORK-SERVICES-MIB; idMIB MODULE-IDENTITY LAST-UPDATED "200011200000Z" -- 20th November 2000 ORGANIZATION "IETF Intrusion Detection Message Exchange Format Working Group" CONTACT-INFO " Glenn Mansfield Postal: Cyber Solutions Inc. 6-6-3, Minami Yoshinari Aoba-ku, Sendai, Japan 989-3204. Tel: +81-22-303-4012 Fax: +81-22-303-4015 E-mail: glenn@cysols.com Working Group E-mail: idwg-public@zurich.ibm.com To subscribe: idwg-public-request@zurich.ibm.com" DESCRIPTION " The MIB for Intrusion Detection Messages." REVISION "200007250000Z" -- 25th July 2000 DESCRIPTION "First draft of the idMIB" REVISION "200011160000Z" -- 16th November 2000 DESCRIPTION "Revised to reflect the structure of the objects in the XML-DTD. Syntactic nits removed." REVISION "200011200000Z" -- 20th November 2000 DESCRIPTION "Syntactic nits removed." Expires: May 19, 2001 [Page 7] Internet Draft November 20, 2000 ::= { mib-2 xxx } -- to be assigned by IANA idAlertObjects OBJECT-IDENTITY STATUS current DESCRIPTION " This is the base object for the objects used in the alert notifications." ::= {idMIB 1} -- idAlertTable: The Table of Alerts. Each row represents an Alert. -- AlertID is the key to the table idAlertTable OBJECT-TYPE SYNTAX SEQUENCE OF IdAlertEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " Each row of this table contains information about an alert indexed by idAlertID." ::= { idAlertObjects 1 } idAlertEntry OBJECT-TYPE SYNTAX IdAlertEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " Entry containing information pertaining to an alert." INDEX { idAlertID} ::= { idAlertTable 1 } IdAlertEntry ::= SEQUENCE { idAlertVersion INTEGER, idAlertID INTEGER, idAlertImpact INTEGER } idAlertVersion OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " The version of the class hierarchy used in defining the alert." ::= {idAlertEntry 1} Expires: May 19, 2001 [Page 8] Internet Draft November 20, 2000 idAlertID OBJECT-TYPE SYNTAX INTEGER (1..2147483647) MAX-ACCESS read-only STATUS current DESCRIPTION " The AlertID uniquely identifies each alert generated by an analyzer." ::= {idAlertEntry 2} -- will be enumerated to represent the allowed types idAlertImpact OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-only STATUS current DESCRIPTION "An indication of the impact of the (potential) impact of the event on the system." ::= {idAlertEntry 3} idTimeTable OBJECT-TYPE SYNTAX SEQUENCE OF IdTimeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " Each row of this table contains information about the time of an alert indexed by idAlertID." ::= { idAlertObjects 2 } idTimeEntry OBJECT-TYPE SYNTAX IdTimeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " Entry containing information pertaining to the time an alert was generated." INDEX { idAlertID} ::= { idTimeTable 1 } IdTimeEntry ::= SEQUENCE { idTimeOffset SnmpAdminString, idTimeNtpStamp SnmpAdminString, idTimeDate SnmpAdminString, idTimeTime SnmpAdminString } Expires: May 19, 2001 [Page 9] Internet Draft November 20, 2000 idTimeOffset OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " Specifies the offset from Coordinated Universal Time UTC, formerly referred to as Greenwich Mean Time that the and