[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

WG Action: RECHARTER: Extended Incident Handling (inch)



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 Chair.


 Extended Incident Handling (inch)
 ---------------------------------

 Last Modified: 2003-11-05 

 Current Status: Active Working Group

 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.