Requirements for Format for
INcident data Exchange (FINE)
draft-ietf-inch-requirements-00.txt
INCH WG, IETF56
March 19, 2003
Yuri Demchenko <demch@nlnetlabs.nl>
Glenn Mansfield Keeni <glenn@cysols.com>
Outlines







Issues to discuss: Summary of discussion on INCH mailing list
Terminology
FINE purpose and Operational model
General requirements
Communication requirements
Format requirements
Security issues
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_2
Summary of INCH List discussion - Issues to discuss
 Name of the format: IODEF vs FINE
 Purpose of the format

Plus description/data object vs message
 Operational model
 Terminology
 Incident information aggregation

In particular, to preserve information for statistical purposes
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_3
FINE Requirements - draft-ietf-inch-requirements-00.txt
1. Introduction
2. Incident Handling Framework
2.1. Incident Description Terms
2.2 The Operational Model
3. The Goal
4. General Requirements
5. Format Requirements
6. Communication Requirements
7. Content Requirements
8. Security Considerations
Is section on requirements to IHS or processing environment
needed?
Incident object Description and Exchange Format
©2000. Yu.Demchenko. TERENA
Slide2_4
FINE/IODEF Purpose
The purpose of the Format for INcident report Exchange (FINE) is to
facilitate the exchange of incident information and statistics among
responsible Computer Security Incident Response Teams
(CSIRTs) and involved parties for reactionary analysis of current
intruder activity and proactive identification of trends that can lead
to incident prevention.
Old: A common and well-defined format will help in exchanging,
retrieving and archiving Incident Reports across organizations,
regions and countries.
New: A common and well defined format will help in exchanging
information about incident information across organizations,
regions and countries.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_5
IODEF Purpose (historical – 2000-2002)
A uniform incident classification enables applications such as:
 uniform statistic generation and exchange, for both domestic use and exchange
of data between teams. Over time a distributed incident statistics infrastructure
can evolve
 trend-analyses for reoccurrence of incidents, victims, attackers, etc.
 trend-analyses for relations between scans and attacks and thus begin working
on pro-active incident response
 uniform internal incident storage
 incident handling between teams made easier (only one team needs to classify
and analyze the complete incident, the other team can re-use this data)
 uniform incident reporting by victims to CSIRTs
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_6
2.1 Incident Description Terms
• Incident
• Event
• Damage
• Impact
•
•
•
•
•
• CSIRT
• Incident Report
• Incident Handling System
Attack
Attacker
Evidence
Target
Victim
• Other terms:
• alert, activity, IDS, Security Policy, etc.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_7
Incident and Security Event
2.1.8 Incident
An Incident is a security event that involves a security violation. An
incident can be defined as a single attack or a group of attacks that
can be distinguished from other attacks by the method of attack,
identity of attackers, victims, sites, objectives or timing, etc.
In the context of FINE, the term Incident is used to mean a Computer
Security Incident or an IT Security Incident.
2.1.5. Event
An action directed at a target which is intended to result in a change of
state (status) of the target. From the point of view of event origination,
it can be defined as any observable occurrence in a system or
network which resulted in an alert being generated. For example,
three failed logins in 10 seconds might indicate a brute- force login
attack.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_8
Attack
2.1.1. Attack
An assault on system security that derives from an intelligent threat, i.e.,
an intelligent act that is a deliberate attempt (especially in the sense
of a method or technique) to evade security services and violate the
security policy of a system.
Attack can be active or passive, by insider or by outsider, or via attack
mediator.
Proposed:
Attack can be active, resulting in the alteration of data, or passive, resulting in
the release of data, by an actor.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_9
Attacker -> Actor
2.1.2 Attacker
Attacker is individual who attempts one or more attacks in order to
achieve an objective(s).
For the purpose of FINE attacker is described by its network ID,
organisation which network/computer attack was originated and
physical location information (optional).
New:
2.1.2 Actor
Actor can be defined as who or what may violate the security requirements
(confidentiality, integrity, availability) of an asset. Actors can be from inside
or outside the organization.
Sort out between Actor, Attacker and Victim
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_10
Impact + Damage -> Impact
2.1.4. Damage: An intended or unintended consequence of an attack
which affects the normal operation of the targeted system or service.
Description of damage may include free text description of actual
result of attack, and, where possible, structured information about the
particular damaged system, subsystem or service.
2.1.7. Impact: Impact describes result of attack expressed in terms of
user community, for example the cost in terms of financial or other
disruption
Recommended to combine Damage and Impact into the term "Impact",
which is what is being described by the current term "damage".
Impact can be extensible and may be defined with terms such as
financial, asset, information, organization, etc.
INCH Meeting recommendation – Impact and Damage are different
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_11
Incident Report
2.1.9. Incident Report:
Document describing in details Incident processed by CSIRT. We
distinguish general definition of Incident report that is created and
handled by CSIRT and may have internal proprietary format adopted
to local Incident handling procedures or defined by used Incident
Handling System, and Format for INcident report Exchange (FINE)
used for exchange of Incident information between CSIRTs. Definition
of the requirements to FINE is a subject of this document.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_12
Incident Handling System
2.1.10. Incident Handling System:
Incident Handling System (IHS) is used by CSIRT to handle Incidents. It
may include user interface, underlying database and may be
integrated with ticketing or customer service system. During Incident
investigation CSIRT may use specific tools, e.g. for examining log
files, mapping network addresses to Internet names and
organisations, etc., which also may be integrated into IHS. In current
document, it is suggested that IHS can produce a document in FINE.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_13
2.2 Operational model
Where is a place for internal (report/data) format and where is a place for
intended exchange format?
See ASCII picture in
©2000. Yu.Demchenko. TERENA
draft-ietf-inch-requirements-00.txt
Incident object Description and Exchange Format
Slide2_14
4. General Requirements
4.1 The definition of the Format for INcident Report Exchange (FINE)
shall reference and use previously published RFCs where possible.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_15
5. Format Requirements - i18n and l10n (5.1)
5.1 FINE shall support full internationalization and localization.
A significant part of the FINE will comprise of human-readable text.
Since some Incidents need involvement of CSIRTs from different
countries, cultural and geographic regions, the FINE description must
be formatted such that they can be presented to an operator in a local
language and adhering to local presentation formats and local naming
rules and conventions. Localized presentation of dates, time and
names may also be required.
In case, if used, the format must be able to identify the rules or
conventions that is used in the naming.
In cases where the messages contain text strings and names that need
characters other than Latin-1 (or ISO 8859-1), the information
preferably should be represented using the ISO/IEC IS 10646-1
character set and encoded using the UTF-8 transformation format,
and optionally using local character sets and encodings.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_16
5. Format Requirements - i18n and l10n (5.1)
In case when Incident information/data is received by party that may not
correctly display and process other encoding than UTF-8, or information is
exchanged between parties that priory known may not process correctly nonnative (but other than UTF-8) encoding, the elements that can carry
encoding sensitive information should marked with the special attribute
and/or necessary transformation should be applied. Use of this attribute can
initiated by sending party, or re-sending party that want to preserve specific
content.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_17
5. Format Requirements - Continue
5.2 FINE must support modularity in Incident description to allow
aggregation and filtering of data.
The structure will contain several components and some components
may be structures themselves. Each component of a structure will
have a well defined semantics.
5.3 FINE must provide the possibility for recording the evolution of
Incident Report during its whole lifetime. In particular, FINE should
contain the record of all communications that happened in course of
current Incident.
5.4 FINE must support the application of an access restriction policy to
individual components.
5.5 An FINE report must be globally uniquely identifiable.
5.6. The Format for Incident report Exchange itself must be extensible.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_18
6. Communications Mechanisms Requirements
6.1. Incident Report exchange will normally be initiated by humans using
standard communication protocols and exchange mechanisms, for
example, e-mail, HTTP, XML Web Services, FTP, etc.
FINE must not rely on communication mechanisms to satisfy
requirements of current document.
The communication mechanisms must have no bearing on the
authenticity, integrity, and confidentiality of the Incident Report itself.
Communications security requirements may be applied separately
according to local policy so are not defined by this document.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_19
7. Contents Requirements
7.1 An Incident Report will generally refer to one or more entities. The
entity may be an attacker, a victim or an observer. There are several
facets of an entity involved in an Incident Report. The entity may have
zero or more network addresses and names as well as zero or more
location names, organizational name, person names, machine names
etc. FINE should support various facets describing the entities
involved.
7.2 The Incident Report should contain the type of the attack if it's
known.
7.3 FINE must include the Identity of the creator (or current owner) of the
Incident Report (CSIRT or other authority). This may be the sender in
an information exchange or the team currently handling the incident.
7.4 The FINE should contain information about the attacker and victim, if
known.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_20
7. Contents Requirements - Continue
7.5 The FINE should contain reference to advisories corresponding to
the Incident Report, e.g. CERT/CC, CVE, and others.
7.6 The FINE should contain a detailed description of the attack that
caused the current Incident. In particular, FINE should contain
information about Attacker’s and Victim’s systems participated or
targeted in that Attack.
7.7 The FINE may contain a description of the incident in a natural
language.
7.8 The Incident Report should contain or be able to reference additional
detailed information/data related to this specific underlying
event(s)/activity, often referred as evidence.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_21
7. Contents Requirements - Continue
7.1a or 5.2a
Format for Incident information exchange should allow Incident
information aggregation (for different purposes, in particular for
statistics and risk Assessment). Rules for such aggregation should be
well defined and documented for particular implementation.
More discussion is necessary
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_22
7. Contents Requirements - Continue
7.11 Time shall be reported as the local time and time zone offset from
UTC. (Note: See RFC 1902 for guidelines on reporting time.)
Internal Incident Report may contain local presentation of time related
information, however FINE must provide unambiguous time
presentation. For event correlation purposes, it is important that the
manager be able to normalize the time information reported in the
FINE descriptions. In case when normalization of the time information
is not possible (like in case of referencing additional data about the
Incident that cannot be changed, e.g. timestamped log data), the time
offset should be mentioned.
7.12 Time granularity in FINE time parameters shall not be specified by
the FINE.
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_23
7. Contents Requirements - Continue
7.13 The Incident Report should allow application of (external)
mechanisms or assertions to assure its authenticity, integrity and nonrepudiation can be verified.
------
 Suggested use of the general XML security technology – may
be applied to any (set of) part of the document
XML Signature
 XML Encryption

 SAML (Security Assertion ML) for including AuthN/AuthZ
tokens
 XML Web Services Security for possible needs to maintain
FINE/IODEF Document status (including also security
tokens)
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_24
Any other issues
©2000. Yu.Demchenko. TERENA
Incident object Description and Exchange Format
Slide2_25