[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