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.