NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 11-Oct-00
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@nortelnetworks.com>
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. |
Internet-Drafts:
· Intrusion Detection Exchange Format Data Model
· Intrusion Detection Message Exchange Format Comparison of SMI and XML Implementations
No Request For Comments
INTRUSION DETECTION EXCHANGE FORMAT (IDEF) Working Group Meeting
Minutes, 49th IETF
The IDWG met at 0900 on both Thursday and Friday of the 49th IETF meeting in San Diego CA.
First meeting - 14 December 2000
The first presentation was on the Intrusion Alert Protocol (IAP). It was presented by Roy Pollock, using slides prepared by Dipankar Gupta. Some changes have been made to the protocol, partly to align it more closely with HTTP1.1. The changes include:
1. Changed content-type to "application/xml" (from application/x-idef-alert).
2. The initiator of the TCP connection must now also initiate the TLS handshake
3. A RESPONSE message may now contain a body
4. A Host: header has been added, to support a virtual hostname.
The following issues were identified:
1. The IDWG's relationship with the work being done by the SYSLOG WG needs to be determined.
2. Interoperability between implementations has not been tested.
3. A port number has not been requested from IANA.
4. IANA OID's for the desired key extensions are needed.
A new draft of the IAP document was sent to the mailing list, and will be properly submitted when possible.
Darren New made a presentation on BEEP, the Block Extensible Exchange Protocol. BEEP (née BXXP) provides a framework for an application protocol, and is being used by the SYSLOG WG, whose requirements are very similar to those of the IDWG. The draft BEEP document is currently in "last call" status. BEEP is asynchronous, bi-directional, and multi-channel. It uses SASL and TLS to establish a session's security properties. A profile defines the properties of a channel. Several interoperable implementations of the previous version of BEEP exist, in multiple languages including Python, PERL, Java, and Tcl; several of these will be updated to the current BEEP specification within the next couple of months. One issue mentioned was that TLS pass-through (a firewall) is not precisely specified, but this is not thought to be a problem.
The question of whether we should use BEEP, and if not why not, was raised. The group's consensus was that we should explore BEEP further, even though it will delay our moving ahead with IAP. Paul Osterwald, John White, and the Aerospace group from Harvey Mudd took on the task of examining BEEP prior to the next IWDG meeting.
Stuart Staniford presented some remaining Data Model and XML Representation issues.
Issue: It has been proposed that the fields of an IP packet be broken out, and also that some stream information be included for context. This is clearly just one example of many technical issues that could be dealt with by XML extension.
Action: David Curry will study the issue of XML extensibility in general. The need for packet breakout should be explored on the mailing list.
Issue: The revised <user> format is in the model, not yet in the XML.
Resolution: Use the revised format in both.
Issue: Addresses can be ambiguous in private address spaces. Propose to add optional VLAN number and VLAN name attributes to <address>, and "interface" to <source> and <target>.
Resolution: Make the change to both model and XML.
Issue: <Environment> and <Arguments> add unnecessary nesting and should be eliminated.
Resolution: OK
Issue: The "unknown" type in <AdditionalData> is meaningless and should be eliminated.
Resolution: OK
Issue: Time representation in the XML is verbose and somewhat inconsistent. It is proposed that we use the IEEE-8601 standard, change <ntpstamp> from an element to an attribute, eliminate <Time> and add <CreateTime>. There is also a question of whether to represent time periods (useful for aggregation), rather than just point times.
Resolution: Switch to the proposed format, using only point time for now. This is only an XML layout change, and does not affect the requirements or the data represented.
Issue: "Impact" is a poorly defined collection of sometimes orthogonal attributes. It is proposed that it be decomposed into severity, completion (optional), and type (optional).
Action: OK to decompose impact, leave the exact decomposition and number of levels to be explored on the mailing list.
Issue: It is proposed that summary counts be added to <Source> and <Target>, for use where the number of instances is excessive. There are probably other cases where a summary count would be useful also.
Action: Identify those items where this would be useful, discuss it on the mailing list. Also, look at the combination of network and network mask to see if it makes sense for aggregated elements.
Yuri Demchenko spoke on the subject of incident reports. These are human-oriented, long-lived, evidentiary reports of a much broader scope than those envisioned in the IDWG charter. The question is whether it makes sense to add this kind of reporting to our charter. They have a requirements draft for the Incident Object Description and Exchange Format, and intend to use an XML representation. The next step in their process is a meeting in January, in Barcelona, between a few European CSIRT's. It was agreed that there were many commonalities and many differences between incident reports and IDMEF messages; there was no consensus regarding any joint effort.
The meeting was then adjourned for the day.
Second meeting - 15 December 2000
Kevin Green spoke regarding the Vulnerability Detection Message. It has goals similar to those of the IDMEF, so the addition of the VDMEF is proposed as an alternative to establishing an independent WG. The VDMEF would require a new class of messages, but its elements would be very like the IDMEF's. Their goals are to prepare a requirements document, a model, and a DTD. It was noted that joining forces would appear to require some modification of the IDWG charter. The group consensus was that this should be pursued. It was observed that some restructure of the DTD would be appropriate; what about the data model? Also it was noted that the absence of a vulnerability is interesting, while the absence of an intrusion is generally not.
Action: Stuart and Mike talk to Jeff Schiller (IESG Security Area Director) about this.
Action: Dave Curry look at the IDMEF DTD to see how this might be handled.
Action: Kevin will start work independently of the IDWG for now.
The general comment was made that we need the ability to add extensibility, but getting version 1.0 out the door is important. We will not, for instance, wait for the specification of XML Schemas to be finished.
Action: Mike Slifcak will work on the Data Model draft, which needs editorial work.
The remaining presentations were all related to IDWG standard implementation experience.
Glenn Mansfield presented his work on the SMI representation of IDMEF messages. He has drafted a document which provides exact mappings between the XML and SMI representation; it contains 19 MIB tables and 70 Managed Objects. The mapping may be taken up as a possible RFC (experimental or best current practice, not as a standard). Glenn has also developed a lightweight MIB for a lightweight IDS, with just one table and 19 MO's. He also described (and demonstrated) an experimental implementation of the IDMEF.
Paul Sangree spoke on the issue of analyzer/manager time synchronization, in an environment of multiple devices and hops. Some devices may be synchronized, others not, and some simple proposals can make the problem worse. At least there need to be some caveats in our documents.
Jeff Flaxer spoke on Data Management of (large volumes of) Alerts. He is considering environments with thousands of alerts per second, sufficient to stress a DBMS. In this situation, hierarchy and aggregation of alerts become essential. Future work by the IDWG in this area is anticipated.
Stuart Staniford described the IDMEF plug-in for Snort. It uses the freely-available libidmef library, built with libxml. Snort is a content-based rules engine, which allows plug-ins for more advanced features (e.g., portscan detection, anomaly detection).
The Harvey Mudd Aerospace group (Tim Buchheim, Ben Feinstein, Greg Matthews, and Roy Pollock) described their IAP implementation. It is fairly complete, although it does not yet support TLS session resumption. Some issues they have identified included the need for a source header if going through a proxy, the uncertainty as to how the proxy next hop is defined, and the use of "port" in the CONNECT message. They are using the openssl library, and noted that it is at best ill-documented; they are willing to share their hard-earned knowledge of it.
The meeting was adjourned at about 1130.
None received.