2.6.3 Extended Incident Handling (inch)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-05

Chair(s):

Roman Danyliw <rdd@cert.org>

Security Area Director(s):

Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>

Security Area Advisor:

Steven Bellovin <smb@research.att.com>

Mailing Lists:

General Discussion: inch@nic.surfnet.nl
To Subscribe: listserv@nic.surfnet.nl
In Body: subscribe inch
Archive: http://listserv.surfnet.nl/archives/inch.html

Description of Working Group:

Background

Computer security incidents occur across administrative domains often
spanning different organizations and national borders. Therefore, the
free exchange of incident information and statistics among involved
parties and the responsible Computer Security Incident Response Teams
(CSIRTs) is crucial for both reactionary analysis of current intruder
activity and proactive identification of trends that can lead to
incident prevention.

Scope

The purpose of the Incident Handling (INCH) working group is to define
a
data format for exchanging security incident information used by a
CSIRT.
A CSIRT is defined broadly as an entity with a security role or
responsibility in a given organization. Often there is a communication
and collaborating component. Organizationally, a CSIRT might be a
dedicated team in a network operations group, or a single individual
with other responsibilities.

The primary use case for the INCH work is to standardize the the
communication between a CSIRT and:

* its constituency (e.g., users, customers) reporting misuse;

* parties involved in an incident (e.g., law enforcement, attacking
site); or

* peer CSIRTs sharing information.

In doing such sharing, especially when action is being requested, due
attention must be paid to authorization and privacy issues.

This format will support the now largely human-intensive dimension of
the incident handling process. It will represent the product of various
incremental data gathering and analysis operations performed by a CSIRT
from the time when the system misuse was initially reported (perhaps by
an automated system) till ultimate resolution. Specifically, the
working group will address the issues related to representing

* the source(s) and target(s) of system misuse, as well as the
    analysis of their behavior;

* the evidence to support any analysis results;

* a scheme to document the incident investigation and analysis
    process; and

* constructs to facilitate the exchange of security information
    across administrative domains (e.g., internationalization, data
    sensitivity).

The WG will investigate the information model needed to support the
typical, operational workflow of the incident handling processes found
at Internet Service Providers; Managed Security Service Providers; Risk
Analysis vendors; and traditional, internal CSIRTs.

Constraints

The WG will not attempt to

- - define an incident or address the implications of sharing incident
    data across administrative domains;

- - define a format for computer security related information for which
    there is already a standard, but where applicable, provide full
    compatibility (e.g. IDWG's IDMEF, Mitre's CVE); or

- - define a protocol for exchanging the incident information.

Output of Working Group

1. A document describing the high-level functional requirements of a
    data format for collaboration between CSIRTs and parties involved
    when handling computer security incidents.

2. A specification of the extensible, incident data language that
    describes the data formats that satisfy the requirements.

3. Guidelines for implementing the WG data format (Output #2 of the
    WG).

4. A set of sample incident reports and their associate representation
    in the incident data language.

Goals and Milestones:

Done  Initial I-D of the incident data language specification
Done  Initial I-D for the requirements specification
Done  Initial I-D of the implementation guidelines document
May 04  Initial I-D of the traceback extension specification
May 04  Submit requirements I-D to the IESG as Informational
Aug 04  Submit incident data language specification I-D to the IESG as Proposed
Aug 04  Submit traceback extension specification I-D to the IESG as Proposed
Sep 04  Submit implementation guidelines I-D to the IESG as Informational

Internet-Drafts:

  • draft-ietf-inch-rid-01.txt

    No Request For Comments

    Current Meeting Report
    Extended Incident Handling (INCH) WG Minutes
    IETF 61
    Thursday, November 11, 2004, 09.00-11.30
    Washington DC, USA

    Chair: Roman Danyliw <rdd@cert.org>
    AD Adviser: Sam Hartman <hartmans@mit.edu>

    ---[ Agenda ]-----------------------------------------------------------

    o Administrative
    (Roman Danyliw, 10 min)

    o Requirements draft review (draft-ietf-inch-requirements-03.01)
    (Glenn Keeni-Mansfield, 15 min)

    o Data Model draft review (draft-ietf-inch-iodef-03)
    (Roman Danyliw, 30 min)

    o Implementation guide draft (draft-ietf-inch-implement-01)
    (Roman Danyliw, 15 min)

    o RID draft review (draft-ietf-inch-rid-01)
    (Kathleen Moriarty, 25 min)

    o RID Implementation Report
    (Naohiro Fukuda, MEW, 20 min)

    o Architecture for Incident Querying
    (Glenn Keeni-Mansfield, 15 min)


    ---[ Administrative ]---------------------------------------------------

    presentation: <http://www.cert.org/ietf/inch/ietf61/ietf61-inch-agenda.pdf>

    Roman Danyliw presented a summary of the INCH working group.

    o Steve Bellovin has stepped down as AD in the Security Area. Sam Hartman is now the AD for the WG.

    o Updates to the schedule were made to reflect a slight slippage in the delivery dates (WG last-call) of the WG drafts.


    ] Dec 04 Submit requirements I-D to the IESG as Informational
    ] Apr 05 Submit incident data language specification I-D to the IESG as Proposed
    ] Apr 05 Submit traceback extension specification I-D to the IESG as Proposed
    ] May 05 Submit implementation guidelines I-D to the IESG as Informational

    o Implementer feedback indicates that the WG needs to define a messaging format and transport binding. Discussions suggest that SOAP over HTTP or BEEP are likely candidate solutions. Procedurally, this new document would entail re-chartering. However, more significant are the larger application implications of this work. In order to proceed, a draft describing the SOAP messaging format with a specific binding will be created. The protocol draft will help inform the WG (and the IESG) as to whether this direction is appropriate. Kathleen Moriarty and Roman Danyliw have volunteered to take on this work. Additional help would be greatly appreciated.


    ---[ Requirements ]-----------------------------------------------------

    document: draft-ietf-inch-requirements-03.01

    The requirements document is ready for WG last-call contingent on a final proofing review that will be completed within two weeks.

    ---[ Data Model ]-------------------------------------------------------

    document: draft-ietf-inch-iodef-03
    presentation: <http://www.cert.org/ietf/inch/ietf61/ietf61-inch-dm.pdf>

    Roman Danyliw described the numerous changes made in the new -03 version of the draft. This new draft addressed many of the long-standing modeling issues. It is felt that the remaining issues necessary to bring this work to last-call are known, and now merely need to be addressed. The implications of XML Schema remains the biggest issue.

    Comments and Discussion:

    (Note: Comments are organized according to the specific issue to which they relate)

    #356: Standardize extensions
    <https://rt.psg.com/Ticket/Display.html?id=356>

    o XMPP already has a way to standardize DTD extensions. Existing approaches should be used instead of inventing new ones.

    o Solution should be Schema specific, no need to fix this issue in DTD

    #551: Formalize RecordData
    <https://rt.psg.com/Ticket/Display.html?id=551>

    o Implementing this change is crucial to discouraging the the in-lining of large amounts of data in a document.

    o Q: Does this construct fulfill the filtering requirement?
    A: No, this will not help in the filtering of incident reports (documents). Rather, it aids in the filtering of logs data that would be referenced by the IODEF.

    o Does the name class aggregated in Contact class require its own class since it is typed as PERSON, and in all other instances it is defined as a STRING?

    o Context sensitive semantics should be avoided. Defining a new class is supported.

    o Specifying a format for the TIMEZONE data type

    o Use [+-]\d{2}\d{2}

    o (author to the WG) Is there a better way to represent an application than the current <Application> class (i.e., is a free-form application name, and version number sufficient?).

    o WG agrees this is hard; leave the representation as is.

    o (author to the WG) Should the OS name be associated with the <Application>?

    o Yes, OS information is relevant to assessing vulnerability.

    o Same representation problems as in <Application>, but this is OK.


    ---[ Implementation Guide draft ]---------------------------------------

    document: draft-ietf-inch-implement-01
    presentation: <http://www.cert.org/ietf/inch/ietf61/ietf61-inch-implementation.pdf>

    Roman Danyliw described the changes made, and remaining issue in the -01 version of the implementation guide. This version is merely an update to reflect changes in the -03 draft of the data model. The most pressing issue that requires resolution is a recommendation on transport and messaging.

    Comments and Discussion:

    (Note: Comments are organized according to the specific issue to which they relate)

    o What to do about IODEF-Document@id?

    Consensus is that this attribute is a construct to support messaging, and should there be removed.

    o What to do a about "document updates"?

    Consensus has again confirmed that document updates are desirable, but are currently not performed because of their difficulty.

    Several suggestions were made:
    - Redesign the data model to support the notion of a delta-format
    - <History> class already supports a way to convey that changes or updates were made
    - The messaging envelope can convey that updates are present.

    The consensus was a change to the data model to create a delta-format was too hard. Instead, ensuring that <History> is rich enough to convey the right information, coupled with an appropriate message envelope will be sufficient.

    o What to do with @ident?

    ident attributes are scattered inconsistently through out the data model. There purpose was to relate complex information. It was the feeling of the author that this problem is solved through the various recursive structures in the IODEF data model. There was consensus to remove this attribute.

    o Hiroyuki Kido has volunteered to provide examples for Section 5 of the draft.


    ---[ RID draft ]--------------------------------------------------------

    document: draft-ietf-inch-rid-01
    presentation: <http://www.cert.org/ietf/inch/ietf61/ietf61-inch-rid.pdf>

    Kathleen Moriarty presented on the -01 version of RID, noting changes from the previous draft and remaining issues. Work is almost complete on this draft.

    Comments and Discussion:

    Q: Is transport security adequate for RID?
    A: No. Hop-by-hop security is not adequate. End-points may need various security properties ensured hop-to-hop, end-to-end, or both.

    Q: Would people using RID typically have credential infrastructures required for RID?
    A: An infrastructure to support XML encryption and signature will be necessary.

    The RID draft continues to inform the working group about transport issues. When this issue is resolved working group wide, then discussion of transport issues will be removed from the RID draft in favor of a dedicated document.


    ---[ RID Implementation Report ]-----------------------------------------

    presentation: <http://www.cert.org/ietf/inch/ietf61/ietf61-inch-mew.pdf>

    Naohiro Fukuda presented on MEW's implementation of RID.

    Comments and Discussion:

    Q: Would changing transport from HTTP + SOAP change multi-AS trace time
    at all given that processing time dwarfs transport time?
    A: Yes, using something other than HTTP would be fast.


    ---[ Incident Tracing Architecture ]-------------------------------------

    presentation: <http://www.cert.org/ietf/inch/ietf61/ietf61-inch-incident-tracking-architecture.pdf>
    document: draft-glenn-ippt-arch-01

    Glenn Keeni-Mansfield led a discussion on a broad architecture to use IODEF to track incident activity. This discuss drew ideas from a draft (draft-glenn-ippt-arch-01) on packet trace-back.

    Comments and Discussion:

    o There was a bit of confusion on the concept, since the specific draft dealt with packets not incidents, the subject of the WG.

    o The draft seems to imply much about software design. However, the underlying requirements for this system were not clear.

    o Asking collaborating sites whether they have seen a particular packet is relatively easy since this comparison is an explicit match. However, incident information is not so straight forward. Comparisons with this type of information are comparable to a similarity match. Does this mean we need a filtering or query language for IODEF documents?

    Given some of this confusion, the author will update the draft to describe the architecture in terms of incident information.

    Slides

    Agenda
    IODEF Data Model Status
    IODEF Implementation Guide Update
    RID IETF Draft Update
    RID Implementation Report
    An Architecture for Tracing Incidents across the Internet