WG Action: RECHARTER: Extended Incident Handling (inch)

[The IESG <iesg-secretary at ietf.org>]

The charter of the Extended Incident Handling (inch) working group in the
Security Area of the IETF has been updated. For additional information, 
please contact the Area Directors or the working group Chairs.

+++

Extended Incident Handling (inch)
==================================

Current Status: Active Working Group

Chair(s):
Roman Danyliw <rdd at cert.org>

Security Area Director(s):
Russ Housley <housley at vigilsec.com>
Sam Hartman <hartmans-ietf at mit.edu>

Security Area Advisor:
Sam Hartman <hartmans-ietf at mit.edu>

Mailing Lists:
General Discussion: inch at nic.surfnet.nl
To Subscribe: listserv at 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  
Done    Submit initial draft of phishing extension specification I-D  
Nov 2005    Initial I-D of a transport binding specification  
Dec 2005    Submit messaging format specification I-D to the IESG as Proposed  
Dec 2005    Submit incident data language specification I-D to the IESG as
Proposed  
Dec 2005    Submit requirements I-D to the IESG as Informational  
Dec 2005    Submit transport binding specification I-D to the IESG as Proposed
Dec 2005    Submit phishing extension specification I-D to the IESG as Proposed
 
Feb 2006    Submit implementation guidelines I-D to the IESG as Informational  


_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce