Expectations for Computer Security Incident Response
draft-ietf-grip-framework-irt-07
The information below is for an old version of the document that is already published as an RFC.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 2350.
|
|
---|---|---|---|
Authors | Erik Guttman , Nevil Brownlee | ||
Last updated | 2013-03-02 (Latest revision 1997-09-11) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | Best Current Practice | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | (None) | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 2350 (Best Current Practice) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-grip-framework-irt-07
Internet Engineering Task Force (IETF) H. Asaeda Request for Comments: 8487 NICT Category: Standards Track K. Meyer ISSN: 2070-1721 Dell EMC W. Lee, Ed. October 2018 Mtrace Version 2: Traceroute Facility for IP Multicast Abstract This document describes the IP multicast traceroute facility, named Mtrace version 2 (Mtrace2). Unlike unicast traceroute, Mtrace2 requires special implementations on the part of routers. This specification describes the required functionality in multicast routers, as well as how an Mtrace2 client invokes a Query and receives a Reply. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8487. Asaeda, et al. Standards Track [Page 1] understand the background and set-up of the CSIRT, and it is vital information for building trust between a constituent and a CSIRT. 3.3.4 Authority This section will vary greatly from one CSIRT to another, based on the relationship between the team and its constituency. While an organizational CSIRT will be given its authority by the management of the organization, a community CSIRT will be supported and chosen by the community, usually in a advisory role. A CSIRT may or may not have the authority to intervene in the operation of all of the systems within its perimeter. It should identify the scope of its control as distinct from the perimeter of its constituency. If other CSIRTs operate hierarchically within its perimeter, this should be mentioned here, and the related CSIRTs identified. Disclosure of a team's authority may expose it to claims of liability. Every team should seek legal advice on these matters. (See section 3.7 for more on liability.) 3.4 Policies It is critical that Incident Response Teams define their policies. The following sections discuss communication of these policies to the constituent community. 3.4.1 Types of Incidents and Level of Support The types of incident which the team is able to address, and the level of support which the team will offer when responding to each type of incident, should be summarized here in list form. The Services section (see below) provides the opportunity to give more detailed descriptions, and to address non-incident-related topics. The level of support may change depending on factors such as the team's workload and the completeness of the information available. Such factors should be outlined and their impact should be explained. As a list of known types of incidents will be incomplete with regard to possible or future incidents, a CSIRT should also give some background on the "default" support for incident types not otherwise mentioned. The team should state whether it will act on information it receives about vulnerabilities which create opportunities for future incidents. A commitment to act on such information on behalf of its constituency is regarded as an optional proactive service policy rather than a core service requirement for a CSIRT. Brownlee, Guttman Internet Draft [Page 10] Expectations for Computer Security Incident Response 11 September 97 3.4.2 Co-operation, Interaction and Disclosure of Information This section should make explicit which related groups the CSIRT routinely interacts with. Such interactions are not necessarily related to the computer security incident response provided, but are used to facilitate better cooperation on technical topics or services. By no means need details about cooperation agreements be given out; the main objective of this section is to give the constituency a basic understanding of what kind of interactions are established and what their purpose is. The reporting and disclosure policy should make clear who will be the recipients of a CSIRT's report in each circumstance. It should also note whether the team will expect to operate through another CSIRT or directly with a member of another constituency over matters specifically concerning that member. Important examples of related groups a CSIRT will interact with are listed below. Incident Response Teams: A CSIRT will often need to interact with other CSIRTs. For example a CSIRT within a large company may need to report incidents to a national CSIRT, and a national CSIRT may need to report incidents to national CSIRTs in other countries to deal with all sites involved in a large-scale attack. Collaboration between CSIRTs may lead to disclosure of information. The following are examples of such disclosure, but are not intended to be an exhaustive list: - Reporting incidents within the constituency to other teams. If this is done, site-related information may become public knowledge, accessible to everyone, in particular the press. - Handling incidents occurring within the constituency, but reported from outside it (which implies that some information has already been disclosed off-site). - Reporting observations from within the constituency indicating suspected or confirmed incidents outside it. - Acting on reports of incidents occurring outside the constituency. - Passing information about vulnerabilities to vendors, to partner CSIRTs or directly to affected sites lying within or outside the constituency. - Feedback to parties reporting incidents or vulnerabilities. Brownlee, Guttman Internet Draft [Page 11] Expectations for Computer Security Incident Response 11 September 97 - The provision of contact information relating to members of the constituency, members of other constituencies, other CSIRTs, or law-enforcement agencies. Vendors: Some vendors have their own CSIRTs, but some vendors may not. In such cases a CSIRT will need to work directly with a vendor to suggest improvements or modifications, to analyse the technical problem or to test provided solutions. Vendors play a special role in handling an incident if their products' vulnerabilities are involved in the incident. Law-enforcement agencies: These include the police and other investigative agencies. CSIRTs and users of the template should be sensitive to local laws and regulations, which may vary considerably in different countries. A CSIRT might advise on technical details of attacks or seek advice on the legal implications of an incident. Local laws and regulations may include specific reporting and confidentiality requirements. Press: A CSIRT may be approached by the press for information and comment from time to time. An explicit policy concerning disclosure to the press can be helpful, particularly in clarifying the expectations of a CSIRT's constituency. The press policy will have to clarify the same topics as above more specifically, as the constituency will usually be very sensitive to press contacts. Other: This might include research activities or the relation to the sponsoring organization. The default status of any and all security-related information which a team receives will usually be 'confidential,' but rigid adherence to this makes the team to appear to be an informational 'black hole,' which may reduce the likelihood of the team's obtaining cooperation from clients and from other organizations. The CSIRT's template should define what information it will report or disclose, to whom, and when. Different teams are likely to be subject to different legal restraints requiring or limiting disclosure, especially if they work in different jurisdictions. In addition, they may have reporting requirements imposed by their sponsoring organization. Each team's template should specify any such constraints, both to clarify users' expectations and to inform other teams. Conflicts of interest, particularly in commercial matters, may also restrain disclosure by a team; this document does not recommend on how such conflicts should be addressed. Brownlee, Guttman Internet Draft [Page 12] Expectations for Computer Security Incident Response 11 September 97 A team will normally collect statistics. If statistical information is distributed, the template's reporting and disclosure policy should say so, and should describe how to obtain such statistics. 3.4.3 Communication and Authentication You must have a policy which describes methods of secure and verifiable communication that you will use. This is necessary for communication between CSIRTs and between a CSIRT and its constituents. The template should include public keys or pointers to them, including key fingerprints, together with guidelines on how to use this information to check authenticity and how to deal with corrupted information (for example where to report this fact). At the moment it is recommended that as a minimum every CSIRT have (if possible), a PGP key available. A team may also make other mechanisms available (for example PEM, MOSS, S/MIME), according to its needs and the needs of its constituents. Note however, that CSIRTs and users should be sensitive to local laws and regulations. Some countries do not allow strong encryption, or enforce specific policies on the use of encryption technology. In addition to encrypting sensitive information whenever possible, correspondence should include digital signatures. (Please note that in most countries, the protection of authenticity by using digital signatures is not affected by existing encryption regulations.) For communication via telephone or facsimile a CSIRT may keep secret authentication data for parties with whom they may deal, such as an agreed password or phrase. Obviously, such secret keys must not be published, though their existence may be. 3.5 Services Services provided by a CSIRT can be roughly divided into two categories: real-time activities directly related to the main task of incident response, and non-real-time proactive activities, supportive of the incident response task. The second category and part of the first category consist of services which are optional in the sense that not all CSIRTs will offer them. 3.5.1 Incident Response Incident response usually includes assessing incoming reports about incidents ("Incident Triage") and following up on these with other CSIRTs, ISPs and sites ("Incident Coordination"). A third range of services, helping a local site to recover from an incident ("Incident Resolution"), is comprised of typically optional services, which not all CSIRTs will offer. Brownlee, Guttman Internet Draft [Page 13] Expectations for Computer Security Incident Response 11 September 97 3.5.1.1 Incident Triage Incident triage usually includes: - Report assessment Interpreting incoming incident reports, prioritizing them,and relating them to ongoing incidents and trends. - Verification Help in determining whether an incident has really occurred, and its scope. 3.5.1.2 Incident Coordination Incident Coordination normally includes: - Information categorization Categorization the incident related information (logfiles, contact information, etc.) with respect to the information disclosure policy. - Coordination Notification of other involved parties on a need-to-know basis, as per the information disclosure policy. 3.5.1.3 Incident Resolution Usually additional or optional, incident resolution services include: - Technical Assistance This may include analysis of compromised systems. - Eradication Elimination of the cause of a security incident (the vulnerability exploited), and its effects (for example, continuing access to the system by an intruder). - Recovery Aid in restoring affected systems and services to their status before the security incident. Brownlee, Guttman Internet Draft [Page 14] Expectations for Computer Security Incident Response 11 September 97 RFC 8487 Mtrace2 October 2018 Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Asaeda, et al. Standards Track [Page 2] RFC 8487 Mtrace2 October 2018 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 7 3. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Mtrace2 TLV Format . . . . . . . . . . . . . . . . . . . 9 3.2. Defined TLVs . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Mtrace2 Query . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Mtrace2 Request . . . . . . . . . . . . . . . . . . . 12 3.2.3. Mtrace2 Reply . . . . . . . . . . . . . . . . . . . . 12 3.2.4. IPv4 Mtrace2 Standard Response Block . . . . . . . . 13 3.2.5. IPv6 Mtrace2 Standard Response Block . . . . . . . . 18 3.2.6. Mtrace2 Augmented Response Block . . . . . . . . . . 20 3.2.7. Mtrace2 Extended Query Block . . . . . . . . . . . . 21 4. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 22 4.1. Receiving an Mtrace2 Query . . . . . . . . . . . . . . . 22 4.1.1. Query Packet Verification . . . . . . . . . . . . . . 22 4.1.2. Query Normal Processing . . . . . . . . . . . . . . . 23 4.2. Receiving an Mtrace2 Request . . . . . . . . . . . . . . 23 4.2.1. Request Packet Verification . . . . . . . . . . . . . 24 4.2.2. Request Normal Processing . . . . . . . . . . . . . . 24 4.3. Forwarding Mtrace2 Request . . . . . . . . . . . . . . . 26 4.3.1. Destination Address . . . . . . . . . . . . . . . . . 26 4.3.2. Source Address . . . . . . . . . . . . . . . . . . . 26 4.3.3. Appending Standard Response Block . . . . . . . . . . 26 4.4. Sending Mtrace2 Reply . . . . . . . . . . . . . . . . . . 27 4.4.1. Destination Address . . . . . . . . . . . . . . . . . 27 4.4.2. Source Address . . . . . . . . . . . . . . . . . . . 27 4.4.3. Appending Standard Response Block . . . . . . . . . . 27 4.5. Proxying Mtrace2 Query . . . . . . . . . . . . . . . . . 28 4.6. Hiding Information . . . . . . . . . . . . . . . . . . . 28 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 29 5.1. Sending Mtrace2 Query . . . . . . . . . . . . . . . . . . 29 5.1.1. Destination Address . . . . . . . . . . . . . . . . . 29 5.1.2. Source Address . . . . . . . . . . . . . . . . . . . 29 5.2. Determining the Path . . . . . . . . . . . . . . . . . . 29 5.3. Collecting Statistics . . . . . . . . . . . . . . . . . . 29 5.4. Last-Hop Router (LHR) . . . . . . . . . . . . . . . . . . 30 5.5. First-Hop Router (FHR) . . . . . . . . . . . . . . . . . 30 5.6. Broken Intermediate Router . . . . . . . . . . . . . . . 30 5.7. Non-supported Router . . . . . . . . . . . . . . . . . . 30 5.8. Mtrace2 Termination . . . . . . . . . . . . . . . . . . . 31 5.8.1. Arriving at Source . . . . . . . . . . . . . . . . . 31 5.8.2. Fatal Error . . . . . . . . . . . . . . . . . . . . . 31 5.8.3. No Upstream Router . . . . . . . . . . . . . . . . . 31 5.8.4. Reply Timeout . . . . . . . . . . . . . . . . . . . . 31 5.9. Continuing after an Error . . . . . . . . . . . . . . . . 31 Asaeda, et al. Standards Track [Page 3] RFC 8487 Mtrace2 October 2018 6. Protocol-Specific Considerations . . . . . . . . . . . . . . 32 6.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.2. Bidirectional PIM . . . . . . . . . . . . . . . . . . . . 32 6.3. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.4. IGMP/MLD Proxy . . . . . . . . . . . . . . . . . . . . . 33 7. Problem Diagnosis . . . . . . . . . . . . . . . . . . . . . . 33 7.1. Forwarding Inconsistencies . . . . . . . . . . . . . . . 33 7.2. TTL or Hop-Limit Problems . . . . . . . . . . . . . . . . 33 7.3. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 33 7.4. Link Utilization . . . . . . . . . . . . . . . . . . . . 34 7.5. Time Delay . . . . . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8.1. "Mtrace2 Forwarding Codes" Registry . . . . . . . . . . . 35 8.2. "Mtrace2 TLV Types" Registry . . . . . . . . . . . . . . 35 8.3. UDP Destination Port . . . . . . . . . . . . . . . . . . 35 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 9.1. Addresses in Mtrace2 Header . . . . . . . . . . . . . . . 35 9.2. Verification of Clients and Peers . . . . . . . . . . . . 35 9.3. Topology Discovery . . . . . . . . . . . . . . . . . . . 36 9.4. Characteristics of Multicast Channel . . . . . . . . . . 36 9.5. Limiting Query/Request Rates . . . . . . . . . . . . . . 37 9.6. Limiting Reply Rates . . . . . . . . . . . . . . . . . . 37 9.7. Specific Security Concerns . . . . . . . . . . . . . . . 37 9.7.1. Request and Response Bombardment . . . . . . . . . . 37 9.7.2. Amplification Attack . . . . . . . . . . . . . . . . 37 9.7.3. Leaking of Confidential Topology Details . . . . . . 38 9.7.4. Delivery of False Information (Forged Reply Messages) 38 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 10.1. Normative References . . . . . . . . . . . . . . . . . . 39 10.2. Informative References . . . . . . . . . . . . . . . . . 40 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Asaeda, et al. Standards Track [Page 4] RFC 8487 Mtrace2 October 2018 1. Introduction Given a multicast distribution tree, tracing hop-by-hop downstream from a multicast source to a given multicast receiver is difficult because there is no efficient and deterministic way to determine the branch of the multicast routing tree on which that receiver lies. On the other hand, walking up the tree from a receiver to a source is easy, as most existing multicast routing protocols know the upstream router for each source. Tracing from a receiver to a source can involve only the routers on the direct path. This document specifies the multicast traceroute facility named Mtrace version 2 or Mtrace2, which allows the tracing of an IP multicast routing path. Mtrace2 is usually initiated from an Mtrace2 client by sending an Mtrace2 Query to a Last-Hop Router (LHR) or to a Rendezvous Point (RP). The RP is a special router where sources and receivers meet in Protocol Independent Multicast - Sparse Mode (PIM-SM) [5]. From the LHR/RP receiving the Query, the tracing is directed towards a specified source if a source address is specified and a source-specific state exists on the receiving router. If no source address is specified or if no source-specific state exists on a receiving LHR, the tracing is directed toward the RP for the specified group address. Moreover, Mtrace2 provides additional information such as the packet rates and losses, as well as other diagnostic information. Mtrace2 is primarily intended for the following purposes: o To trace the path that a packet would take from a source to a receiver. o To isolate packet-loss problems (e.g., congestion). o To isolate configuration problems (e.g., Time to live (TTL) threshold). The following figure shows a typical case of how Mtrace2 is used. FHR represents the first-hop router, LHR represents the last-hop router, and the arrow lines represent the Mtrace2 messages that are sent from one node to another. The numbers before the Mtrace2 messages represent the sequence of the messages that would happen. The source, receiver, and Mtrace2 client are typically hosts. Asaeda, et al. Standards Track [Page 5] RFC 8487 Mtrace2 October 2018 2. Request 2. Request +----+ +----+ | | | | v | v | +--------+ +-----+ +-----+ +----------+ | Source |----| FHR |----- The Internet -----| LHR |----| Receiver | +--------+ +-----+ | +-----+ +----------+ \ | ^ \ | / \ | / \ | / 3. Reply \ | / 1. Query \ | / \ | / \ +---------+ / v | Mtrace2 |/ | Client | +---------+ When an Mtrace2 client initiates a multicast trace, it sends an Mtrace2 Query packet to an LHR or RP for a multicast group and, optionally, a source address. The LHR/RP turns the Query packet into a Request. The Request message type enables each of the upstream routers processing the message to apply different packet and message validation rules than those required for the handling of a Query message. The LHR/RP then appends a Standard Response Block containing its interface addresses and packet statistics to the Request packet, then forwards the packet towards the source/RP. The Request packet is either unicasted to its upstream router towards the source/RP or multicasted to the group if the upstream router's IP address is not known. In a similar fashion, each router along the path to the source/RP appends a Standard Response Block to the end of the Request packet before forwarding it to its upstream router. When the FHR receives the Request packet, it appends its own Standard Response Block, turns the Request packet into a Reply, and unicasts the Reply back to the Mtrace2 client. The Mtrace2 Reply may be returned before reaching the FHR under some circumstances. This can happen if a Request packet is received at an RP or gateway, or when any of several types of error or exception conditions occur that prevent the sending of a Request to the next upstream router. The Mtrace2 client waits for the Mtrace2 Reply message and displays the results. When not receiving an Mtrace2 Reply message due to network congestion, a broken router (see Section 5.6), or a non- responding router (see Section 5.7), the Mtrace2 client may resend another Mtrace2 Query with a lower hop count (see Section 3.2.1) and Asaeda, et al. Standards Track [Page 6] RFC 8487 Mtrace2 October 2018 repeat the process until it receives an Mtrace2 Reply message. The details are specific to the Mtrace2 client and outside the scope of this document. Note that when a router's control plane and forwarding plane are out of sync, the Mtrace2 Requests might be forwarded based on the control states instead. In this case, the traced path might not represent the real path the data packets would follow. Mtrace2 supports both IPv4 and IPv6. Unlike the previous version of Mtrace, which implements its query and response as Internet Group Management Protocol (IGMP) messages [10], all Mtrace2 messages are UDP based. Although the packet formats of IPv4 and IPv6 Mtrace2 are different because of the address families, the syntax between them is similar. This document describes the base specification of Mtrace2 that can serve as a basis for future proposals such as Mtrace2 for Automatic Multicast Tunneling (AMT) [16] and Mtrace2 for Multicast in MPLS/BGP IP VPNs (known as Multicast VPN (MVPN)) [15]. They are, therefore, out of the scope of this document. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL 3.5.2. Proactive Activities Usually additional or optional, proactive services might include: - Information provision This might include an archive of known vulnerabilities, patches or resolutions of past problems, or advisory mailing lists. - Security Tools This may include tools for auditing a Site's security. - Education and training - Product evaluation - Site security auditing and consulting 3.6 Incident Reporting Forms The use of reporting forms makes it simpler for both users and teams to deal with incidents. The constituent can prepare answers to various important questions before he or she actually contacts the team, and can therefore come well prepared. The team gets all the necessary information at once with the first report and can proceed efficiently. Depending on the objectives and services of a particular CSIRT, multiple forms may be used, for example a reporting form for a new vulnerability may be very different from the form used for reporting incidents. It is most efficient to provide forms through the online information services of the team. The exact pointers to them should be given in the CSIRT description document, together with statements about appropriate use, and guidelines for when and how to use the forms. If separate e-mail addresses are supported for form-based reporting, they should be listed here again. One example of such a form is the Incident Reporting Form provided by the CERT Coordination Center: - ftp://info.cert.org/incident_reporting_form 3.7 Disclaimers Although the CSIRT description document does not constitute a contract, liability may conceivably result from its descriptions of services and purposes. The inclusion of a disclaimer at the end of the template is therefore recommended and should warn the user about possible limitations. Brownlee, Guttman Internet Draft [Page 15] Expectations for Computer Security Incident Response 11 September 97 In situations where the original version of a document must be translated into another language, the translation should carry a disclaimer and a pointer to the original. For example: Although we tried to carefully translate the original document from German into English, we can not be certain that both documents express the same thoughts in the same level of detail and correctness. In all cases, where there is a difference between both versions, the German version will prevail. The use of and protection by disclaimers is affected by local laws and regulations, of which each CSIRT should be aware. If in doubt the CSIRT should check the disclaimer with a lawyer. Appendix A: Glossary of Terms This glossary defines terms used in describing security incidents and Computer Security Incident Response Teams. Only a limited list is included. For more definitions please refer to other sources, for example to the Internet User's Glossary [RFC 1983]. Constituency: Implicit in the purpose of a Computer Security Incident Response Team is the existence of a constituency. This is the group of users, sites, networks or organizations served by the team. The team must be recognized by its constituency in order to be effective. Security Incident: For the purpose of this document, this term is a synonym of Computer Security Incident: any adverse event which compromises some aspect of computer or network security. The definition of an incident may vary between organizations, but at least the following categories are generally applicable: - Loss of confidentiality of information. - Compromise of integrity of information. - Denial of service. - Misuse of service, systems or information. - Damage to systems. These are very general categories. For instance the replacement of a system utility program by a Trojan Horse is an example of 'compromise of integrity,' and a successful password attack is an example of 'loss of confidentiality.' Attacks, even if they failed because of proper protection, can be regarded as Incidents. Within the definition of an incident the word 'compromised' is Brownlee, Guttman Internet Draft [Page 16] Expectations for Computer Security Incident Response 11 September 97 used. Sometimes an administrator may only 'suspect' an incident. During the response it must be established whether or not an incident has really occurred. Computer Security Incident Response Team: Based on two of the definitions given above, a CSIRT is a team that coordinates and supports the response to security incidents that involve sites within a defined constituency. In order to be considered a CSIRT, a team must: - Provide a (secure) channel for receiving reports about suspected incidents. - Provide assistance to members of its constituency in handling these incidents. - Disseminate incident-related information to its constituency and to other involved parties. Note that we are not referring here to police or other law enforcement bodies which may investigate computer-related crime. CSIRT members, indeed, need not have any powers beyond those of ordinary citizens. Vendor: A 'vendor' is any entity that produces networking or computing technology, and is responsible for the technical content of that technology. Examples of 'technology' include hardware (desktop computers, routers, switches, etc.), and software (operating systems, mail forwarding systems, etc.). Note that the supplier of a technology is not necessarily the 'vendor' of that technology. As an example, an Internet Service Provider (ISP) might supply routers to each of its customers, but the 'vendor' is the manufacturer, since the manufacturer, rather than the ISP, is the entity responsible for the technical content of the router. Vulnerability: A 'vulnerability' is a characteristic of a piece of technology which can be exploited to perpetrate a security incident. For example, if a program unintentionally allowed ordinary users to execute arbitrary operating system commands in privileged mode, this "feature" would be a vulnerability. Brownlee, Guttman Internet Draft [Page 17] Expectations for Computer Security Incident Response 11 September 97 Appendix B: Related Material Important issues in responding to security incidents on a site level are contained in [RFC 1244], the Site Security Handbook, produced by the Site Security Handbook Working Group (SSH). This document will be updated by the SSH working group and will give recommendations for local policies and procedures, mainly related to the avoidance of security incidents. Other documents of interest for the discussion of CSIRTs and their tasks are available by anonymous FTP. A collection can be found on: - ftp://ftp.cert.dfn.de/pub/docs/csir/ Please refer to file 01-README for further information about the content of this directory. Some especially interesting documents in relation to this document are as follows: - ftp://ftp.nic.surfnet.nl/surfnet/net-security/cert-nl/docs/ reports/R-92-01 This report contains the Operational Framework of CERT-NL, the CSIRT of SURFnet (network provider in the Netherlands). - For readers interested in the operation of FIRST (Forum of Incident Response and Security Teams) more information is collected in Appendix C. - http://hightop.nrl.navy.mil/news/incident.html This document leads to the NRL Incident Response Manual. - http://www.cert.dfn.de/eng/team/kpk/certbib.html This document contains an annotated bibliography of available material, documents and files about the operation of CSIRTs with links to many of the referenced items. - ftp://info.cert.org/incident_reporting_form This Incident Reporting Form is provided by the CERT Coordination Center to gather incident information and to avoid additional delays caused by the need to request more detailed information from the reporting site. - http://www.cert.org/cert.faqintro.html A collection of frequently asked questions from the CERT Coordination Center. Brownlee, Guttman Internet Draft [Page 18] Expectations for Computer Security Incident Response 11 September 97 Appendix C: Known Computer Security Incident Response Teams Today, there are many different CSIRTs but no single source lists every team. Most of the major and long established teams (the first CSIRT was founded in 1988) are nowadays members of FIRST, the worldwide Forum of Incident Response and Security Teams. At the time of writing, more than 55 teams are members (1 in Australia, 13 in Europe, all others in North America). Information about FIRST can be found: - http://www.first.org/ The current list of members is available also, with the relevant contact information and some additional information provided by the particular teams: - http://www.first.org/team-info/ For CSIRTs which want to become members of this forum (please note that a team needs a sponsor - a team which is already a full member of FIRST - to be introduced), the following files contain more information: - http://www.first.org/about/op_frame.html The Operational Framework of FIRST. - http://www.first.org/docs/newmem.html Guidelines for teams which want to become members of FIRST. Many of the European teams, regardless of whether they are members of FIRST or not, are listed by countries on a page maintained by the German CSIRT: - http://www.cert.dfn.de/eng/csir/europe/certs.html To learn about existing teams suitable to one's needs it is often helpful to ask either known teams or an Internet Service Provider for the "right" contact. Brownlee, Guttman Internet Draft [Page 19] Expectations for Computer Security Incident Response 11 September 97 Appendix D: Outline for CSIRT Template This outline summarizes in point form the issues addressed in this document, and is the recommended template for a CSIRT description document. Its structure is designed to facilitate the communication of a CSIRT's policies, procedures, and other relevant information to its constituency and to outside organizations such as other CSIRTs. A 'filled-in' example of this template is given as Appendix E. 1. Document Information 1.1 Date of Last Update 1.2 Distribution List for Notifications 1.3 Locations where this Document May Be Found 2. Contact Information 2.1 Name of the Team 2.2 Address 2.3 Time Zone 2.4 Telephone Number 2.5 Facsimile Number 2.6 Other Telecommunication 2.7 Electronic Mail Address 2.8 Public Keys and Encryption Information 2.9 Team Members 2.10 Other Information 2.11 Points of Customer Contact 3. Charter 3.1 Mission Statement 3.2 Constituency 3.3 Sponsorship and/or Affiliation 3.4 Authority 4. Policies 4.1 Types of Incidents and Level of Support 4.2 Co-operation, Interaction and Disclosure of Information 4.3 Communication and Authentication 5. Services 5.1 Incident Response 5.1.1. Incident Triage 5.1.2. Incident Coordination 5.1.3. Incident Resolution 5.2 Proactive Activities 6. Incident Reporting Forms 7. Disclaimers Brownlee, Guttman Internet Draft [Page 20] Expectations for Computer Security Incident Response 11 September 97 Appendix E: Example - 'filled-in' Template for a CSIRT Below is an example of a filled-in template for a fictitious CSIRT called XYZ-CSIRT. This text is for example purposes only, and does not constitute endorsement by the working group or the IETF of any particular set of procedures or policies. While CSIRTs are welcome to use any or all of this text if they wish, such use is of course not mandatory, or even appropriate in most cases. CSIRT Description for XYZ-CERT ----------------------------- 1. About this document 1.1 Date of Last Update This is version 1.01, published 1997/03/31. 1.2 Distribution List for Notifications Notifications of updates are submitted to our mailing list <xyz-cert-info@xyz-univ.ca>. Subscription requests for this list should be sent to the Majordomo at <xyz-cert-info-request@xyz-univ.ca>; the body of the message should consist of the word "subscribe". Send the word "help" instead if you don't know how to use a Majordomo list manager. This mailing list is moderated. 1.3 Locations where this Document May Be Found The current version of this CSIRT description document is available from the XYZ-CERT WWW site; its URL is http://www.xyz-univ.ca/xyz-cert/english/CSIRT-descr.txt Une version francaise de ce document est igalement disponible: http://www.xyz-univ.ca/xyz-cert/francais/CSIRT-descr.txt Please make sure you are using the latest version. 1.4 Authenticating this Document Both the English and French versions of this document have been signed with the XYZ-CERT's PGP key. The signatures are also on our Web site, under: http://www.xyz-univ.ca/xyz-cert/english/CSIRT-descr.asc http://www.xyz-univ.ca/xyz-cert/francais/CSIRT-descr.asc 2. Contact Information 2.1 Name of the Team "XYZ-CERT": the XYZ University Computer Emergency Response Team. Brownlee, Guttman Internet Draft [Page 21] Expectations for Computer Security Incident Response 11 September 97 2.2 Address XYZ-CERT XYZ University, Computing Services Department 12345 Rue Principale UniversityTown, Quebec Canada H0H 0H0 2.3 Time Zone Canada/Eastern (GMT-0500, and GMT-0400 from April to October) 2.4 Telephone Number +1 234 567 7890 (ask for the XYZ-CERT) 2.5 Facsimile Number +1 234 567 7899 (this is *not* a secure fax) 2.6 Other Telecommunication None available. 2.7 Electronic Mail Address <xyz-cert@xyz-univ.ca> This is a mail alias that relays mail to the human(s) on duty for the XYZ-CERT. 2.8 Public Keys and Other Encryption Information The XYZ-CERT has a PGP key, whose KeyID is 12345678 and whose fingerprint is 11 22 33 44 55 66 77 88 88 77 66 55 44 33 22 11. The key and its signatures can be found at the usual large public keyservers. Because PGP is still a relatively new technology at XYZ University, this key still has relatively few signatures; efforts are underway to increase the number of links to this key in the PGP "web of trust". In the meantime, since most fellow universities in Quebec have at least one staff member who knows the XYZ-CERT coordinator Zoe Doe, Zoe Doe has signed the XYZ-CERT key, and will be happy to confirm its fingerprint and that of her own key to those people who know her, by telephone or in person. 2.9 Team Members Zoe Doe of Computing Services is the XYZ-CERT coordinator. Backup coordinators and other team members, along with their areas of expertise and contact information, are listed in the Brownlee, Guttman Internet Draft [Page 22] Expectations for Computer Security Incident Response 11 September 97 XYZ-CERT web pages, at http://www.xyz-univ.ca/xyz-cert/teamlist.html Management, liaison and supervision are provided by Steve Tree, Assistant Director (Technical Services), Computing Services. 2.10 Other Information General information about the XYZ-CERT, as well as links to various recommended security resources, can be found at http://www.xyz-univ.ca/xyz-cert/index.html 2.11 Points of Customer Contact The preferred method for contacting the XYZ-CERT is via e-mail at <xyz-cert@xyz-univ.ca>; e-mail sent to this address will "biff" the responsible human, or be automatically forwarded to the appropriate backup person, immediately. If you require urgent assistance, put "urgent" in your subject line. If it is not possible (or not advisable for security reasons) to use e-mail, the XYZ-CERT can be reached by telephone during regular office hours. Telephone messages are checked less often than e-mail. The XYZ-CERT's hours of operation are generally restricted to regular business hours (09:00-17:00 Monday to Friday except holidays). If possible, when submitting your report, use the form mentioned in section 6. 3. Charter 3.1 Mission Statement The purpose of the XYZ-CERT is, first, to assist members of XYZ University community in implementing proactive measures to reduce the risks of computer security incidents, and second, to assist XYZ community in responding to such incidents when they occur. 3.2 Constituency The XYZ-CERT's constituency is the XYZ University community, as defined in the context of the "XYZ University Policy on Computing Facilities". This policy is available at http://www-compserv.xyz-univ.ca/policies/pcf.html However, please note that, notwithtanding the above, XYZ-CERT services will be provided for on-site systems only. Brownlee, Guttman Internet Draft [Page 23] Expectations for Computer Security Incident Response 11 September 97 3.3 Sponsorship and/or Affiliation The XYZ-CERT is sponsored by the ACME Canadian Research Network. It maintains affiliations with various University CSIRTs throughout Canada and the USA on an as needed basis. 3.4 Authority The XYZ-CERT operates under the auspices of, and with authority delegated by, the Department of Computing Services of XYZ University. For further information on the mandate and authority of the Department of Computing Services, please refer to the XYZ University "Policy on Computing Facilities&" in this document are to be interpreted as described in BCP 14 [1] [7] when, and only when, they appear in all capitals, as shown here. The key words indicate requirement levels for compliant Mtrace2 implementations. 2.1. Definitions Since Mtrace2 Queries and Requests flow in the opposite direction to the data flow, we refer to "upstream" and "downstream" with respect to data, unless explicitly specified. Incoming Interface: The interface on which data is expected to arrive from the specified source and group. Outgoing Interface: This is one of the interfaces to which data from the source or RP is expected to be transmitted for the specified source and group. It is also the interface on which the Mtrace2 Request was received. Asaeda, et al. Standards Track [Page 7] RFC 8487 Mtrace2 October 2018 Upstream router: The router, connecting to the Incoming Interface of the current router, which is responsible for forwarding data for the specified source and group to the current router. First-Hop Router (FHR): The router that is directly connected to the source the Mtrace2 Query specifies. Last-Hop Router (LHR): A router that is directly connected to a receiver. It is also the router that receives the Mtrace2 Query from an Mtrace2 client. Group state: The state a shared-tree protocol, such as Protocol Independent Multicast - Sparse Mode (PIM-SM) [5], uses to choose the upstream router towards the RP for the specified group. In this state, source-specific state is not available for the corresponding group address on the router. Source-specific state: The state that is used to choose the path towards the source for the specified source and group. ALL-[protocol]-ROUTERS group: Link-local multicast address for multicast routers to communicate with their adjacent routers that are running the same routing protocol. For instance, the IPv4 'ALL-PIM-ROUTERS' group is '224.0.0.13', and the IPv6 'ALL-PIM-ROUTERS' group is 'ff02::d' [5]. 3. Packet Formats This section describes the details of the packet formats for Mtrace2 messages. All Mtrace2 messages are encoded in the Type/Length/Value (TLV) format (see Section 3.1). The first TLV of a message is a message header TLV specifying the type of message and additional context information required for processing of the message and for parsing of subsequent TLVs in the message. Subsequent TLVs in a message, referred to as Blocks, are appended after the header TLV to provide additional information associated with the message. If an implementation receives an unknown TLV Type for any TLV in a message, it SHOULD ignore and silently discard the entire packet. If the length of a TLV exceeds the available space in the containing packet, the implementation MUST ignore and silently discard the TLV and any remaining portion of the containing packet. Asaeda, et al. Standards Track [Page 8] RFC 8487 Mtrace2 October 2018 All Mtrace2 messages are UDP packets. For IPv4, Mtrace2 Query/Request/Reply messages MUST NOT be fragmented. Therefore, Mtrace2 clients and LHRs/RPs MUST set the IP header do-not-fragment (DF) bit for all Mtrace2 messages. For IPv6, the packet size for the Mtrace2 messages MUST NOT exceed 1280 bytes, which is the smallest Maximum Transmission Unit (MTU) for an IPv6 interface [8]. The source port is uniquely selected by the local host operating system. The destination port is the IANA-reserved Mtrace2 port number (see Section 8). All Mtrace2 messages MUST have a valid UDP checksum. Additionally, Mtrace2 supports both IPv4 and IPv6, but not when mixed. For example, if an Mtrace2 Query or Request message arrives as an IPv4 packet, all addresses specified in the Mtrace2 messages MUST be IPv4 as well. The same rule applies to IPv6 Mtrace2 messages. 3.1. Mtrace2 TLV Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 8 bits Describes the format of the Value field. For all the available types, please see Section 3.2. Length: 16 bits Length of Type, Length, and Value fields in octets. Minimum length required is 4 octets. The length MUST be a multiple of 4 octets. The maximum TLV length is not defined; however, the entire Mtrace2 packet length MUST NOT exceed the available MTU. Value: variable length The format is based on the Type value. The length of the Value field is the Length field minus 3. All reserved fields in the Value field MUST be transmitted as zeros and ignored on receipt. Asaeda, et al. Standards Track [Page 9] RFC 8487 Mtrace2 October 2018 3.2. Defined TLVs The following TLV Types are defined: Code Type ==== ================================ 0x00 Reserved 0x01 Mtrace2 Query 0x02 Mtrace2 Request 0x03 Mtrace2 Reply 0x04 Mtrace2 Standard Response Block 0x05 Mtrace2 Augmented Response Block 0x06 Mtrace2 Extended Query Block Each Mtrace2 message MUST begin with either a Query, a Request, or a Reply TLV. The first TLV determines the type of each Mtrace2 message. Following a Query TLV, there can be a sequence of optional Extended Query Blocks. In the case of a Request or a Reply TLV, it is then followed by a sequence of Standard Response Blocks, each from a multicast router on the path towards the source or the RP. In the case where more information is needed, a Standard Response Block can be followed by one or multiple Augmented Response Blocks. We will describe each message type in detail in the next few sections. 3.2.1. Mtrace2 Query An Mtrace2 Query is originated by an Mtrace2 client, which sends an Mtrace2 Query message to the LHR. The LHR modifies only the Type field of the Query TLV (to turn it into a "Request") before appending a Standard Response Block and forwarding it upstream. The LHR and intermediate routers handling the Mtrace2 message when tracing upstream MUST NOT modify any other fields within the Query/Request TLV. Additionally, intermediate routers handling the message after the LHR has converted the Query into a Request MUST NOT modify the Type field of the Request TLV. If the actual number of hops is not known, an Mtrace2 client could send an initial Query message with a large # Hops (e.g., 0xff), in order to try to trace the full path. Asaeda, et al. Standards Track [Page 10] RFC 8487 Mtrace2 October 2018 An Mtrace2 Query message is shown as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | # Hops | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Multicast Address | | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | Source Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Mtrace2 Client Address | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Query ID | Client Port # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length: 16 bits The Length field MUST be either 20 (i.e., 8 + 3 * 4 (IPv4 addresses)) or 56 (i.e., 8 + 3 * 16 (IPv6 addresses)); if the length is 20, then IPv4 addresses MUST be assumed, and if the length is 56, then IPv6 addresses MUST be assumed. # Hops: 8 bits This field specifies the maximum number of hops that the Mtrace2 client wants to trace. If there are some error conditions in the middle of the path that prevent an Mtrace2 Reply from being received by the client, the client MAY issue another Mtrace2 Query with a lower number of hops until it receives a Reply. Multicast Address: 32 bits or 128 bits This field specifies an IPv4 or IPv6 address, which can be either: m-1: a multicast group address to be traced or m-2: all ones in case of IPv4 or the unspecified address (::) in case of IPv6 if no group-specific information is desired. Asaeda, et al. Standards Track [Page 11] RFC 8487 Mtrace2 October 2018 Source Address: 32 bits or 128 bits This field specifies an IPv4 or IPv6 address, which can be either: s-1: a unicast address of the source to be traced or s-2: all ones in case of IPv4 or the unspecified address (::) in case of IPv6 if no source-specific information is desired. For example, the client is tracing a (*,g) group state. Note that it is invalid to have a source-group combination of (s-2, m-2). If a router receives such combination in an Mtrace2 Query, it MUST silently discard the Query. Mtrace2 Client Address: 32 bits or 128 bits This field specifies the Mtrace2 client's IPv4 address or IPv6 global address. This address MUST be a valid unicast address; therefore, it MUST NOT be all ones or an unspecified address. The Mtrace2 Reply will be sent to this address. Query ID: 16 bits This field is used as a unique identifier for this Mtrace2 Query so that duplicate or delayed Reply messages may be detected. Client Port #: 16 bits This field specifies the destination UDP port number for receiving the Mtrace2 Reply packet. 3.2.2. Mtrace2 Request The Mtrace2 Request TLV is exactly the same as an Mtrace2 Query except for identifying the Type field of 0x02. When an LHR receives an Mtrace2 Query message, it turns the Query into a Request by changing the Type field of the Query from 0x01 to 0x02. The LHR then appends an Mtrace2 Standard Response Block (see Section 3.2.4) of its own to the Request message before sending it upstream. The upstream routers do the same without changing the Type field until one of them is ready to send a Reply. 3.2.3. Mtrace2 Reply The Mtrace2 Reply TLV is exactly the same as an Mtrace2 Query except for identifying the Type field of 0x03. When an FHR or an RP receives an Mtrace2 Request message that is destined to itself, it appends an Mtrace2 Standard Response Block (see Section 3.2.4) of its own to the Request message. Next, it turns the Request message into a Reply by changing the Type field of Asaeda, et al. Standards Track [Page 12] RFC 8487 Mtrace2 October 2018 quot;, available at http://www-compserv.xyz-univ.ca/policies/pcf.html The XYZ-CERT expects to work cooperatively with system administrators and users at XYZ University, and, insofar as possible, to avoid authoritarian relationships. However, should circumstances warrant it, the XYZ-CERT will appeal to Computing Services to exert its authority, direct or indirect, as necessary. All members of the XYZ-CERT are members of the CCSA (Committee of Computer Systems Administrators), and have all of the powers and responsibilities assigned to Systems Administrators by the Policy on Computing Facilities, or are members of University management. Members of the XYZ University community who wish to appeal the actions of the XYZ-CERT should contact the Assistant Director (Technical Services), Computing Services. If this recourse is not satisfactory, the matter may be referred to the Director of Computing Services (in the case of perceived problems with existing policy), or to the XYZ University Office of Rights and Responsibilities (in the case of perceived errors in the application of existing policy). 4. Policies 4.1 Types of Incidents and Level of Support The XYZ-CERT is authorized to address all types of computer security incidents which occur, or threaten to occur, at XYZ University. The level of support given by XYZ-CERT will vary depending on the type and severity of the incident or issue, the type of constituent, the size of the user community affected, and the XYZ-CERT's resources at the time, though in all cases some response will be made within one working day. Resources will be assigned according to the following priorities, listed in decreasing order: Brownlee, Guttman Internet Draft [Page 24] Expectations for Computer Security Incident Response 11 September 97 - Threats to the physical safety of human beings. - Root or system-level attacks on any Management Information System, or any part of the backbone network infrastructure. - Root or system-level attacks on any large public service machine, either multi-user or dedicated-purpose. - Compromise of restricted confidential service accounts or software installations, in particular those used for MIS applications containing confidential data, or those used for system administration. - Denial of service attacks on any of the above three items. - Any of the above at other sites, originating from XYZ University. - Large-scale attacks of any kind, e.g. sniffing attacks, IRC "social engineering" attacks, password cracking attacks. - Threats, harrassment, and other criminal offenses involving individual user accounts. - Compromise of individual user accounts on multi-user systems. - Compromise of desktop systems. - Forgery and misrepresentation, and other security-related violations of local rules and regulations, e.g. netnews and e-mail forgery, unauthorized use of IRC bots. - Denial of service on individual user accounts, e.g. mailbombing. Types of incidents other than those mentioned above will be prioritized according to their apparent severity and extent. Note that no direct support will be given to end users; they are expected to contact their system administrator, network administrator, or department head for assistance. The XYZ-CERT will support the latter people. While the XYZ-CERT understands that there exists great variation in the level of system administrator expertise at XYZ University, and while the XYZ-CERT will endeavor to present information and assistance at a level appropriate to each person, the XYZ-CERT cannot train system administrators on the fly, and it cannot perform system maintenance on their behalf. In most cases, the XYZ-CERT will provide pointers to the information needed to implement appropriate measures. The XYZ-CERT is committed to keeping the XYZ University system administration community informed of potential vulnerabilities, and where possible, will inform this community of such vulnerabilities before they are actively exploited. 4.2 Co-operation, Interaction and Disclosure of Information While there are legal and ethical restrictions on the flow of information from XYZ-CERT, many of which are also outlined in Brownlee, Guttman Internet Draft [Page 25] Expectations for Computer Security Incident Response 11 September 97 the XYZ University Policy on Computing Facilities, and all of which will be respected, the XYZ-CERT acknowledges its indebtedness to, and declares its intention to contribute to, the spirit of cooperation that created the Internet. Therefore, while appropriate measures will be taken to protect the identity of members of our constituency and members of neighbouring sites where necessary, the XYZ-CERT will otherwise share information freely when this will assist others in resolving or preventing security incidents. In the paragraphs below, "affected parties" refers to the legitimate owners, operators, and users of the relevant computing facilities. It does not refer to unauthorized users, including otherwise authorized users making unauthorized use of a facility; such intruders may have no expectation of confidentiality from the XYZ-CERT. They may or may not have legal rights to confidentiality; such rights will of course be respected where they exist. Information being considered for release will be classified as follows: - Private user information is information about particular users, or in some cases, particular applications, which must be considered confidential for legal, contractual, and/or ethical reasons. Private user information will be not be released in identifiable form outside the XYZ-CERT, except as provided for below. If the identity of the user is disguised, then the information can be released freely (for example to show a sample .cshrc file as modified by an intruder, or to demonstrate a particular social engineering attack). - Intruder information is similar to private user information, but concerns intruders. While intruder information, and in particular identifying information, will not be released to the public (unless it becomes a matter of public record, for example because criminal charges have been laid), it will be exchanged freely with system administrators and CSIRTs tracking an incident. - Private site information is technical information about particular systems or sites. It will not be released without the permission of the site in question, except as provided for below. - Vulnerability information is technical information about vulnerabilities or attacks, including fixes and Brownlee, Guttman Internet Draft [Page 26] Expectations for Computer Security Incident Response 11 September 97 workarounds. Vulnerability information will be released freely, though every effort will be made to inform the relevant vendor before the general public is informed. - Embarrassing information includes the statement that an incident has occurred, and information about its extent or severity. Embarrassing information may concern a site or a particular user or group of users. Embarrassing information will not be released without the permission of the site or users in question, except as provided for below. - Statistical information is embarrassing information with the identifying information stripped off. Statistical information will be released at the discretion of the Computing Services Department. - Contact information explains how to reach system administrators and CSIRTs. Contact information will be released freely, except where the contact person or entity has requested that this not be the case, or where XYZ-CERT has reason to believe that the dissemination of this information would not be appreciated. Potential recipients of information from the XYZ-CERT will be classified as follows: - Because of the nature of their responsibilities and consequent expectations of confidentiality, members of XYZ University management are entitled to receive whatever information is necessary to facilitate the handling of computer security incidents which occur in their jurisdictions. - Members of the Office of Rights and Responsibilities are entitled to receive whatever information they request concerning a computer security incident or related matter which has been referred to them for resolution. The same is true for the XYZ Security Department, when its assistance in an investigation has been enlisted, or when the investigation has been instigated at its request. - System administrators at XYZ University who are members of the CCSA are also, by virtue of their responsibilities, trusted with confidential information. However, unless such people are also members of XYZ-CERT, they will be given only Brownlee, Guttman Internet Draft [Page 27] Expectations for Computer Security Incident Response 11 September 97 that confidential information which they must have in order to assist with an investigation, or in order to secure their own systems. - Users at XYZ University are entitled to information which pertains to the security of their own computer accounts, even if this means revealing "intruder information", or "embarrasssing information" about another user. For example, if account aaaa is cracked and the intruder attacks account bbbb, user bbbb is entitled to know that aaaa was cracked, and how the attack on the bbbb account was executed. User bbbb is also entitled, if she or he requests it, to information about account aaaa which might enable bbbb to investigate the attack. For example, if bbbb was attacked by someone remotely connected to aaaa, bbbb should be told the provenance of the connections to aaaa, even though this information would ordinarily be considered private to aaaa. Users at XYZ University are entitled to be notified if their account is believed to have been compromised. - The XYZ University community will receive no restricted information, except where the affected parties have given permission for the information to be disseminated. Statistical information may be made available to the general XYZ community. There is no obligation on the part of the XYZ-CERT to report incidents to the community, though it may choose to do so; in particular, it is likely that the XYZ-CERT will inform all affected parties of the ways in which they were affected, or will encourage the affected site to do so. - The public at large will receive no restricted information. In fact, no particular effort will be made to communicate with the public at large, though the XYZ-CERT recognizes that, for all intents and purposes, information made available to the XYZ University community is in effect made available to the community at large, and will tailor the information in consequence. - The computer security community will be treated the same way the general public is treated. While members of XYZ-CERT may participate in discussions within the computer security community, such as newsgroups, mailing lists (including the full-disclosure list "bugtraq"), and conferences, they will treat such forums as though they were the public at large. While technical issues (including vulnerabilities) may be discussed to any level of detail, any examples taken from XYZ-CERT experience will be disguised to avoid identifying the affected parties. Brownlee, Guttman Internet Draft [Page 28] Expectations for Computer Security Incident Response 11 September 97 - The press will also be considered as part of the general public. The XYZ-CERT will not interact directly with the Press concerning computer security incidents, except to point them toward information already released to the general public. If necessary, information will be provided to the XYZ University Public Relations Department, and to the Customer Relations group of the Computing Services Department. All incident-related queries will be referred to these two bodies. The above does not affect the ability of members of XYZ-CERT to grant interviews on general computer security topics; in fact, they are encouraged to do to, as a public service to the community. - Other sites and CSIRTs, when they are partners in the investigation of a computer security incident, will in some cases be trusted with confidential information. This will happen only if the foreign site's bona fide can be verified, and the information transmitted will be limited to that which is likely to be helpful in resolving the incident. Such information sharing is most likely to happen in the case of sites well known to XYZ-CERT (for example, several other Quebec universities have informal but well-established working relationships with XYZ University in such mattters). For the purposes of resolving a security incident, otherwise semi-private but relatively harmless user information such as the provenance of connections to user accounts will not be considered highly sensitive, and can be transmitted to a foreign site without excessive precautions. "Intruder information" will be transmitted freely to other system administrators and CSIRTs. "Embarrassing information" can be transmitted when there is reasonable assurance that it will remain confidential, and when it is necessary to resolve an incident. - Vendors will be considered as foreign CSIRTs for most intents and purposes. The XYZ-CERT wishes to encourage vendors of all kinds of networking and computer equipment, software, and services to improve the security of their products. In aid of this, a vulnerability discovered in such a product will be reported to its vendor, along with all technical details needed to identify and fix the problem. Identifying details will not be given to the vendor without the permission of the affected parties. - Law enforcement officers will receive full cooperation from the XYZ-CERT, including any information they require to pursue an investigation, in accordance with the Policy on Computing Facilities. Brownlee, Guttman Internet Draft [Page 29] Expectations for Computer Security Incident Response 11 September 97 4.3 Communication and Authentication In view of the types of information that the XYZ-CERT will likely be dealing with, telephones will be considered sufficiently secure to be used even unencrypted. Unencrypted e-mail will not be considered particularly secure, but will be sufficient for the transmission of low-sensitivity data. If it is necessary to send highly sensitive data by e-mail, PGP will be used. Network file transfers will be considered to be similar to e-mail for these purposes: sensitive data should be encrypted for transmission. Where it is necessary to establish trust, for example before relying on information given to the XYZ-CERT, or before disclosing confidential information, the identity and bona fide of the other party will be ascertained to a reasonable degree of trust. Within XYZ University, and with known neighbor sites, referrals from known trusted people will suffice to identify someone. Otherwise, appropriate methods will be used, such as a search of FIRST members, the use of WHOIS and other Internet registration information, etc, along with telephone call-back or e-mail mail-back to ensure that the party is not an impostor. Incoming e-mail whose data must be trusted will be checked with the originator personally, or by means of digital signatures (PGP in particular is supported). 5. Services 5.1 Incident Response XYZ-CERT will assist system administrators in handling the technical and organizational aspects of incidents. In particular, it will provide assistance or advice with respect to the following aspects of incident management: 5.1.1 Incident Triage - Investigating whether indeed an incident occured. - Determining the extent of the incident. 5.1.2 Incident Coordination - Determining the initial cause of the incident (vulnerability exploited). - Facilitating contact with other sites which may be involved. - Facilitating contact with XYZ University Security and/or appropriate law enforcement officials, if necessary. - Making reports to other CSIRTs. - Composing announcements to users, if applicable. Brownlee, Guttman Internet Draft [Page 30] Expectations for Computer Security Incident Response 11 September 97 5.1.3 Incident Resolution - Removing the vulnerability. - Securing the system from the effects of the incident. - Evaluating whether certain actions are likely to reap results in proportion to their cost and risk, in particular those actions aimed at an eventual prosecution or disciplinary action: collection of evidence after the fact, observation of an incident in progress, setting traps for intruders, etc. - Collecting evidence where criminal prosecution, or University disciplinary action, is contemplated. In addition, XYZ-CERT will collect statistics concerning incidents which occur within or involve the XYZ University community, and will notify the community as necessary to assist it in protecting against known attacks. To make use of XYZ-CERT's incident response services, please send e-mail as per section 2.11 above. Please remember that the amount of assistance available will vary according to the parameters described in section 4.1. 5.2 Proactive Activities The XYZ-CERT coordinates and maintains the following services to the extent possible depending on its resources: - Information services - List of departmental security contacts, administrative and technical. These lists will be available to the general public, via commonly-available channels such as the World Wide Web and/or the Domain Name Service. - Mailing lists to inform security contacts of new information relevant to their computing environments. These lists will be available only to XYZ University system administrators. - Repository of vendor-provided and other security-related patches for various operating systems. This repository will be available to the general public wherever license restrictions allow it, and will be provided via commonly-available channels such as the World Wide Web and/or ftp. - Repository of security tools and documentation for use by sysadmins. Where possible, precompiled ready-to-install versions will be supplied. These will be supplied to the general public via www or ftp as above. - "Clipping" service for various existing resources, such as major mailing lists and newsgroups. The resulting clippings will be made available either on the restricted mailing list or on the web site, depending on their sensitivity and urgency. Brownlee, Guttman Internet Draft [Page 31] Expectations for Computer Security Incident Response 11 September 97 - Training services - Members of the XYZ-CERT will give periodic seminars on computer security related topics; these seminars will be open to XYZ University system administrators. - Auditing services - Central file integrity checking service for Unix machines, and for any other platforms capable of running "tripwire". - Security level assignments; machines and subnetworks at XYZ University will be audited and assigned a security level. This security level information will be available to the XYZ University community, to facilitate the setting of appropriate access privileges. However, details of the security analyses will be confidential, and available only to the concerned parties. - Archiving services - Central logging service for machines capable of Unix-style remote logging. Incoming log entries will be watched by an automated log analysis program, and events or trends indicative of a potential security problem will be reported to the affected system administrators. - Records of security incidents handled will be kept. While the records will remain confidential, periodic statistical reports will be made available to the XYZ University community. Detailed descriptions of the above services, along with instructions for joining mailing lists, downloading information, or participating in certain services such as the central logging and file integrity checking services, are available on the XYZ-CERT web site, as per section 2.10 above. 6. Incident Reporting Forms There are no local forms developed yet for reporting incidents to XYZ-CERT. If possible, please make use of the Incident Reporting Form of the CERT Coordination Center (Pittsburgh, PA). The current version is available from: ftp://info.cert.org/incident_reporting_form 7. Disclaimers While every precaution will be taken in the preparation of information, notifications and alerts, XYZ-CERT assumes no responsibility for errors or omissions, or for damages resulting from the use of the information contained within. Brownlee, Guttman Internet Draft [Page 32] Expectations for Computer Security Incident Response 11 September 97 4 Acknowlegements The editors gratefully acknowledge the contributed material and editorial scrutiny of Anne Bennett. Thanks also to Don Stikvoort for assistance reworking the description of Incident Response Team services. 5 References [RFC 1244] P. Holbrooks, J. Reynolds / Site Security Handbook. - July 23, 1991. - 101 pages. - FYI 8. [RFC 1983] G. Malkin / Internet Users' Glossary. - August 16, 1996. - 62 pages. - FYI 18. 6 Security Considerations This document discusses the operation of Computer Security Incident Response Teams, and the teams' interactions with their constituencies and with other organizations. It is, therefore, not directly concerned with the security of protocols, applications, or network systems themselves. It is not even concerned with particular responses and reactions to security incidents, but only with the appropriate description of the responses provided by CSIRTs. Nonetheless, it is vital that the CSIRTs themselves operate securely, which means that they must establish secure communication channels with other teams, and with members of their constituency. They must also secure their own systems and infrastructure, to protect the interests of their constituency and to maintain the confidentiality of the identity of victims and reporters of security incidents. 7 Authors' Addresses Nevil Brownlee Erik Guttman ITSS Technology Development Sun Microsystems, Inc. The University of Auckland Bahnstr. 2 74915 Waibstadt Germany Phone: +64 9 373 7599 x8941 E-mail: n.brownlee@auckland.ac.nz Phone: +49 7263 911484 E-Mail: Erik.Guttman@sun.com This document expires March 11, 1998. Brownlee, Guttman Internet Draft [Page 33]