NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-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@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:
No Request For Comments
INTRUSION DETECTION EXCHANGE FORMAT (IDEF)
Working Group Meeting Minutes, 46th IETF
Recorded By David Donahoo
The IDWG working group met at 3:30 pm on Thursday and at 9:00 am on Friday at the 46th IETF meeting in Washington DC. Both co-chairs (Stuart Staniford-Chen and Mike Erlinger were present, and Dave Donahoo took the minutes. Over the two sessions there were about 85 attendees.
This was an aggressive agenda with presentations as follows:
- IDEF Data Model-Herve Debar
- Correlation MIB-Felix Wu
- SNMP Intrusion Detection MIB-Glenn Mansfield
- XML Intrusion Detection Implementation-Dave Curry
- Secure Transport Implementation-Dipankar Gupta
The group came to consensus on the Transport implementation and asked Dipankar to prepare an official Internet Draft under the IDEF banner.
The group further decided to have an interim meeting in early February (location to be determine). The purpose of this meeting is to focus on finalizing the data model and continue the SNMP vs XML implementations discussions.
Herve Debar and Dave Donahoo were tasked to lead a team (Felix Wu, Glenn Mansfield, Mark Wood, and Fengmin Gong) to further develop the data model. A main thrust will be to develop an Entity Relationship model to further explain/clarify the existing data model.
Glenn Mansfield and David Curry were tasked to develop a SNMP/XML document which will compare and contrast the two implementations. The IDWG is looking for a document to prompt the discussions on the pros and cons of each system. The intent is to enable the group to come to consensus on which implementation to support.
Session 1, 11 Nov 99, 3:30 PM (Attendance: 60)
Mike Erlinger opened this session by introducing the Agenda and running through an agenda bashing session.
AGENDA:
Thursday:
- Status and Agenda Bashing-Mike Erlinger
- Data Model-Herve Debar
- Correlation MIB-Felix Wu
- SNMP MIB for IDS-Glenn Mansfield Friday:
- XML Implementation of IDS-Dave Curry
- XML vs SNMP discussion-Chairs
- IDS Secure Transport-Dipankar Gupta
- What's Next-Chairs
Status: Mike briefed on the status of IDWG . Mark Wood has completed his work on the requirements document. We held the last call on the mailing list and have forwarded it to the IETF as an Informational RFC from this working group.
Since our Interim Meeting in Sept we have numerous documents on the table for discussion. Since we now have more than one implementation proposal we will have to come to some consensus on which way the group decides to go. We will get into this discussion on Friday during the "What's Next" discussion.
Herve Debar presented his data model and class hierarchy. For the full version of the draft look at <http://www.ietf.org/internet-drafts/draft-ietf-idwg-data-model-00.txt>. There was a good deal of valid discussions on his model. While we gained consensus on various portions of the model (i.e. eliminating the distinctions between "multi-host and single-host and making it a list or range of hosts), the greatest point of departure was the tree type representation of the class hierarchy. While the tree structure does a good job of identifying the parent child relationships among data elements it does little into identifying the relationships between data elements.
The group decided to form a sub-group to determine the best way to represent this data. An Entity Relationship Diagram was discussed as a possible solution. The group met informally following the Friday meeting to discuss the next steps and will work together over the next three weeks and publish the results to the list for discussion on or about the 15th of Dec. Group members include: Dave Donahoo, Herve Debar, Glenn Mansfield, Felix Wu, Fengmin Gong and Mark Wood.
Felix Wu then briefed his draft for a Correlation MIB which focuses on requirements 5.2, 7.1, 7.4, and 7.17. The objective of his MIB is to provide a data model to support event abstraction, anomaly detection and extensibility. While this MIB provided some very interesting applications of a possible IDS standard the group looked at it as being a little outside the scope of this working group. It appears to address implementation of IDS and not just the Data Exchange (which is the group focus). There was no consensus or significant comments to this draft. The following are highlights from his briefing points (Full Briefing slides available upon request):
Intrusion Detection System Event Correlation MIB
Objectives: A Data Model to support...
- Event Abstraction/Aggregation/Relations performance, reference,...
- Anomaly Detection Events
- Extensibility new types of information and implementer-specific information/relations
Focus on Information standard, not Analysis or Operation standards. Instead we want to make sure that the information model itself is sufficient and general enough to facilitate different analysis models.
Information versus Analysis. IDWG focuses on Data/Information Model standardization. In the Orlando/IETF meeting, we have decided NOT to worry about the standardization" of the analysis model at least at the first stage.
Proposed to IDWG: to develop the information correlation and aggregation data model document (either as part of the data model document or a separated one.) The first draft will probably be in UML.
Glenn Mansfield then began his presentation of his IDS SNMP MIB. He got about half way through before time expired and then he agreed to finish his presentation on the following morning session. For a full text version of this draft is posted on the mailing list. The following are highlights from his briefing points (Full Briefing slides available upon request):
Intrusion Detection Message MIB
ID Model Requirements
- Simplicity, Ease of usage
- Reliability, Security, Authenticity
- Flexibility, heterogeneous.
SNMP
- GET/SET/Inform Something "Something" is defined in MIBs
- MIBs define the syntax and Semantics of the "Somethings" - Managed Objects
- Very flexible and Extensible--define new MIBs
SNMP (v3)
- Already there Network Management Security Management
- NMS and IDS - both monitor the network and watch for events
- Reliable, Secure, Authentic
- One of the candidate transports
SNMP (v3) Constraints
- Generally UDP
- Messages should be small (484 bytes is guaranteed)
- Minimum Information who did what to whom, when
Session 2, 12 Nov 99, 9:00 AM (Attendance: 50)
Glenn Mansfield concluded his presentation on the IDS SNMP MIB.
Dave Curry Presented his XML Implementation IDEF Message Format. For a full version of this draft look at the mailing list. The following are highlights from his briefing points (Full Briefing slides available upon request):
The stated purpose of the message format is...
- To facilitate the exchange of alert data between intrusion detection and response systems and the management systems they interact with
But there are so many other possibilities...
- Alert/ event databases that can store data and perform data analysis and reporting on the "whole picture," obtained from several different IDSs.
- Event correlation systems that can perform cross-correlation and cross-confirmation calculations on data from multiple sources (e. g., use a host-based system to confirm a network- based alert).
- Graphical user interfaces that enable the user or administrator to monitor and respond to alerts from all deployed IDSs, via a single console.
- Reporting tools that can generate all those tables and charts and graphs that the pointy- haired managers seem to like so much data exchange format to enable users, vendors, response teams, and law enforcement to exchange data and communicate about it.
XML is the Extensible Markup Language
- Standard defined in Feb. 1998 by the World Wide Web Consortium (W3C)
- Based on Standard Generalized Markup Language (SGML), ISO 8879
- Gaining widespread acceptance as a language for representing and exchanging documents and data on the Internet
XML is a meta- language
- A language for defining other languages -- each application defines its own application- specific markup
- Can be processed (parsed, filtered, searched, displayed, etc.) by "standard" tools rather than custom code
- Uses tags (e. g,,<paragraph>) and attributes (e. g., type="bulleted") to mark units of semantic content
XML allows a custom language just for intrusion detection
- No kludges resulting from putting square pegs in round holes.
- Language can be as general or specific as necessary.
Lots and lots of processing tools already available
- Commercial, plus plenty of public domain/ open source.
- Java, C, C++, Tcl, Perl, Python, GNU Emacs Lisp...
- IBM, Microsoft, Netscape and others supporting it.
Full internationalization and localization support
- UTF- 8 and UTF- 16 encodings of ISO 10646/ Unicode.
- Language can be specified on a per- element basis
Easy filtering, aggregation, rearranging, conversion
No license, no license fees, no royalties
A few thoughts on XML -vs- SNMP
- Our experience has been that network management systems make lousy intrusion detection consoles
- They're just too slow -- a couple of "serious" ISS scans and you may as well go get a cup of coffee while they update themselves
- Drill-down into alarms (the way they're usually designed) is way too slow
- The urgency of "smurf attack" just ain't the same as "disk space low"
XML is just text - it can be sent over "any" TCP protocol
The SNMP protocol (not the data format) has a "bad rep" "You want to send what through my firewall? Get out of my office!"
Following Dave Curry's presentation Stuart lead a discussion over SNMP vs XML. Stuart stated that what we need to do as a group is to discuss and try to resolve if we want to: choose either an XML solution or an SNMP solution, choose to work both, delay the decision, or turn it over to the Security Area Chairs to decide which we should choose.
Comments from the floor:
One thought is to keep both alive and align the efforts.
Speed may become a factor. SNMP is a faster mechanism than XML.
There are analyzers in place already using SNMP MIBs. This would make for an easier transition.
It doesn't make sense to pick both. That would give us two standards-this just doesn't make sense.
At this time IDS products do not have any XML implementations. All do use SNMP traps to capture data.
¬ From a vendor of consoles we are already supporting both and this is not a problem. It makes a lot of sense to support both.
¬ From a developer's view supporting both is easy, but developing a dual standard is not as easy. I support XML over SNMP.
SNMP is more portable. SNMP traps are not the issue-transport is. We could support the SNMP traps and design the transport later.
Speaking as a vendor of IDS, there are many things I need to think about. Network system management tools make very poor IDS's (but customer's use them). If I go to a customer and ask them to open up the SNMP port they'd throw me out. If, on the other hand, they are ready used it they tend to love it.
Speaking from the DoD side, our Security Policy forbids opening SNMP ports.
Efficiency is another issue. XML looks good but what is the cost in overhead bits?
I don't think the data model is strong enough for us to make a decision.
At this point Stuart stopped the discussion to bring the issue to a vote. He asked:
How many people think we need to select one of these to develop into the standard. Show of hand showed consensus the group feels strongly that we need a single standard.
A second vote showed that as a group we do not have enough information to make that decision. Glenn Mansfield and Dave Curry were tasked by the group to develop a document comparing and contrasting XML and SNMP.
End Of Floor Comments.
Dipankar Grupta then presented his transport protocol. For full text draft read document at <http://www.ietf.org/internet-drafts/draft-gupta-idwg-iap-00.txt>. The following are highlights from his briefing points (Full Briefing slides available upon request):
Problem Overview
- IDWG requirements:
o What information is contained in alerts?
o How is it represented?
o Transport: how is this information moved between IDEF entities?
Transport proposal: intrusion alert protocol (iap)
Intrusion Alert Protocol Highlights
- Application layer protocol influenced by HTTP/1.1
o Simple and provides application layer reliability
- Uses TCP/IP as the transport
o Scalable, reliable, connection oriented
o Works well with wide variety of IP networks
o More heavyweight than raw UDP-based wire protocols such as SNMP/UDP.
- Uses Internet Media Types (MIME) to encode alerts
o Independent of actual alert representation Can cope with XML, BER encoded ASN.1...
- Uses TLS to provide transport layer security
o Widely deployed public key security scheme
o Mandatory mutual authentication
o Allows reuse of key management
o More heavyweight than SNMPv3 security
Deployment Considerations
- Can be deployed with either sensor/analyzer or console initiating the TCP session.
- Protocol can be proxied to tunnel data across security perimeters.
- Suggest IANA allocates a designated port for IDEF traffic.
Four phases of IAP
- Connection setup:
o in the clear
o allows protocol to be proxied
- Security upgrade:
o secures the transport using TLS
o follows recommendation to use the Upgrade keyword to not require a new port if TLS/1.0 is replaced with something else.
- Rest of protocol is run atop TLS record layer.
- Version support verification:
o Thwarts protocol downgrade attacks
- Alert transfer:
o alerts are acknowledged at the application layer synchronously
None received.