2.6.2 Extended Incident Handling (inch)

Last Modified: 2003-05-19

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.

There is a substantial amount of related work in this domain in
TERENA's TF-CSIRT IODEF working group. The IODEF WG has already defined
a set of requirements for exchanging incident information in RFC 3067:
"TERENA's  Incident Object Description and Exchange Format
Requirements" and proposed a data format implementing them in the
"Incident Object Description and Exchange Format Data Model and
Extensible Markup Language (XML) Document Type Definition"
(http://www.terena.nl/task-forces/tf-csirt/iodef/).

Scope

The purpose of the Incident Handling (inch) working group is to define
data formats for communication between

* a CSIRT and its constituency (e.g., users, customers, trusted
  reporters) which reports system misuse;

* a CSIRT and parties involved in an incident investigation (e.g., law
  enforcement, attacking site); and

* collaborating CSIRTs sharing information.

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:
Sep 02  Initial I-D of the implementation guidelines and examples document
Dec 02  Initial I-D of the requirements specification
Dec 02  Submit requirements I-D to the IESG as Informational
Dec 02  Submit incident data language specification I-D to the IESG as Proposed
Jan 03  Submit implementation guidelines I-D to the IESG as Informational
Internet-Drafts:
  • - draft-ietf-inch-iodef-01.txt
  • - draft-ietf-inch-iodef-rfc3067bis-requirements-00.txt
  • - draft-ietf-inch-requirements-01.txt
    • No Request For Comments

    Current Meeting Report

     
    Incident Handling (INCH) WG Minutes
IETF 57 - Wednesday, 15.30-17.30, July 16, 2003
Vienna, Austria


                Chair: Roman Danyliw <rdd@cert.org>
Security Area Advisor: Steven Bellovin 
<smb@research.att.com>


---[ Agenda 
]---------------------------------
--------------------------


  o Administrative  (Roman Danyliw)


  o Data model requirements (Glenn Mansfield Keeni)
     - draft-ietf-inch-requirements-01


  o Data Model
     - draft-ietf-inch-iodef-01  (Jan Meijer)
     - XML Schema migration (Yuri Demchenko)


  o Implementation Guide (Roman Danyliw)



---[ Administrative 
]---------------------------------------------------
presenter: Roman Danyliw


o Steve Bellovin is the new security area adviser to the working group


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


 ] SEP 03    Initial I-D of the implementation guidelines document
 ] NOV 03    Submit requirements I-D to the IESG as Informational
 ] NOV 03    Submit incident data language specification I-D to the IESG as 
Proposed Standard
 ] FEB 04    Submit implementation guidelines I-D to the IESG as 
Informational



---[ Requirements 
]-----------------------------------------------------
presenter: Glenn Mansfield Keeni
 [1] 
http://www.andrew.cmu.edu/~rdanyliw/in
ch/ietf57/ietf57-inch-req.ppt


Keeni presented the remaining open issues in the requirement draft in [1].


Comments and Discussion:


  o There is a need for continued discussion of the 
domain-specific definitions found in Section #3.


    - "Impact" reflects a non-technical results on an organization (e.g., 
loss of customers).  On the other hand, "Damage" is a technical impact of an 
"Attack" on a host (e.g., denial of service).


    - Is the definition of "Incident" sufficiently broad to encompass the 
destruction of information?  Yes.


    - There appears to be a lack of symmetric in the definitions. If a 
"Target" and "Victim" are defined, then a corresponding "Source" and 
"Attacker" must also be added.


    - Reuse definitions from other sources.  If a term is used in other 
standards, cite that reference, and provide a description as to why the 
term is slightly different in the INCH domain.


  o The requirements should more clearly reflect the need for 
multi-lingual text.  A proposed change to support this need can be found at: 
<h
ttp://nic.surfnet.nl/scripts/wa.exe?A2
=ind03&L=inch&F=&S=&P=14060>


     - Provide a requirement that translations (multiple versions of the 
same text in different languages) of text must be consistent.


  o A requirement to deal with time corrections should be added.
    The situation of concern is how to convey that a host has their clock 
set incorrectly.


  o The term "data owner" used in several requirements is unclear; 
expound upon this definition.  Does this term refer to the "owner" as the 
source of the data?  person acting on the data?


  o Certain terms defined in the requirements draft are NOT used in the 
data model


  o There was some discussion on the time format of FINE: explicitly UTC, or 
to allow local timezone.  Ultimately, it was decided to support only UTC, or a 
local format easily convertible to UTC.



---[ Data Model 
]-------------------------------
------------------------
presenter: Jan Meijer
 [2] 
http://www.andrew.cmu.edu/~rdanyliw/in
ch/ietf57/ietf57-inch-dm.ppt


Meijer presented a review of the open issues related to the current data 
model in [2].


That said, the data model is beginning to stabilize.  There have been no 
substantial changes (or proposed changes) in the past 4-months. The 
remaining work is in:


  o migrating the current XML DTD implementation to Schema


  o addressing remaining issues with multi-lingual free-form text


  o examining and further enumerating certain enumerated attribute values


  o codifying the semantics of document updates, and making any 
appropriate data model changes that might be necessary
       - At a minimum this will require a careful examination of which 
fields are explicitly required (rather than optional)


  o fully integrating XML-Signature and XML-Encryption


  o confirming that all FINE requirements are being met


  o proof reading of the text


A new draft incorporating an initial implementation in XML Schema, and all 
current pending issues will be complete by September 2003. This draft will 
still include the DTD implementation to ease the transition.


Comments and Discussion:


  o Supporting multi-lingual free-form text remains an open issues.
    A thread on the particular details can be found 
at:<http://ni
c.surfnet.nl/scripts/wa.exe?A2=i
nd03&L=inch&F=&S=&P=13967>


  o The use of terms defined in the requirements document should be 
consistent with the data model document



---[ XML Security in the IODEF 
]----------------------------------------
presenter: Yuri Demchenko 
[3] 
http://www.andrew.cmu.edu/~rdanyliw/in
ch/ietf57/ietf57-inch-iodef-xmlschema.ppt


Demchenko provided a migration strategy for the data model to XML Schema in 
[3].


Comments and Discussion


  o Many suggestions to the data model were proposed in the 
presentation.  However, not all are explicitly required to make the 
transition to XML Schema.  Yuri was asked to separate the suggested 
changes from those explicitly required for the migration.


---[ Implementation Guide 
]---------------------------------------------
presenter: Roman Danyliw 
[4] 
http://www.andrew.cmu.edu/~rdanyliw/in
ch/ietf57/ietf57-inch-iguide.ppt


Danyliw presented an overview of the main topics to discuss in the 
implementation guide in [4].  No draft for this document exists, but an 
initial version should be complete by September 2003.


The following topics were suggested for inclusion in the draft:


  o examples of IDMEF messages included in an IODEF document


  o best practices in CSIRT data exchange protocols


  o an interoperability matrix, when a sufficient number of 
implementations are available

    Slides

    INCH Req
    Optimising XML Schema for IODEF Data model
    IODEF datamodel update
    IODEF Implementation Guide: