Current Meeting Report
Slides


2.5.9 Extended Incident Handling (inch) Bof

Current Meeting Report

Incident Handling (INCH) BoF minutes
IETF52 - Monday 13.00-15.00 December 10, 2001, Salt Lake City

CHAIRS:
Yuri Demchenko <demch@terena.nl>
Roman Danyliw <rdd@cert.org>

Scribe:
Jan Meijer <jan.meijer@surfnet.nl>

Agenda:

1. Agenda bashing and introductions (5 min)
2. Problem statement and the scope of work - RD (5 min)
3. Incident Handling workflow - JM (10 min)
4. Background: IODEF WG - JM (15 min)
5. Requirements for such a standard (including analysis of the current IODEF requirements) - RD (15 min)
6. IODEF Design principles (including relation to IDMEF) - YD (15 min)
7. Presentation of current IODEF Data Model and XML DTD document - RD (15 min)
8. Discussion: How to proceed and proposed Charter (30 min)
9. Conclusions (next steps, interest level, etc.) (10 min)

RD - Roman Danyliw
YD - Yuri Demchenko
JM - Jan Meijer

1. Agenda bashing and introductions (5 min)
--------------------------------------------------------------------

The agenda of the BoF and the presenters were introduced.
(http://www.terena.nl/tech/inch/inch-bof-ietf52.html)

No additions or motions against the agenda were made.

2. Problem statement and the scope of work - RD (5 min)
--------------------------------------------------------------------

The first presentation discussed the issues with handling security incidents across administrative domains. In particular, that resolving these incidents may require collaboration between CSIRTs and involved parties.

Slides:
http://www.terena.nl/tech/inch/docs/inch_bof_scope.ppt

3. Incident Handling workflow - JM (10 min)
--------------------------------------------------------------------

The second presentation outlined the steps usually taken by a CSIRT in the course of handling an incident. The details of workflow in a CSIRT and the implications of standardized data representations were discussed.

Slides:
http://www.terena.nl/tech/inch/docs/inch-bof.worfklow.ppt

Q: Is there a contractual relationship between a CSIRT and the remote organization involved in handling/investigating an incident?
A: Communication is the important issue when handling an incident. It often involves interaction between the CSIRT handling the incident and the CSIRT(s) of the other organization/network involved. Since attacks against your constituency can come from anywhere in the world, as well as launched against anyone else from your constituency, there is no predefined contractual relationship.

4. Background: IODEF WG - JM (15 min)
--------------------------------------------------------------------

The third presentation described the history behind the creation of the Incident Object Description Exchange Format (IODEF) and the current results of the IODEF WG in the TERENA TF-CSIRT working group.

Slides:
http://www.terena.nl/tech/inch/docs/inch-bof.background.iodefwg.ppt

Q: How does the IODEF standard differ from the IDMEF standard?
A: It is proposed to postpone this question to agenda item 6 where the relationship between IODEF and IDMEF will be discussed in detail.

Q: Why is this effort being undertaken in the IETF framework? It seems that network security is more relevant to an ISP.
A: While defining the scope and target community for the work, we surveyed the various network and Internet security associations and initiatives.
Most of them were focused on the political and corporate issues rather than the daily incident handling work of a CSIRT. Our observation was that there was no common format for exchanging computer/network security related information exchange; the most appropriate place for such work is seen in the IETF framework.

Q: Is the IODEF standard meant to be a software template?
A: IODEF is a data format or rather a language for describing all aspects of an incident during its lifetime.

Q: Although transport issues are outside the scope of the IODEF WG, There are cases when incident handling requires cutting network connectivity like in case of recent network viruses/worms. How are these cases are handled by IODEF?
A: Communication issues like these are the concern of that particular CSIRT and it should know or decide how to act in such cases.

5. Requirements for such a standard (including analysis of the current IODEF requirements) - RD (15 min)
--------------------------------------------------------------------

The fourth presentation summarized the requirements of the IODEF data format.

Slides:
http://www.terena.nl/tech/inch/docs/inch_bof_requirements.ppt

Q: How can you define confidence? IDMEF also has this, it is a float; the confidence level is expressed in numbers, that tends to become meaningless.
A: An IDS producing IDMEF alerts uses statistical methods for defining/calculating the confidence level. The IODEF reuses the IDMEF definition of confidence but also allows the confidence level to be defined according to the confidence of the incident manager/triage creating or handling a particular incident. This definition may differ among CSIRTs and requires further attention.

Q: Are you going to try to create a standard for submitting evidence into various courts worldwide?
A: No, this is strictly a standard for communicating about incidents.
However, nothing precludes extensions to the standard specifically tweaked for the evidence guidelines of a particular legal framework.

Q: How are you going to trust the data?
A: As soon as it gets into the framework: use digital signatures. Before the data enters the framework, there is no supported way. You will of course have to use the mechanisms you're currently using to establish the amount of trust you can put into data coming from persons/machines.

Q: The requirements talk about confidentiality and authenticity, where are the other standard security services, particularly availability?
A: The requirements also define integrity and non-repudiation. However, these are all in the data format. Availability is related to transport (communication/network protocol) that is out of scope. We define what goes across the wire, not how.

6. IODEF Design principles (including relation to IDMEF) - YD (15 min)
--------------------------------------------------------------------

The fifth presentation was an outline and description of the design principles behind the IODEF data format.

Slides:
http://www.terena.nl/tech/inch/docs/docs/ietf52-inch-bof-iodef-design.ppt

7. Presentation of current IODEF Data Model and XML DTD document - RD (15 min)
--------------------------------------------------------------------

The sixth presentation was an overview of the IODEF data model, and described in some detail the top-level classes.

Slides:
http://www.terena.nl/tech/inch/docs/inch_bof_datamodel.ppt

Q: Can I put a file containing evidence in the data model?
A: Yes. You can include the entire file as an EvidenceItem or use a link to the particular file.

Q: The detect time, is that the same as in IDMEF?
A: Correct.

Q: The correlation incident, is that meant to link different incidents together?
A: Correct. This is what a CSIRT member already does in his head. We're trying to put that into a format.

Q: Are there current implementations speaking IODEF?
A: There is someone in Canada who has declared to have implemented IODEF in Lotus Domino; another implementation of an early IODEF draft has been done at a Swedish university to facilitate the exchange of incident related data between Scandinavian universities. A TERENA pilot project has also started implementing it in a project that should be finished by September 2002.

Q: Describe the integration between IODEF and IDMEF.
A: We follow the development of the IDMEF very carefully as we intend to have (complete upward) compatibility between these two standards. Also we have the intention to reuse (if possible) the open-source, reference implementation of IDMEF (libidmef) to create libiodef. There is also the idea that the IODEF implementation should understand IDMEF enough to at least extract the necessary information from an IDMEF message into an IODEF description.

Q: Do you envision analysis engines being built using this?
A: This is not the primary purpose of this standard, but yes, this is definitely something that could be done.

Q: Who would be the author of a report?
A: The report could be created by a machine (a library would be useful).
In the end, it is assumed a report will be created through human interaction with an automated system.

Q: Is CERT/CC involved in this work?
A: The CERT/CC is involved in the TERENA IODEF working-group.

Q: Is it centralizing the data streams involved in incident handling?
A: No, the IODEF draft is not related at all to centralizing data. Rather, it provides a data format to allow peers to collaborate about incidents.

Q: You're saying the format can include log data (evidence), but how to handle all those different tools that can generate logs? If you send a log from A to B and B does not have the log-reading tool A has, there is a problem for B.
A: Indeed, that is why you have the pointer to evidence and the 'type of tool' attribute to indicate which tool was used. How to get that tool to B is out of scope.

8. Discussion: How to proceed and proposed Charter (30 min)
--------------------------------------------------------------------

Upon concluding the general presentations, a rough charter was proposed for discussion.

Initially, there were some general questions about an incident handling standard.

Q: How do you ensure confidentiality/security of the message (PGP, PKI, S/MIME)?
A: We'll try to provide this in the standard to allow the resulting message to be self-contained. If we find it is not feasible, there are enough alternatives to ensure message confidentiality during transport.

Q: Would a reporter-specified severity level be included in the standard, and would it dictate some time period for acknowledgment by the receiver?
A: The data model could indeed include such a severity level. However, in reference to a "time period for acknowledgment", this is policy issue outside of the scope of the standard. Such a relationship would have to be negotiated out-of-band.

Next, specific details of the proposed charter were discussed.

Q: Why conduct this work in the IETF, and not in the W3C?
A: The W3C mostly focuses on developing/creating languages and data formats for general use (largely in the domain of WWW applications). There is a need to make the exchanging of incident information more formalized (and common) among CSIRTs and other organizations dealing with computer security issues. An organization such as the IETF, which creates standards for the Internet community, seemed most appropriate.

It was observed that the bullet points in the Description section of the proposed charter represented only the beneficiaries of an incident-handling standard, not the problem. The problem was enumerated as 'how to represent/describe incidents'. After discussion, there was consensus that the problem statement should be refined with a bit more detail.

There was also concern about the specific scope of the working-group. It was noted that it was unclear from the proposed charter what the exact area of work of the working group would be (i.e. the current text left the area too broad). The conclusion of this discussion was that the problem statement needs to be more explicit in the details of its deliverables (either by way of describing the top-level classes or in words like "what, when, how" etc.).

There was agreement on the Scope and Output of the WG sections.

9. Conclusions (next steps, interest level, etc.) (10 min)
--------------------------------------------------------------------

The BoF chairs asked whether a working group should be formed to pursue this work. After asking for 'mmm', there was 'mmm'. After asking for hands, there was a clear indication that consensus reached.

Slides

Agenda
Problem Statement & Scope of Work
'Incident handling workflow, where would the standard fit in?'
Background: IODEF working group
INCH Requirements
IODEF Data Model
IODEF Design principles and relation to IDMEF