One document matched: draft-ietf-inch-requirements-00.txt
Network Working Group Yuri Demchenko
INTERNET DRAFT NLnet Labs
Category: Informational Hiroyuki Ohno
WIDE Project
Expires August 2003 Glenn M Keeni
Cyber Solutions Inc.
February, 2003
Requirements for Format for INcident Report Exchange (FINE)
<draft-ietf-inch-requirements-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsolete by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstracts
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. A common and well-defined format will help in
exchanging, retrieving and archiving Incident Reports across
organizations, regions and countries.
[Page 1]
INTERNET DRAFT FINE Requirements February, 2003
This document describes the requirements for an Incident Report
Exchange Format.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Table of Contents
1. Introduction ............................................... 2
2. Incident Handling Framework ................................ 2
3. The Goal ................................................... 7
4. General Requirements ....................................... 8
5. Format Requirements ........................................ 8
6. Communication Requirements ................................. 9
7. Content Requirements ....................................... 9
8. Security Considerations .................................... 11
9. Acknowledgements ........................................... 12
10. References ................................................. 12
11. Authors' Addresses ......................................... 13
Full Copyright Statement ....................................... 13
1. Introduction
Computer security incidents occur across administrative domains
often spanning different organizations and national borders.
Therefore, the 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.
In the following we refer to the information pertaining to an
incident as an Incident Report. Actually Incident Report created and
handled by CSIRT may have internal proprietary format that is
adopted to local Incident handling procedure and used Incident
Handling System (IHS). It is intended that exchange of Incident
information will be conducted in a common format referred in this
document as Format for INcident report Exchange (FINE).
This document defines the high-level functional requirements to the
FINE intended to facilitate collaboration between CSIRTs and parties
involved when handling computer security incidents.
2. Incident Handling Framework
2.1. Incident Description Terms
Expires August 2003 [Page 2]
INTERNET DRAFT FINE Requirements February, 2003
A definition of the main terms used in the rest of document is given
for clarity.
Where possible, existing definitions will be used; some definitions
will need additional detail and further consideration. Currently
proposed definitions are based on well-known in the CSIRT community
documents [7, 8, 9, 10].
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.
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).
2.1.3. CSIRT
CSIRT (Computer Security Incident Response Team) is used in FINE to
refer to the authority handling the Incident and creating Incident
Report. The CSIRT is also likely to be involved in evidence
collection and custody, incident remedy, etc.
In FINE CSIRT represented by its ID, constituency, public key, etc.
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.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.
Expires August 2003 [Page 3]
INTERNET DRAFT FINE Requirements February, 2003
2.1.6. Evidence
Evidence is information relating to an event that proves or supports
a conclusion about the event. With respect to security incidents (the
events), it may include but is not limited to: data dump created by
Intrusion Detection System (IDS), data from syslog file, kernel
statistics, cache, memory, temporary file system, or other data that
caused the alert or were collected after the incident happened.
Special rules and care must be taken when storing and archiving
evidence, particularly to preserve its integrity. When necessary
evidence should be stored encrypted.
According to the Guidelines for Evidence Collection and Archiving [6]
evidence must be strictly secured. The chain of evidence custody
needs to be clearly documented.
It is essential that evidence should be collected, archived and
preserved according to local legislation.
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
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.
However we should distinguish between the generic definition of
'Incident' which is an event that might lead to damage or damage
which is not too serious, and 'Security Incident' or 'IT Security
Incident' which are defined below:
a) Security incident is an event that involves a security violation.
This may be an event that violates a security policy, AUP, laws and
jurisdictions, etc. A security incident may also be an incident that
has been escalated to a security incident.
A security incident is worse than an incident as it affects the
security of or in the organisation. A security incident may be
logical, physical or organisational, for example a computer
intrusion, loss of secrecy, information theft, fire or an alarm that
doesn't work properly. A security incident may be caused on purpose
Expires August 2003 [Page 4]
INTERNET DRAFT FINE Requirements February, 2003
or by accident. The latter may be if somebody forgets to lock a door
or forgets to activate an access list in a router.
b) An IT security incident is defined according to [9] as any real or
suspected adverse event in relation to the security of a computer or
computer network. Typical security incidents within the IT area are:
a computer intrusion, a denial-of-service attack, information theft
or data manipulation, etc.
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.
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.
2.1.11. Target
A computer or network logical entity (account, process or data) or
physical entity (component, computer, network or internetwork).
2.1.12. Victim
Victim is individual or organisation which suffered the attack which
is described in incident report.
For the purpose of FINE victim is described by its network ID,
organisation and location information.
2.1.13. Other terms
Other terms used: alert, activity, IDS, Security Policy, etc., - are
defined in related I-Ds, RFCs and standards [2, 3, 6, 7, 8, 9, 10].
2.2 The Operational Model
Expires August 2003 [Page 5]
INTERNET DRAFT FINE Requirements February, 2003
Incident Reports are generated, received and updated. For example,
An organization may send an Incident Report to a CSIRT when an
attack has been detected. Computer Security Incident Response Teams
(CSIRTs) receive Incident Reports via different channels including
Incident reports from constituency or customers, or from other
CSIRTs. The CSIRTs maintain these reports. They may process the
reports to generate statistics, or investigate Incident further. As
part of the investigation, or as part of the reporting the CSIRT may
forward the Incident Report or parts of it to other CSIRTs. The
CSIRTs may also receive results of investigation, or additional
information related to currently active Incident from other CSIRTs.
These operations are shown in fig. 1
From the operational point of view during the whole life-cycle of an
Incident Report:
+ the report itself evolves;
+ the report is exchanged between CSIRT and can be
investigated/processed by few CSIRTs at the same moment;
+ the changes in the report may be effected by one or more CSIRTs
+ a single CSIRT may not be in a position to vouch for the veracity
of all parts of the Incident Report
+ the Incident Report may exist in several states:
- complete/closed - the Incident Report is not being processed and
no processing is planned
- waiting - the Incident Report is waiting on some event, in
particular case, a response from one or more CSIRTs
Also, due to the nature of the operations:
+ the various parts of an Incident Report will have information of
varying degrees of sensitivity and will need to be handled with
the appropriate level of confidentiality.
+ the Incident Report may be multilingual i.e. different parts of
the Incident Report may use different languages. It is also
possible that multiple versions of parts of the report exist,
each version in a different language. The versions may not be
consistent.
It is essential to distinguish between internal Incident Report
processing procedures and respectfully requirements to internal
Incident Report format and Incident Report participating in
information exchange between CSIRTs for different purposes, whether
itÆs aimed for cooperative investigation, specific information or
action request, or just for information or statistics, and therefore
complying to FINE.
Incident
Database <--------- Incident Reports
(Local) (in internal format)
| ^
| | FINE
| | (Exchange Format)
Expires August 2003 [Page 6]
INTERNET DRAFT FINE Requirements February, 2003
| | |
v | v
Initial Incident | Internal Incident
Incident ---> Handling | Incident ---> Exchange
Report System | Report Gateway
| (IHS) | Format (FINE)
| ^ | | | ^
| | | | |
| | | | |
| | v | |
+---------- CSIRT | | FINE
(Triage/ | | (Exchange
Operator) | | Format)
^ | |
| v |
| Other CSIRTs
+-------------------> (other parties)
Other forms of
Information
Exchange
Fig. 1 Operational Model of an Incident Handling Procedure
Initial Incident Report may be based on information or request
received from the constituency/victim, Network Operation Center,
other CSIRTs or in a form of Alert from automated Intrusion
Detection System. It should be noted that there is a generic
difference between "Alerts" generated by IDS (as defined in
Intrusion Description and Exchange Format (IDMEF) [5] and Incident
Reports. The IDMEF Alerts are generated by "sensors" and processed
by managers (applications). On the other hand the Incident reports
will be created by human beings (although with the support of
automated IHS) and will also be finally consumed primarily by human
beings.
3. The Goal
The purpose of the Format for INcident Report Exchange (FINE) is to
facilitate the exchange of incident information and statistics among
involved parties and Computer Security Incident Response Teams
(CSIRTs) for reactionary analysis of current security incidents and
proactive identification of trends that can lead to incident
prevention. A common and well-defined format for Incident Reports
will help in exchanging, retrieving and archiving Incident Reports
across organizations, regions and countries.
There is need to
+ to make its semantics as clear and unambiguous as possible even
across regional and national boundaries;
+ to have a well defined syntax (at least for parts of it);
+ to enable categorization and statistical analysis;
Expires August 2003 [Page 7]
INTERNET DRAFT FINE Requirements February, 2003
+ to make it possible to ensure integrity of the message, and the
authenticity of the message source.
4. General Requirements
4.1 The definition of the Format for INcident Report Exchange (FINE)
shall reference and use previously published RFCs where possible.
5. Format Requirements
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.
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.
An Incident Report may evolve with time. As investigation proceeds
more
information about an incident may be revealed and parts of the
earlier information will be refined/obsolete. The Format for
Incident report Exchange should be able to support the record of the
evolution of the Incident Report with the level of details defined
internal/adopted Incident Handling procedure Appropriate timestamps
identifying the epochs in the lifetime of an Incident Report should
be also possible/applied.
5.4 FINE must support the application of an access restriction
policy to individual components.
Expires August 2003 [Page 8]
INTERNET DRAFT FINE Requirements February, 2003
An Incident Report may potentially contain sensitive or private
information (such as passwords, persons/organisations identifiers or
forensic information (evidence data)) and in some cases may be
exposed to non-authorised persons. It must be possible to define the
degree of confidentiality for the individual components of the
Incident Report and for different roles and parties involved.
Such situations may arise particularly in case of Incident
information exchange between CSIRTs or other involved bodies.
Technical realization may include using special restriction
attributes or general external technology available with
implementation format, which can be applied by Incident Handling
System. Some cases may be addressed by encrypting FINE elements,
however this will not always be possible. Therefore, to prevent
accidental disclosure of sensitive data, parts of the FINE object
must be marked with access restriction attributes. These markings
will be particularly useful when used with automated processing
systems
5.5 An FINE report must be globally uniquely identifiable.
It should be possible to map the origin/creator of an Incident
Report from its globally unique identifier.
5.6. The Format for Incident report Exchange itself must be
extensible. The extension will be in terms of addition of components
and/or extending the components.
6. Communication 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.
7. Content Requirements
FINE must be flexible enough to support various degrees of
completeness. At the same time it must clearly state the minimal
information without which the information in the Incident Report
will be seriously degraded.
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
Expires August 2003 [Page 9]
INTERNET DRAFT FINE Requirements February, 2003
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.
FINE must support well-known classification/enumeration schemes. It
is expected that this type will be drawn from a standardized list of
events/attacks; a new type of event may use a temporary
implementation- specific type if the event type has not yet been
standardized.
Incident handling may involve many different staff members and
teams. It is therefore essential that common terms are used to
describe incidents. If the event type has not yet been standardized,
temporary type definition might be given by team created Incident
Report. It is expected that new type name will be self-explanatory
and derived from a similar, existing type definition.
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.
The identity of Incident description creator is often valuable
information for Incident response. In one possible scenario the
attack may progress through the network, comparison of corresponding
incidents reported by different authorities might provide some
additional information about the origin of the attack. This is also
useful information at post-incident information handling/exchange
stage.
7.4 The FINE should contain information about the attacker and
victim, if known.
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.
Expires August 2003 [Page 10]
INTERNET DRAFT FINE Requirements February, 2003
This information may include IDMEF [5] messages, which have been
generated by security devices.
7.9 The Incident Report should describe the Impact on the target, if
known.
There should be guidelines to describe the impact on the target
to ensure a uniform interpretation of the description.
The value of this field should be drawn from a standardized list of
values if the attack is recognized as known, or expressed in a free
language by responsible CSIRT team member.
7.10 The Incident Report should describe the actions taken since the
occurrence of the incidence.
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.
The time data may be included into FINE description by existing
information systems, retrieved from incident reporting messages or
taken from IDS data or other event registration tools. Each of
these cases may have its own different time granularity. For the
purposes of implementation, it should be possible to handle time at
different stages according to the local system capabilities.
7.13 The Incident Report should allow application of (external)
mechanisms or assertions to assure its authenticity, integrity and
non-repudiation can be verified.
7.14 The semantics of FINE must be well defined. The various
components of FINE should have a well defined semantics.
8. Security Considerations
This memo does not describe a protocol by itself. This memo
describes the requirements for an Incident Report Exchange Format.
The reports themselves are about security incidents. The contents of
the Incident Reports will have significant direct and/or indirect
impact on the security and privacy of a network and/or individuals.
Expires August 2003 [Page 11]
INTERNET DRAFT FINE Requirements February, 2003
FINE implementers should take care to analyze and implement the
requirements stated in 5.5 and 7.12.
9. Acknowledgments.
The precursor of this document is "TERENAÆs Incident Object
Description Exchange Format Requirements" [RFC3067] which is based
on the work done at Incident Object Description Exchange Format
Working Group at TERENA. Subsequent work and discussion has been
carried out in the INCH-WG and in the WIDE-WG on Network Management
and Security.
10. References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[2] Arvidsson, J., Cormack, A., Demchenko, Y., Meijer J. "TERENA's
Incident Object Description and Exchange Format Requirements", RFC
3067, February 2001
[3] Incident Object Description and Exchange Format Data Model and
Extensible Markup Language (XML) Document Type Definition û October
2002. Work in progress.
[4] Taxonomy of the Computer Security Incident related terminology
- http://www.terena.nl/task-forces/tf-csirt/iiodef/docs/i-
taxonomy_terms.html
[5] Intrusion Detection Exchange Format Requirements by Wood, M. -
October 2002, Work in Progress.
[6] Guidelines for Evidence Collection and Archiving by Dominique
Brezinski, Tom Killalea û BCP 55, RFC 3227, February 2002.
[7] Brownlee, N. and E. Guttman, "Expectations for Computer Security
Incident Response", BCP 21, RFC 2350, June 1998.
[8] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May
2000.
[9] Establishing a Computer Security Incident Response Capability
(CSIRC). NIST Special Publication 800-3, November, 1991
[10] Handbook for Computer Security Incident Response Teams
(CSIRTs), Moira J. West-Brown, Don Stikvoort, Klaus-Peter
Kossakowski. - CMU/SEI-98-HB-001. - Pittsburgh, PA: Carnegie Mellon
University, 1998.
[11] A Common Language for Computer Security Incidents by John D.
Howard and Thomas A. Longstaff. - Sandia Report: SAND98-8667, Sandia
Expires August 2003 [Page 12]
INTERNET DRAFT FINE Requirements February, 2003
National Laboratories -
http://www.cert.org/research/taxonomy_988667.pdf
11. AuthorsÆ Addresses:
Yuri Demchenko
NLnet Labs
Email: demch@chello.nl
Hiroyuki Ohno
WIDE Project, Japan
Email: hohno@wide.ad.jp
Glenn Mansfield Keeni
Cyber Solutions Inc.
Sendai, Japan
Email: glenn@cysols.com
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Expires August 2003 [Page 13]
INTERNET DRAFT FINE Requirements February, 2003
Appendix û non-normative
Major Changes (reverse count)
Expires August 2003 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-24 01:30:32 |