Last Modified: 2004-02-10
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 | |
Nov 03 | Initial I-D of the implementation guidelines document | |
Dec 03 | Submit requirements I-D to the IESG as Informational | |
Dec 03 | Submit incident data language specification I-D to the IESG as Proposed | |
Mar 04 | Submit implementation guidelines I-D to the IESG as Informational |
Extended Incident Handling (INCH) WG Minutes IETF 59 - Thursday, 13.00-15.00, March 4, 2004 Seoul, Korea Chair: Roman Danyliw <rdd@cert.org> Security Area Adviser: Steven Bellovin <smb@research.att.com> ---[ Agenda ]--------------------------------- -------------------------- o Administrative o Implementation - Implementation Guide draft (draft-ietf-inch-implement-00) (Roman Danyliw) - "Three class based models of traceback systems between ASs" (Naohiro Fukuda) - "Early Experience from the JPCERT/CC IODEF Activity" (Huroyuki Kido, Gleen Keeni-Mansfield) o Requirements draft review (draft-ietf-inch-requirements-02) (Glenn Keeni-Mansfield) o Data Model draft review (draft-ietf-inch-iodef-02) (Roman Danyliw) o Extensions - DDOS RID draft review (draft-moriarty-ddos-rid-06) (Kathleen Moriarty) ---[ Administrative ]--------------------------------------------------- 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 ] APR 04 Submit requirements I-D to the IESG as Informational ] AUG 04 Submit incident data language specification I-D to the IESG as Proposed Standard ] AUG 04 Submit distributed denial of service extension specification I-D to the IESG as Proposed Standard ] OCT 04 Submit implementation guidelines I-D to the IESG as Informational ---[ Implementation Guide draft ]---------------------------------------- document: draft-ietf-inch-implement-00 presentation: <http://www.cert.org/ietf/inch/i etf59/ietf59-inch-implementation.pdf> Roman Danyliw presented on the newly written IODEF implementation draft. It remains a work in progress. There are a number of areas in the document that highlight where further specification from the WG is required. Comments and Questions: o Specific guidelines and examples must be given for generating globally unique identifiers as required by the id attribute of the IODEF-Description class. o Examples of IODEF documents using XML-Encryption and XML-Signature will be necessary. o One of the issues identified in the draft was the need to clarify the technique to perform updates to existing incidents. The described use case was the situation where there is follow-up information about an incident after an IODEF document has already been sent. o The question of whether document updates were currently being done was posed by the WG. No one in the WG current uses these kind of communication. The open question then remains do we need to support it? o Given that no one is using document updates, it was suggested that additional operational experience might dictate the implementation path. The consensus of the mailing list needs to be assessed. ---[ Implementation Experience #1 ]-------------------------------------- presentation: <http://www.cert.org/ietf/inch/i etf59/ietf59-inch-rid-implementation.pdf> Naohiro Fukuda presented on "Three class based models of traceback systems between ASs" to discuss a practical implementation of the RID protocol. ---[ Implementation Experience #2 ]-------------------------------------- presentation: <http://www.cert.org/ietf/inch/i etf59/ietf59-inch-jpcert.pdf> <http://www.cert.org/ietf/inch/ietf59/i etf59-inch-jpcert-demo.pdf> Huroyuki Kido and Gleen Keeni-Mansfield presented on "Early Experience from the JPCERT/CC IODEF Activity". ---[ Requirements ]----------------------------------------------------- document: draft-ietf-inch-requirements-02 Glenn Mansfield Keeni reported that the requirements draft is complete, and ready for WG last call. Comments and Discussion: o A grammatical review of the document is necessary. o The use of SHOULD and MUST needs to be evaluated in the requirements. ---[ Data Model ]------------------------------- ------------------------ document: draft-ietf-inch-iodef-02 presentation: <http://www.cert.org/ietf/inch/i etf59/ietf59-inch-dm.pdf> Roman Danyliw presented a review of the open issues related to the current data model. Comments and Discussion: o An alternate to using domain names to uniquely identify CSIRTs in name attribute of the IncidentID class was proposed: use registry handle. (see: http://nic.surfnet.nl/scripts/wa.exe ?A2=ind03&L=inch&O=D&P=18902) o The WG was polled and there was consensus to both simplify the existing data model (e.g., moving legacy IDMEF constructs), and and support a flow relationships between hosts. (see: http://nic.surfnet.nl/scripts/wa.exe ?A2=ind03&L=inch&O=A&P=22621) A straw man proposal has been posted to the mailing list. (see: http://nic.surfnet.nl/scripts/wa.exe ?A2=ind04&L=inch&F=&S=&P=1576) This is a newly raised, complex issue that will require significant further discussion on the mailing list. o The representation for AS numbers should be done in conjunction to the new simplified model. AS number support is required for the RID draft. o Consensus was reached to standardize the extension classes with the proposal at http://nic.surfnet.nl/scripts/wa.e xe?A2=ind04&L=inch&F=&S=&P=748. Any objections from the mailing list? o There was no consensus on the type attribute of the extension classes. (see: http://nic.surfnet.nl/scripts/wa.exe ?A2=ind03&L=inch&O=D&P=21811) ---[ RID draft ]-------------------------------- ------------------------ document: draft-moriarty-ddos-rid-06 presentation: <http://www.cert.org/ietf/inch/i etf59/ietf59-inch-rid.pdf> Kathleen Moriarty presented on the current status of the RID protocol. Comments and Discussion: o Separate the transport and data modeling issues into distinct sections of the draft, perhaps even separate documents. o Use Reliable Transport for Syslog (RFC 3195) to exchange IODEF documents. |