Current Meeting Report
2.5.12 Extended Incident Handling (inch) Bof
Current Meeting Report
INCH BoF Minutes
0900-1130, Thursday, March 21. 2002
IETF 53, Minneapolis, MN
Roman Danyliw <email@example.com> [RD]
Jan Meijer <firstname.lastname@example.org> [JM]
1. Agenda bashing and introductions (5 min)
1. Agenda Bashing, Introduction, Minutes Taker - Danyliw -- 5 min.
2. INCH Status Report and News - Danyliw -- 5 min.
3. Terena IODEF Working Group Status Report - Meijer - 15 min
4. DMTF Common Support Schema - Rafalowi - 20 min
5. Discuss requirement document (mailing list, RFC 3067, new requirements) - 30 min
6. Discuss data model document (mailing list, IODEF, high-level data elements) - 45 min
7. Discussions and Plans for the Future - 15 min
No additions or motions against the agenda were made.
2. INCH Status Report and News
Roman Danyliw reviewed the goals of the INCH BoF and actions taken since the previous BoF. (scribe note: the minutes of the previous BoF can be found at
The expressed goal of this second BoF was to decide on the details of the INCH deliverables.
Several items of INCH related news were mentioned:
* Yuri Demchenko of Terena unfortunately had to withdraw as co-chair
* The Terena IODEF-WG had disbanded
* The W3C had finished work on an XML signing standard
3. Terena IODEF WG status report
Jan Meijer presented on the activities of Terena's IODEF-WG. The IODEF-WG as an organizational construct no longer exists. Development of the IODEF data-model within the IODEF-WG has been halted because it was hoped that further development of the IODEF data-model would be undertaken within the IETF. The IODEF-WG considered that developing the same datamodel in two bodies at the same time would be rather in-efficient.
Nevertheless, the remaining deliverables (users guide, management guide) agreed on in this WG will still be completed in May. Furthermore, a pilot project using the IODEF has been started with results also expected next May.
4. DMTF common support schema, Lee Rafalowi [LR]
Lee Rafalow of IBM held a presentation about the work of the Support WG of the DTMF (Distributed Management Task Force, http://www.dmtf.org). The DTMF is a not-for-profit industry organization that establishes industry standards for the management of computer systems, networks and the Internet. Members include Microsoft, Intel, Symantec, BMC, and IBM. The Support WG is responsible for the common Support schema, and uses the DMTF's CIM (common information model) model for defining classes related to service incidents and knowledge. The CIM standards are implemented by a wide variety of vendors, amongst which are Microsoft, Sun, Pegasus (open source), IBM, HP. CIM is a meta-schema, not pure XML.
[LR] expressed a vision of a more consolidated help desk and incident response operations. Such a vision implies a clear case for using the same tools and standards. The INCH should decide between an architectural description strategy (like CIM), in which case having a close look at CIM could be very useful, or a less-inclusive, incremental development process.
Q: Is there workflow-support in the common Support schema? [RD]
A: Sharing data between administrative domains is done using a SOAP like flow. [LR]
Q: Is there a pointer to this workflow-support? [JM]
A: Will be sent to the list [LR]
Q: What are the facilities for sharing data across administrative domains in DMTF? [RD] A: Administrative domains can be defined as organizational or administrative boundaries, but CIM does not provide any security properties in band. [LR]
Q: Is there a specified transport protocol? [RD]
A: Yes, XML over HTTP. [LR]
* JM does not see help desk and incident response operations growing closer together to enable them to use the same tools and standards all together. There are many differences between them, not the least of which is that they have different information requirements, especially in CSIRT-to-CSIRT communication.
5. Discuss requirement document (RFC 3067, new requirements) - 30 min
[RD] noted the related work of the informational RFC3067 to the requirements document specification. The WG examine RFC3067 and reject it or make it the first-draft of the WG requirements specification.
* Patrick Cain suggested that rather than creating a separate requirements document, a chapter in the INCH data model deliverable could be dedicated to explaining the various changes and the rational behind them.
* Patrick Cain pointed out that since the IDMEF is an I-D, referring to it in RFC3067 and in the IODEF data model specification is not possible.
* Patrick Cain commented about the time representation. "Everyone" uses UTC rather then time zone information, but RFC3067 specifies time as local. There was consensus that the INCH data model should also use UTC.
* Michael St. Johns commented that the INCH WG timeline of two years was rather long given the substantial work that can be incorporated.
* There was discussion regarding the use of the term 'evidence' and what this could mean. Would this mean that there is to be support for legally recognized chain of custody? If so, are there any experts on maintaining a chain of custody involved in the development?
[RD] commented that in the future the data model could be used for chain of custody, but this would probably occur as a custom extension. Supporting a legally recognized chain of custody would pose many problems, as there are different legal standards and rules around the globe. The original notion of 'evidence' was to provide a way to represent data in support of the incident report (i.e., the raw incident data such as log files).
The consensus was to avoid the term 'evidence' due to its loaded meaning and choose a different identifier such as 'supportive'.
A call for consensus on using RFC3067 as the first draft of the requirements document was issued. There was no humming against using RFC3067 for the requirements document, there was sufficient humming in favor.
RFC3067 will be used as the basis of the requirements document, but serious updating is needed. Glenn Keeni volunteered to be document editor of the requirements specification.
6. Discuss data model document (IODEF, high-level data elements) - 45 min
[RD] presented a summary of the mailing list comments on the data mode:
* Areas to potentially explore include: representing analysis results, various "evidence"/support incident data, and vulnerability reports; data sanitization;
* IODEF specific issues:
* What degree of IDMEF compatibility should be supported?
* What kind of self-documentation is required in-band (History class)?
* The granularity of setting restrictions on data usage
* What constructs should be provided to support document updates?
* The meaning of the impact, confidence, and purpose of an incident
* Randy Presuhm commented that discussing the data model before the requirements are done is premature. [RD] and Michael St. Johns noted that while such a strategy is typically premature, the sheer volume of previous work makes parallel development possible and practical.
* Michael St. Johns stated that the INCH development is going to trigger discussion within the IAB on using XML for defining data-formats.
A show of hands was called for in order to determine consensus on reusing the IODEF data model document as a starting point for the INCH data model and for doing this development in parallel with developing the requirements document.
Consensus was reached, as there were no hands against this proposal, and many hands in favor.
[JM] volunteers as a document-editor for the data model specification document.
-- IODEF Comments
* Glenn Keeni commented that the IODEF and IDMEF should be disjoint. IDMEF deals with packet-level data and this (IODEF) addresses a more high-level problem.
It was also commented that IDMEF is more of a specific subclass of IODEF
* The difficulty of internationalization was raised. The goal of the IODEF is readability, but how is that going to be achieved? The WG was generally in favor of internationalization, where possible. The solution discussed was to review the data model document and identify the data elements that require internationalization and which must remain standard.
Q: What is the relationship between the IODEF and security advisories? What format would be used to exchange security advisories? A: IODEF messages and security advisories are not the same thing. At most, an advisory can be linked to from an IODEF object.
Q: Are there constructs present in the IODEF model to represent the status of an incident, e.g. 'new', 'passed on', 'to legal' etc.? A: There are currently two ways to represent status: using the history class and the purpose attribute. However, this is not as easy as it should be. The meeting concluded more discussion on the subject of status-representation is needed.
It was added that webdav could be used to address some of these lifetime and update questions.
* SIP was suggested as a way to transport IODEF, but transport issues remain outside the scope of the INCH.
* The Impact and Confidence class have issues that were raised on the mailing list. It was concluded that for a proper definition of "confidence" in the data model agreement on the meaning of "confidence" was required. The notion of "confidence" generated substantial discussion in the IDWG.
7. Discussions and plans for the future
It was decided from this meeting to take the following actions:
* Update the charter to reflect a shortened timeline for completing the deliverables (by December 2002) and clearly label the data model specification as standards track and the requirements document as informational.
* Re-use RFC3067 and Terena's IODEF-05 data model as draft-00 of the requirements and data model specification. Active work on these drafts must begin.