Internet Draft T. Hansen
draft-ietf-grip-user-00.txtdraft-ietf-grip-user-01.txt AT&T Laboratories Valid for six months T. Killalea Verio NorthwestJanuary 31, 1999 Security Expectations for Internet Service Provider Consumers <draft-ietf-grip-user-00.txt><draft-ietf-grip-user-01.txt> Author's version: 1.51.7 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. This memo and its companions are discussed on the GRIP working group mailing list, grip-wg[-request]@uu.net. Copyright Notice Copyright (C) The Internet Society (1998).(1999). All Rights Reserved. Abstract The purpose of this document is to provide information to the gen- eral Internet community regarding security expectations of Internet Ser- vice Providers (ISPs). It is not the intent of this document to define a set of require- ments that would be appropriate for all ISPs, but rather to provide the community with a framework for discussion of security expectations with current and prospective service providers. This document is written from the perspective of the consumer. Companion documents provide information from the ISP perspective. 1. Introduction The purpose of this document, and its companions [RFCisp] and [RFCsshadd], is to express the general Internet community's expectations of Internet Service Providers (ISPs) with respect to security. A goal is that customers could have a framework to facilitate the discussion of security with prospective service providers; regrettably, such a discussion rarely takes place today. Additionally, in informing ISPs of what the community hopes and expects of them, a further goal is to encourage ISPs to become proactive in making security not only a priority, but something to which they point with pride when selling their services. This document is addressed to Internet service purchasing decision-makers (customers). It has been argued that vendors begin to care about security only when prompted by customers. We hope that these documents will encourage both parties to more readily express how much they care about security, and that discussion between the community and its ISPs will be increased. Three types of customers are considered in this document: first connectivity customers, then hosting customers, and finally co-located customers. 1.1. Conventions Used in this Document The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119]. 2. Incident Response A Security Incident Response Team (SIRT) is a team that performs, coordinates, and supports the response to security incidents that involve sites within a defined constituency. The Internet community's expectations of SIRTs are described in [BCP21]. 2.1. ISPs and Security Incident Response Teams Some ISPs have Security Incident Response Teams (SIRTs). However it should not be assumed that either the ISP's connectivity customers or a site being attacked by a customer of that ISP can automatically avail of the services of the ISP's SIRT. ISP SIRTs are frequently provided as an added-cost service, with the team defining as their constituency only those who specifically subscribe to (and perhaps pay for) Incident Response services. Some providers go even further and offer services such as Virtual Private Network (VPN) and firewall management, as well as intrusion detection for a substantial fee. Thus it's important to determine what incident response and secu- rity resources are available to you, and define your incident response escalation chain BEFORE an incident occurs. You should find out if your ISP has a SIRT, and if so what the charter, policies and services of that team are. (This information is best expressed using the SIRT template as shown in Appendix D of [BCP21].) If the ISP doesn't have a SIRT, you should find out what role, if any, they WILL take in incident response.response to an incident. You should also find out if there is any other SIRT whose constituency would include yourself and to whom incidents could be reported. You may also be able to con- tract these services from third-party companies to perform these ser- vices on a routine or one-time basis. 2.2. Assistance with Inbound Security Incidents When a security incident targeting one of their connectivity custo- mers occurs, you should expect your ISP to inform you of the attack, provide assistance to trace the attack, and collect and protect evidence of the incident and guard against its destruction or unintentional announcement. If the event continues, you may ask the ISP to provide logging in order to further diagnose the problem, or to perform filter- ing of certain types of traffic. You should ask your ISP what information they will be able to give out if another customer is the party attacking you to determine whether or not their response is acceptable to you. Some providers may give this information freely, while others will not release the identity of the attacker without a court order. 2.3. Notification of Vulnerabilities and Reporting of Incidents You should expect your ISP to be proactive in notifying you of security vulnerabilities in the services they provide. In addition, as new vulnerabilities in systems and software are discovered, they should indicate whether their services are threatened by these risks. When security incidents occur that affect components of an ISP's infrastructure, your ISP SHOULD promptly report to you: - who is coordinating response to the incident - the vulnerability - how service was affected - what is being done to respond to the incident - whether customer data may have been compromised - what is being done to eliminate the vulnerability - the expected schedule for response, assuming it can be predicted - the trouble ticket number being used to track the incident by the provider, or other suitable means of identifying the incident at a later date. 2.4. Contact Information If you need to contact someone at your ISP, you should use the address SECURITY@your.isp.example for network security issues, ABUSE@your.isp.example for issues relating to inappropriate public behaviour, and NOC@your.isp.example for issues relating to network infrastructure. ([RFC2142] states that sites (including ISPs) must maintain these mailboxes, as well as additional mailboxes that are defined for receiving queries and reports relating to specific ser- vices.) Your ISP may also have web site addresses (e.g., http://www.ISP-name-here.net/security/)http://www.your.isp.example/security/) that you may use to check for expanded details on the above. You should also be able to find contact information for your ISP in Whois and in the routing registry [RFC1786]. 2.4.1. After Hours You should recieve information for reaching customer support or opera- tions personnel on a 24x7 (24 hours, 7 days per week) basis. If the ISP does not maintain 24x7 operations (NOC, Customer Support, etc.) then some means of reaching customer support after hours for security incidents should be relayed to you in advance. 2.5. Communication and Authentication You should expect your ISP to have clear policies and procedures on the sharing of information about a security incident with you, other ISPs or SIRTs, with law enforcement, and with the press and the general public. If your jurisdiction permits, you should expect to be able to conduct such communication with your ISP over a secure channel. 3. Policies 3.1. Security Policy You should expect your ISP to have a policy with regard to privacy, authentication, accountability, application of security patches, availa- bility and violations reporting. A more detailed discussion of Security Policy can be found in the Site Security Handbook [RFC2196]. 3.2. Appropriate Use Policy When you establish a contract with your ISP to provide connectivity to the Internet, that contract SHOULD be governed by an Appropriate Use Policy (AUP). The AUP SHOULD clearly identify what you may and may not do on the various components of the system or network, including the type of traffic allowed on the networks. The AUP should be as explicit as possible to avoid ambiguity or misunderstanding. The AUP should be reviewed each time you renew your contract. You should also expect your ISP to proactively notify you as their policies are updated. 3.3. Sanctions You should expect the AUP to be clear in stating what sanctions will be enforced in the event of inappropriate behaviour. You should also expect your ISP to be forthcoming in announcing to the community when such sanctions are imposed. 3.4. Announcement of Policies You should expect your ISP to publish their security and appropri- ate use policies in a public place such as their web site. This way, the community can be aware of what the ISP considers appropriate and can know what action to expect in the event of inappropriate behaviour. 4. Network Infrastructure Your ISP is responsible for managing the network infrastructure of their portion of the Internet in such a way that it is: - reasonably resistant to known security vulnerabilities - not easily hijacked by attackers for use in subsequent attacks - capable of preventing internal illegal traffic (bogus route announcements, spoofed traffic, etc.) generated by its custo- mers from reaching the global Internet 5. Physical SecurityConcerns Specific to Hosting Service Customers [Ed: this section is totally new and needs lots of work.] If you are hosting content on your ISP, you have additional con- cerns. - Generally there is a separate AUP from that used for connec- tivity customers. - These machines may be housed in unlocked cabinets. As such, there must be tight restrictions as to who may have access. Electronic access control, guards, video surveillance, etc., are all fair game. All visitors ESPECIALLY need to be escorted, as the potential for damage is much higher than in a colocation situation. - As the customer is not generally responsible for securing the operating system or applications, there needs to be a heightened understanding of how the ISP reacts. - If you also get connectivity from the ISP (i.e., a T1), you should check to see if security for the managed site is done by a different group and check to see if the procedures for reporting and notification are much different. - A modality for backups must be included, as the ISP will be doing the majority of these. Most providers also have off- site backup services. - Other customers may legitimately cause a denial of service attack by hogging all of the network capacity. Providers should have standards as far as how saturated their networks may get, and should prevent this from occurring. - Cold site facilities, and hot spare hardware can be important when recovering from an incident. Customers should inquire with the ISP if this is important to them. - Providers should do a good deal of proactive testing against, and active patching of the OS and application loads. As these loads tend to be the same from customer to customer, the ISP should be responsible in assuring host based security. - Many providers offer a managed security service for additional fees. Customers are encouraged to find out what is included in the service that they are paying for, and to explore options as far as what they can do. - Generally there is option of whether or not the customer even has root privs. 6. Concerns Specific to Co-location Customers If you have co-located equipment at your ISP's facility, the physi- cal security of the installation should be given appropriate considera- tion. This is particularly so for co-located facilities to which people from different organisations and with different security policies have access. Many issues arise surrounding customer access to their co- located equipment. 6.1. Acceptable Use Policy The AUP for co-located customers is usually different from that used by connectivity customers. You should inquire about the AUP. 6.2. Separated Equipment Ideally you and each other customer SHOULD have a fully enclosed locking 'cage', akin to a small room with walls and ceiling of heavy wire mesh fencing, containing the racks in which their equipment is mounted. Each customer would be allowed access to their own cage under escort by one of the ISP's employees, orby a guard, with keys or elec- tronic access control that grant access specifically to their cage.cage, or some combination thereof. This assignment of separate cages is expensive in terms of space however, so many ISPs compromise by putting all co-located equipment together in a single machine room, and managing the actions of escorted customers very closely. However this may be insufficient to prevent mishaps such as the accidental disconnection of another customer's equipment. If a single machine room is used then the ISP SHOULD provide separate locking cabinets for each co-location customer in preferance to an open common area. Another alternative are cabinets which can separate all of the facilities within the same cabinet, and have independent locking mechanisms for each portion of the rack. You should expect to always be supervised while in the physical presence of any equipment that is not yours, and should not expect to be allowed to touch, photograph, or examine equipment belonging to another customer. 6.3. Layer 1 Security Also of importance is "layer 1" security of co-located equipment. Other customers should not blow the same fuse that you are on by power- ing all their machines up at once. The ISP can control this by having separate breakers and circuits for each customer, or by overbuilding the power system and keeping track of the power ratings of all equipment in use. 6.4. Layer 2 Security Also of concern is layer 2 security of co-located equipment. Your equipment SHOULD NOT be allowed to share a physical network segment with hosts belonging to anyone else, whether another customer or the ISP themselves. It's common for crackers to exploit weak security or unen- crypted remote logins on co-located customer-owned equipment to take control of that equipment and put it into promiscuous listening mode on the local network segment, thereby potentially compromising the privacy and security of any other devices on that segment. 6.The use of a switch is generally recommended for this sort of thing. 7. References [BCP21] Brownlee, N and E. Guttman, "Expectations for Computer Security Incident Response", BCP 21, RFC 2350, June 1998. [RFC1786] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., Karrenberg, D., Terpstra, M., and J. Yu, "Representation of IP Routing Policies in a Routing Registry (ripe- 81++)", RFC 1786, March 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, May 1997. [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997. [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September 1997. 7.8. Acknowledgements We gratefully acknowledge the constructive comments received from Nevil Brownlee, Randy Bush, Bill Cheswick, Barbara Y. Fraser, Randall Gellens, Erik Guttman, Larry J. Hughes Jr., Klaus-Peter Kossakowski, Michael A. Patton, Don Stikvoort andStikvoort, Bill Woodcock. 8.Woodcock and Chris Kuivenhoven. 9. Security This entire document discusses security issues. 9. Author's Address10. Authors' Addresses Tony Hansen AT&T Laboratories Lincroft, NJ 07738 USA Phone: +1 732 576-3207 E-Mail: firstname.lastname@example.org Tom Killalea Verio Northwest 15400 SE 30th Pl., Ste. 202 Bellevue,1516 2nd Ave Seattle, WA 98007-654698101 USA Phone: +1 425 649-7417206 694-2196 E-Mail: email@example.com firstname.lastname@example.org 11. Full Copyright Statement Copyright (C) The Internet Society (1998).(1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and dis- tributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organisations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Stan- dards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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."PURPOSE. This document expires August 1999.