2.6.4 Extended Incident Handling (inch)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-27

Chair(s):

Roman Danyliw <rdd@cert.org>

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Sam Hartman <hartmans-ietf@mit.edu>

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
Done  Initial I-D of the traceback extension specification
Apr 05  Submit requirements I-D to the IESG as Informational
Apr 05  Submit initial draft of phishing extension specification I-D
Jul 05  Submit incident data language specification I-D to the IESG as Proposed
Jul 05  Submit traceback extension specification I-D to the IESG as Proposed
Jul 05  Submit phishing extension specification I-D to the IESG as Proposed
Aug 05  Submit implementation guidelines I-D to the IESG as Informational

Internet-Drafts:

  • draft-ietf-inch-requirements-04.txt
  • draft-ietf-inch-rid-02.txt
  • draft-ietf-inch-phishingextns-01.txt

    No Request For Comments

    Current Meeting Report
    Extended Incident Handling (INCH) WG Minutes
    IETF 63
    Wednesday, August 3, 2005, 10.30-12.30
    Paris, France

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

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

    o Administrative
    (Roman Danyliw, 5 min)

    o Requirements draft review (draft-ietf-inch-requirements-04)
    (Glenn Keeni-Mansfield, 5 min)

    o Data Model draft review (draft-ietf-inch-iodef-04)
    (Roman Danyliw, 25 min)

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

    o RID draft review (draft-ietf-inch-rid-03)
    (Kathleen Moriarty, 20 min)

    o Transport draft review (draft-moriarty-soap-00)
    (Brian Trammell, 20 min)

    o Phishing extension draft review (draft-ietf-inch-phishingextns-01)
    (Pat Cain, 20 min)

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

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

    Roman Danyliw presented a summary of the INCH working group.

    o A new WG document that extends the IODEF to describe phishing incidents has been accept. This work was previously presented at IETF 62. See draft-ietf-inch-phishingextns-01.

    o An individual draft, draft-moriarty-soap-00, was submitted to describe a SOAP transport binding for the IODEF. This draft will help inform the WG and the IESG as to whether this direction is appropriate for the WG. Transport entails a substantial expansion of the charter.

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

    ] Sep 05 Submit requirements I-D to the IESG as Informational
    ] Dec 05 Submit incident data language specification I-D to the IESG as Proposed
    ] Dec 05 Submit phishing extension specification I-D to the IESG as Proposed
    ] Dec 05 Submit traceback extension specification I-D to the IESG as Proposed
    ] Feb 06 Submit implementation guidelines I-D to the IESG as Informational


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

    document: draft-ietf-inch-requirements-04
    presentation: <http://www.cert.org/ietf/inch/ietf63/ietf63-inch-req.pdf>

    Glenn Keeni-Mansfield reported on the new -04 version of the requirements draft. It addressed a number of proofing changes. Another final set of comments were provided just before the meeting. An -05 draft will be produced by August 30, and the document will then enter WG last call.


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

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

    Roman Danyliw presented on the substantial updates found in the -04 draft, (notably the introduction of an XML Schema), and the group discussed the remaining modeling issues. The WG is aiming to freeze the data model by September 2005 and use the subsequent months till December 2005 to address the editorial issues.

    Comments and Discussion on open issues:

    #698: Representing a Name in <Contact>

    o WG consensus was to adopt both Proposal #2 (i.e., Rename the name class used in Contact to PersonOrgName) and Proposal #3 (i.e., a DN-like syntax) but require only one to be present.

    o If a DN-like construct is introduced, it should be made explicit that no certificate processing is required.

    #855: Formalize <Location>

    o The existing proposal is poorly understood. The original commenter on this change needs to clarify their position

    o There was limited support for binding a DN syntax (i.e., certificate information often stored in LDAP repositories) to hosts

    #701: Review of Default Values

    o Progress is slower than expected due to the conflicting specifications found in the text, DTD, and Schema.

    #551: Formalizing <RecordData>

    o Proposed schema changes exist, but it remains poorly understood. The original commenter has been asked to provide text for the schema.

    #857: Handling Binary Files

    o Still awaiting to hear back from original commenter on a proposal

    Comments unrelated to open issues:

    o Specifications on using XML-Encryption and Signature are found in multiple drafts: data model, RID, and SOAP. It should be only in once place and referenced from the others. The authors of the various drafts will determine the right way to accomplish this task.

    o The actions taken in a trace previously represented in RID must be moved into the RecordItem class.


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

    document: draft-ietf-inch-implement-01 (now expired)

    Roman Danyliw reported that no changes have been made to the
    implementation draft pending resolution on transport and data model
    issues. All open issues remain open.


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

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

    Kathleen Moriarty presented the new -03 draft which has completed RID's transformation into a generalized messaging format for IODEF. Given the recent changes in the data model, a revision of this draft is necessary.

    Discussion:

    Q: Does RID always need to be used in a consortium?
    A: No, bilateral or peer relationships are very much possible.

    Q: It appears that RID has a way to specify a policy for the sender, but what about a policy for the receiver?
    A: When working with peers, one will likely trust one more than the other. For this circumstance, there is the Confidence class in IODEF.

    ---[ SOAP Binding draft ]-----------------------------------------------

    presentation: <http://www.cert.org/ietf/inch/ietf63/ietf63-inch-soap.pdf>
    document: draft-moriarty-soap-00

    Complementing the RID message format, Brian Trammel presented a new individual I-D that provides a SOAP transport binding. This draft was a response to the community's request and the WG's and AD's uncertainty about adopting a transport specification. Additional coordination with RID and the implementation draft are necessary and will be included in the -01 draft.


    ---[ Phishing Extensions draft ]----------------------------------------

    presentation: <http://www.cert.org/ietf/inch/ietf63/ietf63-inch-phishing.pdf>
    document: draft-ietf-inch-phishingextns-01

    Pat Cain presented the -01 draft of the phishing extensions to the IODEF. A new version of the draft will be ready in mid-August.

    Comments:

    o An XForm generator for phishing IODEF message can be found at http://coopercain.com/incidents/index.htm

    Slides

    Agenda
    INCH Requirements
    IODEF Data Model Status
    RID IETF Draft Update
    A SOAP Transport for RID
    INCH Extensions for Phishing