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