Last Modified: 2004-06-17
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.
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 |
Extended Incident Handling (INCH) WG Minutes
IETF 60 Thursday, 13:00-15:00, August 5, 2004 San Diego, USA Chair: Roman Danyliw <rdd@cert.org> Security Area Adviser: Steven Bellovin <smb@research.att.com> ---[ Agenda ]----------------------------------------------------------- o Administrative (Roman Danyliw, 10 min) o Requirements draft review (draft-ietf-inch-requirements-03) (Hiroyuki Ohno, 10 min) o Data Model draft review (draft-ietf-inch-iodef-02) (Roman Danyliw, 25 min) o Implementation guide draft (draft-ietf-inch-implement-00) (Roman Danyliw, 5 min) o RID draft review (draft-ietf-inch-rid-00) (Kathleen Moriarty, 20 min) o New Work Vulnerabilities and Exploits Description Exchange Format (VEDEF) (Ian Bryant, 20 min) ---[ Administrative ]--------------------------------------------------- Roman Danyliw presented a summary of the INCH working group. o News: An interim meeting was held between IETF 59 and 60 in June 2004 in Budapest, Hungary. o Updates to the schedule were made to reflect a slight slippage in the delivery dates (WG last-call) of the WG drafts. ] done Initial I-D of the implementation guidelines document ] AUG 04 Submit requirements I-D to the IESG as Informational o The I-D editor has a list of the remaining concerns with the draft ] NOV 04 Submit incident data language specification I-D to the IESG as Proposed Standard ] NOV 04 Submit distributed denial of service extension specification I-D to the IESG as Proposed Standard ] JAN 04 Submit implementation guidelines I-D to the IESG as Informational o Blocking on the finalization of the IODEF ---[ Requirements ]----------------------------------------------------- document: draft-ietf-inch-requirements-03 presentation: <http://www.cert.org/ietf/inch/ietf60/ietf60-inch-req.pdf> Hiroyuki Ohno presented on the remaining issues in the requirements draft. Comments and Discussion: - The definition of a CSIRT must be consistent across all documents. Currently, the charter, data model, and requirements documents are out of sync. Q: [In discussing, the definition of "incident"] Should IODEF only represent security events? How does one instantly know that an event is security related; is there no time component? A: [Follow-up comments] - Resoundingly, IODEF should only represent security incidents - Social engineering is something that IODEF should be able to represent. - Timeliness in generating reports is key. ---[ Data Model ]------------------------------------------------------- document: draft-ietf-inch-iodef-02 presentation: <http://www.cert.org/ietf/inch/ietf60/ietf60-inch-dm.pdf> Roman Danyliw presented a review of the open issues related to the current data model. There are a significant number of issues that have been resolved that need to be reflected in the 03 version of the draft. Comments and Discussion: (Note: Comments are organized according to the specific issue to which they relate) #356 Standardizing the extension classes <https://rt.psg.com/Ticket/Display.html?id=356> o Consensus to resolve this issue without waiting for XML Schema #359 Supporting AS Numbers <https://rt.psg.com/Ticket/Display.html?id=359> o A reminder was made that while this is desirable in the data model, it is not necessary for RID. ---[ Implementation Guide draft ]--------------------------------------- document: draft-ietf-inch-implement-00 presentation: <http://www.cert.org/ietf/inch/ietf60/ietf60-inch-implementation.pdf> Roman Danyliw presented on the status of the implementation guide. Effectively, nothing new has been done with the draft since there has been no significant resolution to the issues posed in the data-model Comments and Discussion: Q: [posed to the WG] Are document updates being used, and how do CSIRTs practically implement this communication. A: None of the 4 present CSIRTs updated incident data once it was sent. This suggests that document updates do not need to be supported. Additional discussion is necessary on this issue. ---[ RID draft ]-------------------------------------------------------- document: draft-ietf-inch-rid-00 presentation: <http://www.cert.org/ietf/inch/ietf60/ietf60-inch-rid.pdf> Kathleen Moriarty presented on the current status of the RID protocol. Feedback: The RID protocol needs to specify a transport protocol. Up till now, the core data model has been agnostic on this issue. However, the feedback from all implementers, again voiced at the meeting, suggests that this lack of specificity is not helpful for promoting adoption. Hence, the investigation into the protocol choice for RID will be used to inform an IODEF-wide choice. The likely candidate is SOAP. The intent is to find a shared solution for both the generic IODEF data model, and the more application specific RID extension. ---[ New Work ]---------------------------------------------------------- presentation: <http://www.cert.org/ietf/inch/ietf60/ietf60-inch-vedef.pdf> Ian Bryant and Yurie Itoh presented on the Vulnerabilities and Exploits Description Exchange Format (VEDEF). The intent of this presentation was to propose new work for the WG in standardizing vulnerability collaboration. This work would be completely distinct from the current efforts with IODEF. Several questions were posed: Q: How is this better/different than the full-disclosure mailing list? A: It is standardized. Q: How does this related to other efforts, specifically work being done in OASIS? A: This work would bring together the various efforts currently underway. With regard to OASIS, this is a limited standards body not widely known outside the US. Also, work appears to have stalled in OASIS. Q: Are the communities currently working on this problem in support of/or willing to participate in this effort in the IETF? A: The current communities are fractured and are not working together. To assess the next step forward, the chair asked the WG whether there were individuals in the group that would be willing to work on these drafts. There were few volunteers outside of the presenters. Hence, without additional interest, this work will not be added to the WG charter. |