2.6.5 Intrusion Detection Exchange Format (idwg)

NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 04-Jun-99


Michael Erlinger <mike@cs.hmc.edu>
Stuart Staniford-Chen <stanifor@cs.ucdavis.edu>

Security Area Director(s):

Jeffrey Schiller <jis@mit.edu>
Marcus Leech <mleech@nortel.ca>

Security Area Advisor:

Jeffrey Schiller <jis@mit.edu>

Mailing Lists:

General Discussion:idwg-public@zurich.ibm.com
To Subscribe: idwg-public-request@zurich.ibm.com
Archive: http://www.semper.org/idwg-public/

Description of Working Group:

Security incidents are becoming more common and more serious, and intrusion detection systems are becoming of increasing commercial importance. Numerous intrusion detection systems are important in the market and different sites will select different vendors. Since incidents are often distributed over multiple sites, it is likely that different aspects of a single incident will be visible to different systems. Thus it would be advantageous for diverse intrusion detection systems to be able to share data on attacks in progress.

The purpose of the Intrusion Detection Working Group is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems, and to management systems which may need to interact with them. The Intrusion Detection Working Group will coordinate its efforts with other IETF Working Groups.

The outputs of this working group will be:

1. A requirements document, which describes the high-level functional requirements for communication between intrusion detection systems and requirements for communication between intrusion detection systems and with management systems, including the rationale for those requirements. Scenarios will be used to illustrate the requirements.

2. A common intrusion language specification, which describes data formats that satisfy the requirements.

3. A framework document, which identifies existing protocols best used for communication between intrusion detection systems, and describes how the devised data formats relate to them.

Goals and Milestones:

Apr 99


Submit Requirements document as an Internet-Draft

Aug 99


Submit Framework and Language documents as Internet-Drafts

Aug 99


Submit Requirements document to IESG for consideration as an RFC.

Dec 99


Submit Framework and Language documents to IESG for consideration as RFCs.


No Request For Comments

Current Meeting Report

The IDWG working group met at 9:00 on Thursday and at 9:00 on Friday at the 45th IETF meeting in Oslo, Norway. Both co-chairs were present, and Dave Donahoo took the minutes. Over the two sessions there were about 70 attendees.

The technical part of the first meeting was led by Mark Wood and focused on refining various requirements issues for inclusion in an internet draft. During the Friday meeting the group presented various design concepts and discussed alert contents and possible alternatives for expressing and transmitting alerts. These discussions were only for general information gathering.

The group decided to have an interim meeting in early September to focus on developing a common data dictionary. Dave Donahoo was tasked to collect current data requirements from various vendors and write document which will be used as the basis of discussion for the Sept meeting. The group consensus was that this was the first logical step in developing a common design concept.

Session I
0900-1130 15 July 1999
(Attendance 64)

9:00 Agenda Bashing
9:15 Requirements Internet Draft Review (Mark Wood)
11:15 Interim Meeting and RAID 99 (Mike Erlinger)

Session II
0900-1130 16 July 1999
(Attendance 50)

9:00 Requirements Internet Draft Review (Mark Wood)
9:30 Intrusion Detection Agent System Brief
9:45 IDEF Design Thoughts from CERT (Jed Pickle)
10:00 AXENT MIB (Vimal Vaidya)
10:30 Felix Wu's MIB presented by Mike Erlinger
11:00 Interim Meeting/RAID
11:15 Charter Discussion.

Session I
Mark Wood started the Internet Draft Requirements Document discussion with a brief historical account of the document and an outline of the general document structure.

Following this introduction the Mark led the group in an open and constructive discussion of the document. This review started with a review of the definitions and then moved through each requirement in the sequential order of the draft.

For the most part the definitions were acceptable as written. Only two minor problems were noted. First, the way the definitions are written there is no name for the connection from a sensor to an analyzer. Dave Donahoo presented a process model which clearly highlighted this point. A simple correction to the definition for Activity cleared this up and the group agreed. Dave was tasked to provide an ASCII version of the definition model for inclusion in this document.

| |
| Data |_____ __________
| Source | Event |
|________| | | Operator
| |
| |
|__________ | |
. . . . \|/ . . . . .
A |
. _____V___ . /|\
. | | .
\ |
. | Sensor |__ . \
. | | | .
Notification |
. |_________ | Activity . \
. A | _________ . \
. /|\ | | | .
\ Response
. | --->| Analyzer |__ .
| A
. | | | Alert
| /|\
. | |_________| |.
| |
.| . . . . . . . A . . . |.
| |
| /|\ \|/
| |
|________________| ____V___ |
| |
|__| |
| | Manager
| |
| |________|
| A
Security /|\
_______________ | Policy__________|
| | |
| Administrator |__|
| |

The Second point was made that we need a definition of the term Intrusion Detection System (IDS) Mark Wood took this on as an action item.

The following paragraphs were accepted by the group with little or no discussions/objections and were corrected on the spot:

4.1, 4.2. 5.1, 5.2. 6.1, 6.2, 6.3, 6.4, 6.5, 6.7, 6.8, 7.1, 7.3, 7.5, 7.6, 7.9, 7.10, 7.12, 7,13, 7.14, 8.2, 8.3

The following paragraphs require significant work or rewrite:

- 6.6 Rational and scenario must be developed. Must clearly define the concept of non-repudiation. (Stuart)
- 7.2 Needs to be broken down into three separate requirements. (Mark Wood)
- 7.4 There is some confusion to the group over how to determine potential. This will become a mailing list topic. Jed Pickel will put something out.
- 7.7 Message should contain identity of item which located the event. (needs further discussion on the list (Mark Wood).
- 7.8 This item requires further discussion on the list (Mark Wood)
- 7.11 While the intent was to develop the message semantics which are well defined and machine readable, the rational and scenario read that the message semantics should be people readable. The discussion will be brought to the mailing list. (Mark Wood)
- 8.1 Difficult at best. How do we determine compliance? What is the requirement here. The intent is that we recognize the need for a process to extend the IDEF--to add new fields that we don't know of in today's ID environment. Need more mailing list discussion on this (Mike Erlinger)

Session II

The majority of this session was devoted to briefings of various design/implementations of IDS. At the time this minutes were completed the electronic versions of these briefings had not been received. They will be provided to the list as soon as possible. The following is a list of each brief:

Intrusion Detection Agent System Brief IDEF Design Thoughts from CERT (Jed Pickle) AXENT MIB (Vimal Vaidya) Felix Wu's MIB presented by Mike Erlinger

The most significant point captured from these briefings was that it would be helpful if we had captured existing data fields from various vendors and merged the data into common data elements. This appears to be a great starting point for our Sept Interim meeting. Dave Donahoo volunteered to ping the list for a data call and consolidate the data into some form for consideration on the list and discussions in Sept.

Interim Meeting is possibly to be held in conjunction with the RAID meeting at Perdue University during the week of 6-10 Sept.


None received.