Requirements for Format for INcident data Exchange (FINE) draft-ietf-inch-requirements-00.txt

Requirements for Format for INcident data Exchange

(FINE) draft-ietf-inch-requirements-00.txt

INCH WG, IETF56

March 19, 2003

Yuri Demchenko <[email protected]>

Glenn Mansfield Keeni <[email protected]>

©2000. Yu.Demchenko. TERENA Incident object Description and Exchange Format

Slide2_2

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


Slide2_3

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


Slide2_4

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 Goal4. General Requirements5. Format Requirements6. Communication Requirements7. Content Requirements8. Security Considerations

Is section on requirements to IHS or processing environment needed?


Slide2_5

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.


Slide2_6

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


Slide2_7

2.1 Incident Description Terms

• Incident

• Event

• Attack

• Attacker

• Evidence

• Target

• Victim

• Damage• Impact

• CSIRT• Incident Report • Incident Handling System

• Other terms: • alert, activity, IDS, Security Policy, etc.


Slide2_8

Incident and Security Event

2.1.8 IncidentAn 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.


Slide2_9

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.


Slide2_10

Attacker -> Actor

2.1.2 AttackerAttacker 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


Slide2_11

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


Slide2_12

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.


Slide2_13

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.


Slide2_14

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 draft-ietf-inch-requirements-00.txt


Slide2_15

4. General Requirements

4.1 The definition of the Format for INcident Report Exchange (FINE) shall reference and use previously published RFCs where possible.


Slide2_16

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.


Slide2_17

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 non-native (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.


Slide2_18

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.


Slide2_19

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.


Slide2_20

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.


Slide2_21

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.


Slide2_22


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


Slide2_23


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.


Slide2_24


7.13 The Incident Report should allow application of (external) mechanisms or assertions to assure its authenticity, integrity and non-repudiation 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)


Slide2_25

Any other issues

Requirements for Format for INcident data Exchange (FINE) draft-ietf-inch-requirements-00.txt

Documents

Transcript of Requirements for Format for INcident data Exchange (FINE) draft-ietf-inch-requirements-00.txt