NOTE: This charter is a snapshot of the 43rd IETF Meeting in Orlando, Florida. It may now be out-of-date. Last Modified: 25-Nov-98
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
[Notes taken by Dave Donahoo - ddonahoo@csc.com]
7:30pm--Stuart Staniford-Chen opened the meeting with an introduction of himself and Mike Erlinger, as the co-chairs of the Intrusion detection Exchange Format Working Group (IDWG). Following his brief comments he presented the following as the agenda for tonight's and Tuesday morning's meetings:
Monday evening (12/7/98), 7.30pm - 10pm
7.30 - 7.40--Introduction from chairs
7.40 - 7.55--Kevin Ziese, Cisco view of requirements for IDWG
7.55 - 8.10--Mark Woods, ISS view of requirements for IDWG
8.10 - 8.25--Drew Williams, Axent view of requirements for IDWG
8.25 - 8.40--Rod Greeley, Network Associates view of requirements for IDWG
8.40 - 8.55--Maureen Stillman, Lessons from CIDF for IDWG scope
8.55 - 9.05--Polly Siegel, Hewlett Packard view on requirements
9.05 - 9.15--Steve Lynchard, Air Force Information Warfare Center viewpoint.
9.15 - 9.40--Open discussion on scope - comments from floor.
9.40 - 10:00--Chairs attempt to gain rough consensus on rough scope of IDWG
(at least on what to start with).
Tuesday morning (12/8/98) 9am - 10am
9:00 - 9.20--Review scope discussion from previous day/ gain consensus
9.20 - 9.30--Identify requirements draft editors/authors
9.30 - 9.45--Review charter
9.45 - 10:00--Should we have an interim meeting?
In concluding his opening remarks Stuart reminded the group that what we were looking to achieve this evening was a rough consensus (or at least a starting point) on the scope of the IDWG. The speakers lined up for this night are here to discuss requirements and expectations of the IDWG.
As Kevin Ziese form Cisco was not available at this time, Stuart introduced Mark Woods from ISS.
7:35-- Mark Woods presented a briefing (see attached slides) on ISS's approach to intrusion detection. This approach starts with collecting customer thoughts and needs. This collection must come from multiple customers to help define a requirements statement. For example one customer requirement is to manage multiple sensors from a central management control panel.
ISS also recommends starting something like with real-time alarms and defining: Common meaning, Message formats, and Design goals. ISS recommended that design goals should; be Easy, make use of Existing Technology, and be Extendable by vendor and customer
7:40-- Drew Williams presented a short briefing of what Axent expects. They agree with ISS in that one approach is to collect customer comments. What is most important is that the IDWG looks for what is the scope of what our customers want us to do.
7:43-- Chris Burns-Centax spoke next. Standardizing signatures can be done at the frame level but host base cannot be done. The suggestion to communicate intrusion detection data can be done.
7:45-- Rod Greely presented Network Associates views of the working group. As to the scope of the problem he spoke of how common signatures and common alert format are two things but much more can result for better information exchange. (For example: Discovery information where the systems find out who and what is out there. Commands--The Cider project had interesting need for systems to communicate. Tracing ability; blocking; automatic help desk tickets; queries.) Finally there is a need for common alert formats.
7:50-- Maureen Stillman-CIDF representative. (See Attached Slides) Common Intrusion Detection (CIDF) working group started in Jan 97. CIDF currently has over 60 active members. CIDF's original charted was to facilitate the exchange of intrusion detection data across various components-interoperatability of components. Over the last year CIDF has developed a framework document, API's, and a Common Intrusion Specification Language (CISL). CIDF uses General Intrusion Detection Objects (GIDOs) to capture information on events, analysis, response and queries. CIDF also has developed a dictionary of over 200 SIDs.
As for lessons learned to be applied to the IDWG CIDF recommended that the requirements should include flexible information base, Interoperability of various components, Robust and scalable Infrastructure, and Survivability. Language attributes must be simple and unique and contain: Flexible policies to allow the system to adapt to situations and Throttle detectors to enable it to tell the system to throttle back so as not to flood you system with intrusion detection overhead data.
8:00-- Jim Rice-HP (See Attached Slides). HP sees great application of an intrusion detection standard in their Openview Security Management Products. As seen by HP the Intrusion Detection world is comprised of sensors and management stations-HP wants to be in the Management Stations side of the business. HP also see an opportunity to introduce Data warehousing in their management stations to support forensics.
As to the requirements for the IETF IDWG, HP envisions the focus on event representation and exchange formats as a major need. The work already done by the CIDF may be a good starting point. Another need is to ensure consistency of attack identifiers and other parameters. Finally, it is essential the capitalize on previous works of the IETF.
8:05-- Captain Steve Lynchard of the AFIWC was our final briefer for the evening (slides available). In his briefing, Capt. Lynchard solidified the AFIWC as one of the (if not the) largest scale consumer of intrusion detection systems. Currently monitoring over 130 sensors around the globe, AFIWC detects on the average of 130 million suspicious events each month. Of these AFIWC has recorded 352 confirmed incidents thus far this year. Records indicate that the number of events against AF systems is directly attributable to the nature of the press and world actions. AFIWC expects between 3 to 6 billion suspicious events each year.
AFIWC requirements and expectations of the IETF are Interoperability between sensors and directors, Common data formats, Ability to share attack signatures, Provide Real-time detection across multiple sensors, and automatic control of sensors. In addition to those things previous speakers outlined, the AFIWC would like to see the IDWG deliver standard Intrusion Detection data elements and minimum security requirements
8:25-- At this time Stuart Staniford-Chen opened the meeting up to comments from the floor. The following is a summation of those comments:
There is a big need to look at the business process of intrusion systems. System Managers must work with this. The standard must be compatible with existing network management systems. See framework definition and not limit it to a central processor
Do not work without coordination with open group specification which has a set of API. Good to use as a point of reference.
Thus far the discussion has been Internet based-a big problem is being able to track from where you are being attacked. Add option of automated tracking back through the chain.
We need to address the ability of intrusion event tracing in real-time.
Current Intrusion Detection is a limited viewpoint. We could be looking at many things for example to look at other things like physical security sensors as well.
One thing that is required is the ability to gather collection of events and determine relationships between events. We need standard data format and protocols.
On very interesting option would be for attack source tracing. DARPA research is currently performing research in this area and information can be obtained from website www.shang.csc.ncsu.edu/deciduous.
Nee to take a good look at the protocol used to exchange the data. SNMP-is it the right protocol?. A big problem is how the protocol reacts through firewalls. For obvious reasons, most people do not want to allow SNMP access to their firewalls.
8:35-- Comments from the floor concluded and Mike Erlinger provided a quick listing of the things we heard from both the briefings and floor comments. These Include:
- Alert Format
- Attack Signatures
- Communication Protocol
- Response Stuff-Real Time
- Integration with Network Management
- Firewall
- Semi-automatic Tracing
- Database format
- Control of Components
- Security
- Flexibility Architecture
- Distributed
- Hierarchical
- Reuse of existing standards
- Relationships with other working groups
- Customer Driven
It is key that we get a good idea of the customer requirements. Approx. 40 percent of this group are vendors and about 20 percent users.
Mike then gave a brief summary of the Charter Outputs: Requirements Document, Framework Document, and a Language Document. The timeline for those are as follows:
April 99 Requirements Document Draft
Aug 99 Framework & Language documents Drafts
Aug 99 Requirements Document as RFC
Dec 99 Framework & Language documents as RFCs.
At this point Stuart started the process of working on consensus of the items above which Mike had outlined. The purpose of this exercise was to come to some agreement on the scope of the IDWG.
Alert Format-approved with no addition discussion.
Attack Signatures-Disapproved; however we will include static name (attack Signatures) in the Alert Format.
Communications Protocol-approved: The process should be to determine requirements first then identify existing protocols, finally develop new protocols only if required.
Response Stuff (real-time)-disapproved while this is a needed capability for intrusion detection systems it appears outside the scope of this working group.
Control of Components-approved but postponed: While this is within the scope of the WG, it will not be attempted initially
Semi-Automatic Tracing-Disapproved. This item resulted in a great deal of discussion. The bottom-line in the disapproval was that it was outside the scope of the IDWG. The level of interest in this group, however, suggests it may be a topic for a BOF at a future date.
DB Format-Disapproved (without any significant discussion.)
Following this discussion Stuart summed up the determinations that Alert Format and Communications Protocol were the only two products which met the scope of this working group. Others, specifically semi-automatic tracing and attack signatures may be taken up under a separate effort.
In closing, Stuart reminded the participants of the follow-on meeting scheduled for 9:00am Tuesday.
Tuesday 8 December, 1998
9:00am Stuart introduced Kevin Ziese from Cisco (See Attached Slides) to present his Cisco's concerns and expectations of the IDWG.
Concerns: Cisco believes in and supports intrusion detection standardization. Cisco does not want a standard that forces vendors to rebuild existing Intrusion Detection Systems. Cisco believes IDSs should be network, Host, and applications based. Cisco has worked with and supports framework and language simular to that developed under CIDF.
Expectations: Cisco would like to see two RFCs. One for intrusion detection and an ther for vulnerability assessment.
0905-- Following Cisco's presentation Mike opened the meeting with comments to summarize events of last night's meeting. The scope was pretty much decided during the previous meeting. In addition Mike put up the charter for a quick refreshment. Our focus at this point is on the requirements document where we are looking to April 1999 to submit draft.
Concern: At this point a significant concern was raised from the floor. The last sentence in first paragraph suggest that this group will do semi-auto tracking. We excluded this in last nights meeting with the suggestion of a BOF for those concerned. The concern is that if a BOF is suggested it would be excluded as something IDWG should be doing. Recommendation: We will note and address this if it becomes an issue.
Mike now turned the discussion to the Alert Format Requirement. He conducted a brainstorming session which yielded the following candidates as high-level requirements:
- Format must be machine readable
- Source of Attack/alert/Target
- IP Address
- Mac Address
- User Name
- Hardware
- OS
- Port
- Timestamp
- Particular Sensor
- Target of Attack
- Security of message/protocol
- Non reputable
- Identity of Context of Attack
- Comment field on attack relation
- Context-Observation and Implications
- Requirement fix-One-way or two-way conversation
- Format should support intelligent or non intelligent sensors
- Complex series of events
- Streamline format to reduce traffic.
- Allow selective info in messages
- Status of attack
- Identify probabilities of attack
None received.