2.6.3 Intrusion Detection Exchange Format (idwg)

NOTE: This charter is a snapshot of the 44th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 11-Feb-99

Chair(s):

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 Current Internet-Drafts
No Request For Comments

Current Meeting Report

The IDWG working group met at 9:30 on Monday, at 1:00 on Tuesday, and at 2:15 on Tuesday at the 44th IETF meeting in Minneapolis, Minnesota. Both co-chairs were present, and Dave Donahoo took the minutes. Over the three sessions there were about 80 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. The Tuesday meetings 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 May to focus on the requirements document.

IETF IDWG
Session I
0930-1130 15 March 1999
(Attendance 61)
Agenda:
5 Min Agenda Bashing
10 Min Intro
9. Purpose of Group
10. Summary of Last Meeting
90 Min Requirements
11. Early List
12. Comments/Discussion
Schedule Issues
13. Milestones
14. Interim Meeting

Agenda Bashing
Mike Erlinger (co-chair) opened this meeting with general comments. Reviewed agenda items listed above. Give summary of last meeting and then turn it over to Mark Wood for a discussion of the requirements.

Additionally we are looking at possibly holding an interim meeting sometime in May.

Mike also asked how many people planned to attend the summer meeting in Oslo - a significant number of folks responded they would be there. The concern was there would not be enough people there to get anything done but from the numbers indicating they would be there it looks as if that is no longer a concern and we will plan to meet then.

Agenda for tomorrow (Tuesday):
15. Sample attacks used
16. Attack data content
17. Discussion of stakeholders needs.

Mike opened it up for agenda bashing from the group. No comments were offered so we went with the agenda as proposed.

INTRODUCTION

Purpose Of Group

Mike put up our charter and read the objectives.
Define data formats and exchange procedures for sharing information of interest to intrusion detection response systems and management systems.

In working toward this goal, during the last meeting it was determined that the first step would be to develop a requirements document. That brings us to the first item we will discuss today--the requirements document.

Tomorrow we will be discussing a common intrusion detection specification language. With that the meeting was turned over to Mark Wood, editor, IDWG Requirements Document

REQUIREMENTS

Mark Wood opened the discussion of the requirements. Mark extracted these requirements, from the notions that were brought out during the first meeting and latter discussions on the mail list. He first sent them out to the mailing list as the first draft list of requirements.

Mark developed this list as a brainstorming concept, putting everything on the list without thought toward relevance. Now he would like to discuss the requirements with an eye towards relevance.

From this early list Mark would like to do three things
18. Eliminate those that are "out of scope"
19. Add detail required
20. ID Missing things

In this vein and in an attempt to jump-start the discussions, Mark offered three items on the list he felt would be "out of scope."

WHAT ITEMS ARE OUT OF SCOPE?

21. The protocol should support finding and identifying other IDS components

Discussion on this item was limited. Comments from the floor all tended to agree.

The only significant concern was that that they agree with removing the wording "finding" but Identifying is a key requirement. As a result the Requirement should remain but read:

The protocol should support identifying other IDS components.

Requirements on the configuration of IDS

There was a mixed discussion on this thing about configuration.

At our first meeting it was determined this was out of scope. In the final analysis configuration remains out of scope for now.

***Entered a side discussion on protocol Vs requirements****

NEW IDEA: Ability to include Configuration data with alarms that is relevant to alarms. Consensus on this as a requirement

NEW IDEA: Semantics of fields need to be standardized Consensus without any discussion

NEW IDEA: Ability to get/set Configuration Data Consensus on postponing this for a latter date

NEW IDEA: Alert format contains a reference (pointer) for additional data related to a specific alert that may or may not have been processed. Consensus to include this requirement

NEW IDEA: Additional fields: time available, space required, manner of access?

NEW IDEA: Group communications must be supported

NEW IDEA: Should document address forwarding?

ITEMS NEEDING MORE DETAIL:

Specifics on the security of communications channel.
22. Authentication
23. Process with vendor, author, specific instance
24. Confidentiality
25. Best practices
26. Non-repudiation
27. Integrity
28. No Denial of Service
29. No malicious duplication (replay)

When it became obvious that these topics, as they currently stand would take up a great deal of time in debates, Mark decided to take this as an action item to flesh-out the above requirements to define their meaning.

Required level of detail/raw data available to manager
+++Did not get around to discussing this item+++

Requirements on process of defining and standardizing new events/extensibility
30. Must be Extensible - this concept of extendibility is a two edged sword and each is equally important to vendors and users.
31. Customers/vendors changing their products (add signatures)
32. Extensibility of the standard itself (ability to add new data fields and/or alert types as new attacks or methods are developed).

The specific fields in the message
+++ Did not get around to discussing this item+++

SCHEDULE ISSUES

Milestones
33. Internet Draft for Requirements
34. We have missed this milestone already. The question is do we change our milestones or double our efforts and push on to achieve current milestones on time. Consensus of the group was to keep on track and deliver milestones on current schedule.
35. Internet draft of design documents

Interim Meeting
Would like to have an interim meeting. Discussion about this topic favored an interim meeting sometime in the month of May. AFIWC volunteered to host the two-day working group at their CSC Contractor site in San Antonio TX. Harvey Mudd University also volunteered to host. A count of people interested in attending such a meeting looked to be about 10 to 15 people.

The purpose and objective of this group is still to be determined but publication of an Internet Draft requirements document is primary goal. It is a fact that there is a lot of work that needs to be done prior to the summer IETF meeting in Oslo.

It was determined that an interim meeting was necessary - location TBD.

Date to be determined but look to be the second week of May.

This meeting was closed at 1130. Next meeting is tomorrow morning at 1300.

IETF IDWG
Session II
1300-1400 16 March 1999
(Attendance 30)

AGENDA:

36. Summary of mailing List
37. Discussion of alert data content
38. Expression alternatives for alerts? XML, SNMP, ASN.1

SUMMARY OF MAILING LIST

Stuart Staniford-Chen (co-chair) briefly summarized the issues discussed on the mailing list.

DISCUSSION OF ALERT DATA CONTENT

Open to floor discussion opened on data content for alerts.

A few common fields and then attack specific fields.

39. Time
40. Host Name of originating device
41. Event/attack type
42. Source
43. Destination
44. Idea of Specialization (layering of fields)
45. Classes of attacks

What has the CIDF group done? Brian Witten addressed this issue.

Brian Tung presented a brief talk on CISL

(Delete
(Initiator
(UserName ?joe?)
(UserID 12345)
)
(FileSource
(FullNamePath ?/ect/passwd)
)
(Location
(time ?1999 Mar 11 ?)
)
)

In English this reads that a user name ?joe? with UserId ?12345? has deleted a file named ?ect/passwd? on 11 March 1999.

Stuart talked about difficulties with CISL. Too flexible. People can write CISL compliant s-expressions about the same event and it will look and read different. IETF standard need to be much more rigid.

The need is to get the vendors to offer up a list of fields they currently use in determining attacks, and to get that information posted on the mailing lists? Stuart and Mike will take this as an action item.

EXPRESSION ALTERNATIVES FOR ALERTS? XML, SNMP, ASN.1

Mike asked the group if there was someone who knew a lot about XML. The curiosity arises form comments on the mailing list and other communities where XML is being proposed as the solution to all man's problems.

Would it work for the data model here in our application?

XML allows for a more robust rapid response capability to new attacks. XML allows authors to define Data Type Definitions (DTD) and publish them to the web. This is a plus with the pace of evolution we have and will continue to sustain. On the other hand SNMP has a history of being slow to respond to the pace of technology. The revision process is lengthy.

Using XML, DTDs can quickly be developed and posted on a website for a given period of time. Then, once the "best-in-breed" DTD is determined for a specific attack it can be ported into the IDS and removed from the web.

From a management station view, a whole new set of transport methods are needed--You can use the same tools but transport is different.

SNMP across a firewall seems a major hurdle. For an ISP view, we get a lot of calls from customers just because they see SNMP traffic across the network.

Three issues to concern and take up on the mailing list.
Data Model, Transport, building tools

INTERIM MEETING

HP will host the meeting in their CA Facility. Details to follow.

Slides

None received.