2.6.3 Extended Incident Handling (inch)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-07

Chair(s):

Roman Danyliw <rdd@cert.org>

Security Area Director(s):

Russell 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
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

Internet-Drafts:

  • draft-ietf-inch-iodef-03.txt
  • draft-ietf-inch-requirements-03.txt
  • draft-ietf-inch-implement-01.txt
  • draft-ietf-inch-rid-01.txt

    No Request For Comments

    Current Meeting Report
    Extended Incident Handling (INCH) WG Minutes
    IETF 62
    Wednesday, March 9, 2005, 15.30-17.30
    Minneapolis, 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)
    (Glenn Keeni-Mansfield, 15 min)

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

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

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

    o Extending IODEF for Phishing Reports (draft-jevans-phishing-xml-00)
    (Pat Cain, 20 min)

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

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

    Roman Danyliw presented a summary of the INCH working group.

    o The new PROTO process for document shepherding will only apply to certain drafts in the WG due to the chair being co-author on certain drafts.

    o The Tools team has generated WG-specific pages:
    http://tools.ietf.org/wg/inch/

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

    ] Apr 05 Submit requirements I-D to the IESG as Informational
    ] 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
    ] Aug 05 Submit implementation guidelines I-D to the IESG as Informational


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

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


    Kathleen Moriarty presented for Glenn Keeni-Mansfield (who was unable to attend the meeting) on the new -03 draft. This revision introduced more concise definitions and copious proofing. The authors will release another revision of this document based on late feedback, but the document is about ready for WG last-call after the -04 draft. The community needs to begin making a final review.


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

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

    Roman Danyliw presented on updates that are in progress on the -03 data model draft. Primarily, theses changes are related to the migration to Schema, and representing contact and forensic information.

    Comments and Discussion:

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

    #365: XML Schema v04
    o Yuri Demchenko has maintained a Schema reflecting DTD changes through the -03 discussion. This schema will appear in the -04 draft.
    <http://www.uazone.org/demch/projects/iodef/>

    o Ensure when updating the draft with Schema to remove all the associated
    references to DTD in the text.

    #699: Format TIMEZONE data-type
    o Proposal is to handle using the ISO8601 timezone format by adding RE to schema

    #856: Implementation-Friendly Time
    o Proposal to use xs:DateTime was accepted

    #356: Standardize extensions
    o Deemed unnecessary given the transition to Schema

    #703: Redesign <Analyzer>
    o Proposal to rename the element to <Sensor>, drop <pid> <path> <Process>, and add versioning was accepted.

    #858: Redefine Incident@purpose
    o Ensure that this attribute is consistent with the RID message types

    #702: Representing OS information
    o Proposal to model the OS information (<OperatingSystem>) after <Application> was accepted.

    #698: Representing a Name in <Contact>
    #855: Formalize <Location>
    o Existing proposals conflict for #698 and #855; no resolution in discussion. Further discussion on mailing list is required.

    o The difficulties in both issues seem to have the same root modeling problem.

    #701: Review of Default Values
    o Pat Cain volunteered to help in this review

    #551: Formalizing <RecordData>
    o Ensure that a byte offset can be specified for binary files

    #857: Handling Binary Files
    o Hiroyuki Kido is investigating XOP and other W3C standards for handling binary files

    Questions:

    Q: Are trouble-ticket numbers tracked in IODEF?
    A: Yes, this information is captured in the IncidentID and AlternativeID elements.


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

    document: draft-ietf-inch-implement-01

    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-01
    presentation: <http://www.cert.org/ietf/inch/ietf62/ietf62-inch-rid.pdf>

    Kathleen Moriarty presented on updates that are in progress for RID. Primarily the focus of the -02 draft will be a generalized messaging format for all IODEF documents.

    Discussion:

    Q: (author) Does a Report message need a corresponding reply?
    A: Probably not was the audience consensus, but the draft text needs to reflect that once such a message is sent there is no responsibility for the sender.

    Comments:

    o Request by author for on the completeness of RID Policy

    o Sender and recipient in an IODEF dialogue become SOAP endpoints

    o If a response to a received message will occur in "human-time", a trace pending message should be sent.

    ---[ Phishing Extensions to IODEF ]--------------------------------------

    presentation: <http://www.cert.org/ietf/inch/ietf62/ietf62-inch-phishing.pdf>
    document: draft-jevans-phishing-xml-00

    Pat Cain presented an individual draft that extends the IODEF to describe phishing and spam reports. As a logic extension of ongoing work, there was consensus to accepted this draft as a WG document. To this end, the following will be added to the charter:

    ] Jul 05 Submit phishing extension specification I-D to the IESG as Proposed

    As a follow-up to the draft, an XForm generator will be implemented to collect phishing information. This will also provide another independent implementation of IODEF.

    Slides

    Agenda
    INCH Requirements
    IODEF Data Model Status
    RID IETF Draft Update
    Phishing Reports using the INCH Format