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
Michael Erlinger <email@example.com>
Stuart Staniford-Chen <firstname.lastname@example.org>
Security Area Director(s):
Jeffrey Schiller <email@example.com>
Marcus Leech <firstname.lastname@example.org>
Security Area Advisor:
Jeffrey Schiller <email@example.com>
To Subscribe: firstname.lastname@example.org
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:
Submit Requirements document as an Internet-Draft
Submit Framework and Language documents as Internet-Drafts
Submit Requirements document to IESG for consideration as an RFC.
Submit Framework and Language documents to IESG for consideration as RFCs.
No Current Internet-Drafts
No Request For Comments
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.
0930-1130 15 March 1999
5 Min Agenda Bashing
10 Min Intro
9. Purpose of Group
10. Summary of Last Meeting
90 Min Requirements
11. Early List
14. Interim Meeting
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.
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
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.
23. Process with vendor, author, specific instance
25. Best practices
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+++
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
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.
1300-1400 16 March 1999
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.
40. Host Name of originating device
41. Event/attack type
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
(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
HP will host the meeting in their CA Facility. Details to follow.