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
Purpose of Group
Summary of Last Meeting
90 Min Requirements
Early List
Comments/Discussion
Schedule Issues
Milestones
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):
Sample attacks used
Attack data content
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
--Eliminate those that are "out of scope"
--Add detail required
--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?
+++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.
--Authentication
---Process with vendor, author, specific instance
--Confidentiality
---Best practices
--Non-repudiation
--Integrity
--No Denial of Service
--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
--Must be Extensible - this concept of extendibility is a
two edged sword and each is equally important to vendors
and users.
---Customers/vendors changing their products (add
signatures)
---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
--Internet Draft for Requirements
---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.
--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:
Summary of mailing List
Discussion of alert data content
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.
Time
Host Name of originating device
Event/attack type
Source
Destination
Idea of Specialization (layering of fields)
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.