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

1. 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>

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 Incident object Description and Exchange Format

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 Incident object Description and Exchange Format

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

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 archivingIncident 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. Incident object Description and Exchange Format

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 Incident object Description and Exchange Format

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. Incident object Description and Exchange Format

8. 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. Incident object Description and Exchange Format

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. Incident object Description and Exchange Format

10. 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 Incident object Description and Exchange Format

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 Incident object Description and Exchange Format

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. Incident object Description and Exchange Format

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. Incident object Description and Exchange Format

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 Incident object Description and Exchange Format

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. Incident object Description and Exchange Format

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. Incident object Description and Exchange Format

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. Incident object Description and Exchange Format

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. Incident object Description and Exchange Format

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. Incident object Description and Exchange Format

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. Incident object Description and Exchange Format

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. Incident object Description and Exchange Format

22. 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 Incident object Description and Exchange Format

23. 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. Incident object Description and Exchange Format

24. 7. Contents Requirements - Continue • 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) Incident object Description and Exchange Format

25. Any other issues Incident object Description and Exchange Format