INCH Working Group Yuri Demchenko Internet Draft University of Amsterdam Category: Informational Hiroyuki Ohno WIDE Project Expires: April 24, 2004 Glenn M Keeni Cyber Solutions Inc. October 25, 2004 Requirements for Format for INcident information Exchange (FINE) Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, or will be disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. 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 obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html" This document is a product of the inch Working Group. Comments should be addressed to the authors or the mailing list at inch@ietf.org This Internet-Draft will expire on April 24, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Expires: April 24, 2005 [Page 1] Internet Draft October 25, 2004 Abstract 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 in the exchange of Incident related information across organizations, regions and countries. This document describes the requirements for an Incident Report Exchange Format. Table of Contents 1. Introduction ............................................... 3 2. Incident Handling Framework ................................ 3 3. General Requirements ....................................... 7 4. Format Requirements ........................................ 7 5. Communication Mechanism Requirements ....................... 9 6. Content Requirements ....................................... 9 7. Security Considerations .................................... 11 8. IANA Considerations ........................................ 11 9. References ................................................. 11 10. Acknowledgements ........................................... 12 11. Authors' Addresses ......................................... 12 Full Copyright Statement ....................................... 13 Expires: April 24, 2005 [Page 2] Internet Draft October 25, 2004 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. Definition of a common well defined format for Incident Reports will facilitate incident related information exchange across organizations, regions and countries by achieving these particular goals: + to make the semantics of the report as clear and unambiguous as possible, intended for use across organizational, regional and national boundaries; + to ensure that the report (or parts of it) has a well defined syntax; + to ensure that the structure of the report allows easy categorization and statistical analysis; + to ensure the verifiability of the integrity of the report, and the authenticity of the report source. This document defines the high-level functional requirements of a Format for INcident report Exchange (FINE). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. Incident Handling Framework 2.1. Incident Description Terms For the purpose of clarity, certain commonly used terms from the operational domain of CSIRTs are defined here. These are based on related documents [7, 8, 9, 10, 11] 2.1.1. Attack One or more steps taken by an attacker to achieve an unauthorised Expires: April 24, 2005 [Page 3] Internet Draft October 25, 2004 result. An Attack can be active or passive[8]. An attack may be successful. 2.1.2. Attacker An attacker is an entity that attempts one or more attacks. An attacker may be an insider acting from within the target network or organization, an outsider acting from outside the target network or organization, or an entity acting via an attack mediator. For the purpose of FINE, an attacker is described by the computer/network ID, from which the attack was launched. The organization name and/or physical location of the computer/network are used as additional information. 2.1.3. CSIRT CSIRT (Computer Security Incident Response Team) is a team that coordinates and supports the response to security incidents that involve sites within a defined constituency [7]. The CSIRT generates, processes and maintains incident reports. 2.1.4. Damage The intended or unintended consequence of an attack. Description of damage may include a free text description of the actual result of an attack, and where possible, structured information about the particular damaged system, subsystem or service. 2.1.5. Event An occurrence in a system or network, which maybe of interest and/or warrants attention. An event may indicate an attack. An event may also indicate an error, a fault, or be the result of a deliberate act that is not an attack. For example, the occurrence of three failed logins in 10 seconds is an event. It might indicate a brute-force login attack. A program failure, network fault, and system shutdown are other examples of an event. 2.1.6. Impact Impact describes the result of an attack expressed in terms of user community, for example the cost in terms of financial or other disruption. Expires: April 24, 2005 [Page 4] Internet Draft October 25, 2004 2.1.7. Computer/Network Security Incident A Computer/Network Security Incident, referred to as incident in this work, is a set of one or more events. The events in the incident may indicate attacks. There may also be incidents which comprise of events which are not indicative of attacks. Typical computer security incidents are- computer intrusion, denial- of-service attack, information theft, data manipulation, etc. 2.1.8. Incident Report In this document an Incident Report refers to the information pertaining to an incident. In practice, an Incident Report may have some internal proprietary format that is adapted to the local Incident Handling System (IHS) and Incident handling procedures. Definition of the requirements to the format for Incident Report exchange is the subject of this document. 2.1.9. Source The source of an attack. This can be a logical entity (e.g. a user account, a computer process or data, a logical network or internetwork) or a physical entity (e.g. a computer interface, a router etc.). 2.1.10. Target The target of an attack. This can be a logical entity( e.g. a user account, a computer process or data, a logical network or internetwork) or a physical entity, e.g. (a computer interface, a router etc.) 2.1.11. Victim The entity which suffered the attack. For the purpose of FINE a victim is described by its network identifier (ID), organization and location information. 2.1.12. Other terms Other terms used: alert, activity, Intrusion Detection System (IDS), Expires: April 24, 2005 [Page 5] Internet Draft October 25, 2004 Security Policy, etc., are defined in related I-Ds, RFCs, standards and documents[2, 3, 6, 7, 8, 9, 10]. 2.2 The Operational Model 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 from customers or from other CSIRTs. The CSIRTs maintain these reports. They may process the reports to generate statistics, or investigate the 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 Incidents from other CSIRTs. These operations are shown in fig. 1 +----- CSIRT | +---------------------+ | | | | | +--------+ | | | | | | | | | | | Incident Report | | |Incident|<---------|<----------------->| Customers/ | |ReportDB| | | CSIRTs/ | | | |<=== FINE ===>| Collaborators/ | | | | | Involved parties | | | | | | +--------+ | | | | | | | | | | | | | | +---------------------+ +----- Fig. 1 Operational Model for FINE From the operational point of view during the life-cycle of an Incident Report the following may apply: + the report itself evolves. It may exist in one of the following states: - handling the Incident Report is being handled Expires: April 24, 2005 [Page 6] Internet Draft October 25, 2004 - complete/closed - the Incident Report is not being processed and no processing is planned - waiting - the Incident Report is waiting on some event; + the report is exchanged between CSIRTs and may be investigated/processed by multiple CSIRTs, simultaneously; + additions and/or changes to the report may be effected by one or more CSIRTs. So a single CSIRT may not be in a position to vouch for the veracity of all parts of the Incident Report, 3. General Requirements 3.1 The definition of the Format for INcident Report Exchange (FINE) shall reference and use previously published RFCs where possible. 4. Format Requirements 4.1 FINE shall support full internationalization and localization. A significant part of the Incident Report will comprise of human- readable text. Since some Incidents need involvement of CSIRTs from different countries and geographic regions, FINE must have provisions so that the Incident Report can be presented in the local language in accordance with local rules and conventions. FINE must have provisions to specify the naming rules and conventions that have been applied in the Incident Report. In cases where the messages contain text strings and names that need characters other than Latin-1 (or ISO 8859-1), the information should preferably 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. In cases where local (non-standard) character sets and encodings are used, the elements that carry encoding sensitive information should be clearly indicated. It should be possible to preserve the content of these elements when transferring an Incident Report. 4.2 FINE must support aggregation and filtering of Incident Report data. The format of FINE must be structured with components that have a well-defined syntax and semantics. 4.3 FINE must provide the possibility for recording the evolution of Expires: April 24, 2005 [Page 7] Internet Draft October 25, 2004 an Incident Report during its lifetime. An Incident Report may evolve with time. As investigation proceeds, it is likely that more information about an incident will be revealed and parts of the earlier information will be modified/deleted. FINE must support the recording of these changes. 4.4 FINE must support the application of an access restriction policy to individual components of the Incident Report. 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. It must be possible to specify the degree of confidentiality for the individual components of the Incident Report. Applications can then implement different levels of access restrictions for the different components of the Incident Report. 4.5 FINE must support globally unique identifiers for the exchanged Incident reports. It should be possible to refer to an Incident Report unambiguously using the globally unique identifier. It should also be possible to map the origin/creator of an Incident Report from its globally unique identifier. 4.6. FINE must have a well defined semantics and provide a standard way for extensibility in terms of addition of components and/or extending the components. 4.7. FINE must allow multilingual reports. In case there are multiple language versions of a component of the report, the versions should be consistent and FINE must provide a way to identify which version is authentic. An 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 of the report may be in a different language and the versions may not be consistent. Expires: April 24, 2005 [Page 8] Internet Draft October 25, 2004 5. Communication Mechanism Requirements 5.1 The communication mechanisms must have no bearing on the authenticity, integrity, and confidentiality of a FINE formatted Incident Report. Provisions for authenticity, integrity and confidentiality should be made in FINE. Incident Report exchange will normally be conducted using standard communication protocols and exchange mechanisms, for example, e-mail, HTTP, FTP, XML Web Services, etc. FINE must not rely on communication mechanisms or specific applications to ensure authenticity, integrity and/or confidentiality of an Incident Report. 6. Content Requirements 6.1 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. 6.2 FINE must contain information about the various entities involved in the incident. An Incident Report will generally refer to one or more entities. The entity may be the attacker, perpetrator, victim, or an observer. 6.3 FINE should support the description of various aspects/details of the entities involved in the incident. There may be 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 names, person names, machine names etc. 6.4 FINE should contain the description of the method by which the attack or security event was conducted, if known. Well-known classification/enumeration schemes should be used to describe the type of attack, vulnerabilities, and exposures which caused the particular Incident or security event. 6.5 FINE must include the identity of the creator of the Incident Report (CSIRT or other authority). FINE should indicate the source of each component of the Incident Report if is different from the creator. The source of a component of the Incident Report may be the creator of the Incident Report, the team handling the incident or, some other Expires: April 24, 2005 [Page 9] Internet Draft October 25, 2004 party. 6.6 FINE should provide the possibility to include or reference additional detailed information/data external to report. This information may include IDMEF [5] messages, which have been generated by security devices. 6.7 FINE may contain a natural language description of the Incident or related security events. 6.8 FINE should contain references to the appropriate advisories, wherever applicable, corresponding to the related events , e.g. CERT/CC, CVE, etc. 6.9 FINE should provide the possibility for describing the impact of an incident. There should be guidelines to describe the impact on the target and intermediate parties affected to ensure a uniform interpretation of the description. 6.10 FINE should support the description the actions taken since the occurrence of the incident. 6.11 FINE should support the time specification as the local time and time zone offset from UTC. (Note: See RFC 2578 [12] for guidelines on reporting time.) Internal Incident Report may contain local presentation of time related information, however FINE must support unambiguous time specification. 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. time-stamped log data), the time offset should be mentioned. 6.12 FINE will not have any specific requirement for granularity of time. Different systems will support different time granularities. FINE should be able to support Incident Reports from various systems irrespective of their time granularity. 6.13 FINE should allow the application of external mechanisms to support authenticity, integrity, and non-repudiation checks of Incident Reports. Expires: April 24, 2005 [Page 10] Internet Draft October 25, 2004 7. 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 e.g. the information that the account of user A on the server B was compromised reveals information about user A. FINE implementers should take care to analyze and implement the requirements regarding access restriction policy as stated in 4.4 and requirements regarding support of external mechanisms for authenticity, integrity and non-repudiation 6.13. 8. IANA Considerations This document has no actions for IANA. 9. References 9.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 9.2 Informative References [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 Expires: April 24, 2005 [Page 11] Internet Draft October 25, 2004 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 National Laboratories - http://www.cert.org/research/taxonomy_988667.pdf [12] K. McCloghrie, D. Perkins, J. Schoenwaelder, Structure of Management Information Version 2 (SMIv2). K., RFC 2578, April 1999. 10. Acknowledgments. The precursor of this document is "RFC3067 TERENA's Incident Object Description Exchange Format Requirements" [2] which is based on the work done at Incident Object Description Exchange Format Working Group at TERENA. Subsequent work and discussion have been carried out in the INCH-WG and in the WIDE-WG on Network Management and Security. [ List of contributors ] 11. Authors' Addresses: Yuri Demchenko University of Amsterdam, The Netherlands Email: demch@chello.nl Hiroyuki Ohno WIDE Project, Japan Email: hohno@wide.ad.jp Glenn Mansfield Keeni Cyber Solutions Inc. Sendai, Japan Expires: April 24, 2005 [Page 12] Internet Draft October 25, 2004 Email: glenn@cysols.com Expires: April 24, 2005 [Page 13] Internet Draft October 25, 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Expires: April 24, 2005 [Page 14] Internet Draft October 25, 2004 Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Expires: April 24, 2005 [Page 15] Internet Draft October 25, 2004 Appendix - non-normative. Major Changes (reverse count) Information about changes to the document since publishing -00 version will be documented here. Major changes in version -03 1) editorial nits 2) in Security Considerations section an example is added to explain the impact of the contents of the IR on the security and privacy of individuals of organization. 3) Section 3 is deleted Major changes in version -02 1) clarified definitions of some terms. Added a few definitions. 2) in 5.1, added requirement for handling non-standard/local encoding and/or character codes. 3) in 5.7, added requirement that multiple versions of the report should be consistent 4) in 7.5, added requirement that the source of each component of the Incident Report must be identified (if different from the creator of the Incident Report). 5) some editorial nits are fixed. Major changes in version -01 1) clarified definition of some terms - still in the process, needs more discussion with concerned parties. 2) re-written section 2. Operational model 3) added text about multilingual support for non-utf-8 character sets to item "5.1 FINE shall support full internationalization and localization" - results of discussion at IETF-56 4) included clear statement about unique identification of the Incident Report to item "5.1 FINE shall support full internationalization and localization." 5) added item about the possibility of Incident description in natural language: 7.7 The FINE may contain a description of the Incident or comprising Expires: April 24, 2005 [Page 16] Internet Draft October 25, 2004 security events in a natural language. 6) requirement about describing impact of the Incident extended (item 7.9) with recommendation to provide guidelines to describe the impact on the target to ensure a uniform interpretation of the description. 7) item 7.11 about time normalization extended with the possibility to describe time offset when normalization is not possible. Expires: April 24, 2005 [Page 17]