idnits 2.17.1 draft-ietf-grip-user-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 629 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 199 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 482 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 16 has weird spacing: '...ormance with...' == Line 25 has weird spacing: '... It is inapp...' == Line 28 has weird spacing: '... The list ...' == Line 31 has weird spacing: '... can be acces...' == Line 34 has weird spacing: '...ons are discu...' == (194 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCisp' is mentioned on line 75, but not defined == Missing Reference: 'RFCsshadd' is mentioned on line 75, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'BCP21' ** Downref: Normative reference to an Informational RFC: RFC 1786 ** Downref: Normative reference to an Informational RFC: RFC 2196 Summary: 13 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft T. Hansen 2 draft-ietf-grip-user-02.txt AT&T Laboratories 3 Valid for six months 4 June 25, 1999 6 Security Checklist for 7 Internet Service Provider (ISP) 8 Consumers 10 12 Author's version: 1.11 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents at 25 any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This memo and its companions are discussed on the GRIP working 35 group mailing list, grip-wg[-request]@uu.net. 37 Copyright Notice 39 Copyright (C) The Internet Society (1999). All Rights Reserved. 41 Abstract 43 The purpose of this document is to provide a checklist for the gen- 44 eral Internet community to use when discussing security with Internet 45 Service Providers (ISPs). These questions can serve as a framework for 46 discussion of security expectations with current and prospective service 47 providers. 49 1. Introduction 51 The purpose of this document is to provide a checklist for the gen- 52 eral Internet community to use when discussing security with Internet 53 Service Providers (ISPs). These questions can serve as a framework for 54 discussion of security expectations with current and prospective service 55 providers. Regrettably, such a discussion rarely takes place today. 57 This document is addressed to Internet service purchasing 58 decision-makers (consumers). Three types of consumers are considered in 59 this document: connectivity consumers, hosting service consumers, and 60 co-located consumers. 62 Additionally, in informing ISPs of what the community will be ask- 63 ing of them, a further goal is to encourage ISPs to become proactive in 64 making security not only a priority, but something to which they point 65 with pride when selling their services. It has been argued that vendors 66 begin to care about security only when prompted by consumers. We hope 67 that these documents will encourage both parties to more readily express 68 how much they care about security, and that discussion between the com- 69 munity and its ISPs will be increased. 71 Note that these are broad categories and individual consumers may 72 not fall exactly into these categories; as such, not all questions will 73 apply to all consumers, nor will all questions apply to all ISPs. 75 Companion documents, [RFCisp] and [RFCsshadd], express the general 76 Internet community's expectations of ISPs with respect to security. 78 The questions have been collected together into Appendix A for easy 79 reference. 81 2. Concerns Specific to Connectivity Service Consumers 83 2.1. Policies 85 2.1.1. Security Policy 87 ** Does the ISP have a written Security Policy? 89 ** If so, how can you receive a copy of it? 91 A Security Policy covers such issues as privacy, authentication, 92 accountability, application of security patches, availability and 93 violations reporting. A more detailed discussion of Security Policies 94 can be found in the Site Security Handbook [RFC2196]. 96 2.1.2. Appropriate Use Policy 98 ** Does the ISP have a written Acceptable Use Policy (AUP)? 100 ** If so, how can you receive a copy of it? 102 When you establish a contract with your ISP to provide connectivity 103 to the Internet, most contracts are governed by an Appropriate Use Pol- 104 icy (AUP). An AUP should clearly identify what you may and may not do 105 on the various components of the system or network, including the type 106 of traffic allowed on the networks. The AUP should be as explicit as 107 possible to avoid ambiguity or misunderstanding. 109 The AUP should be reviewed each time you renew your contract. You 110 should also expect your ISP to proactively notify you as their policies 111 are updated. 113 2.1.3. Sanctions 115 ** If there is an AUP, what sanctions will be enforced in the 116 event of inappropriate behaviour? 118 An AUP should be clear in stating what sanctions will be enforced 119 in the event of inappropriate behaviour. You should also expect your 120 ISP to be forthcoming in announcing to the community when such sanctions 121 are imposed. 123 2.1.4. Announcement of Policies 125 ** If the AUP changes, will you be notified of changes to it, and 126 if so, how? 128 You should expect your ISP to publish their security and appropri- 129 ate use policies in a public place such as their web site. This way, 130 the community can be aware of what the ISP considers appropriate and can 131 know what actions to expect in the event of inappropriate behaviour. 133 2.2. Incident Handling 135 A Security Incident Response Team (SIRT) is a team that performs, 136 coordinates, and supports the response to security incidents that 137 involve sites within a defined constituency. The Internet community's 138 expectations of SIRTs are described in [BCP21]. 140 2.2.1. ISPs and Security Incident Response Teams 142 ** Does the ISP have a Security Incident Response Team (SIRT)? 144 ** If so, 146 ** What is the charter, policies and services of the 147 team? 149 ** What is the escalation chain that I would follow? 151 ** Is it published somewhere (on the web)? 153 ** What is the cost of using the SIRT's different ser- 154 vices? 156 ** If not, 158 ** What role will the ISP take in response to a secu- 159 rity incident? 161 ** Is there another SIRT to whom you can turn? 163 ** What other security resources are available from the ISP? 165 ** If so, at what cost? 167 ** What other security-related services are available from the 168 ISP? 170 ** If so, at what cost? 172 Some ISPs have Security Incident Response Teams (SIRT's). Some 173 don't. In some ISPs, the SIRT consists of a single person; in others, a 174 large group of people. Some ISP's provide SIRT's as an added-cost ser- 175 vice, with the team defining as their constituency only those who 176 specifically subscribe to (and perhaps pay for) Incident Response ser- 177 vices. 179 Some of the services provided by SIRT's include: responding to 180 attacks on the ISP's consumers, responding to attacks on other sites by 181 consumers of the ISP, Virtual Private Network (VPN) and firewall manage- 182 ment, and intrusion detection. 184 Thus it's important to determine what incident response and secu- 185 rity resources are available to you, and define your incident response 186 escalation chain BEFORE an incident occurs. You should find out if your 187 ISP has a SIRT, and if so what the charter, policies and services of 188 that team are. (This information is best expressed using the SIRT tem- 189 plate as shown in Appendix D of [BCP21].) 191 If the ISP doesn't have a SIRT, you should find out what role, if 192 any, they WILL take in response to an incident. You should also find 193 out if there is any other SIRT whose constituency would include yourself 194 and to whom incidents could be reported. You may also be able to con- 195 tract these services from third-party companies to perform these ser- 196 vices on a routine or one-time basis. 198 2.2.2. Assistance with Inbound Security Incidents 200 ** Will the ISP inform you of attacks against you? 202 ** Will the ISP provide assistance to trace an attack? 204 ** Will the ISP collect and protect evidence of the incident? 206 ** Will the ISP guard against destruction of such evidence? 208 ** Will the ISP guard against unintentional announcement of such 209 evidence. 211 When a security incident targeting you occurs, you should expect 212 your ISP to inform you of the attack, provide assistance to trace the 213 attack, collect and protect evidence of the incident, and guard against 214 its destruction or unintentional announcement. 216 If the event continues, you may ask the ISP to provide logging in 217 order to further diagnose the problem, or to perform filtering of cer- 218 tain types of traffic. 220 You should ask your ISP what information they will be able to give 221 out if another consumer is the party attacking you to determine whether 222 or not their response is acceptable to you. Some providers may give 223 this information freely, while others will not release the identity of 224 the attacker without a court order. 226 2.2.3. Notification of Vulnerabilities and Reporting of Incidents 228 ** What information will the ISP make available to you as secu- 229 rity vulnerabilities are discovered in their services? 231 ** Will they be proactive or reactive in informing you? 233 ** How and where will that information be communicated to you? 234 ** What information will be included in such reports? 236 You should expect your ISP to be proactive in notifying you of 237 security vulnerabilities in the services they provide. In addition, as 238 new vulnerabilities in systems and software are discovered, they should 239 indicate whether their services are threatened by these risks. 241 When security incidents occur that affect components of an ISP's 242 infrastructure, your ISP should promptly report to you: 244 - who is coordinating response to the incident 246 - the vulnerability 248 - how service was affected 250 - what is being done to respond to the incident 252 - whether customer data may have been compromised 254 - what is being done to eliminate the vulnerability 256 - the expected schedule for response, assuming it can be 257 predicted 259 - the trouble ticket number being used to track the incident by 260 the provider, or other suitable means of identifying the 261 incident at a later date. 263 2.2.4. Contact Information 265 ** Who should you contact via email for network security issues? 267 ** Who should you contact via email to report inappropriate pub- 268 lic behaviour? 270 ** Who should you contact via email for issues relating to net- 271 work infrastructure? 273 ** Who should you contact via email for network security issues? 275 ** ???? Anything else from the email list? 277 If you need to contact someone at your ISP, you should use the 278 address SECURITY@your.isp.example for network security issues, 279 ABUSE@your.isp.example for issues relating to inappropriate public 280 behaviour, and NOC@your.isp.example for issues relating to network 281 infrastructure. ([RFC2142] states that sites (including ISPs) should 282 maintain these mailboxes, as well as additional mailboxes that are 283 defined for receiving queries and reports relating to specific ser- 284 vices.) Your ISP may also have web site addresses (e.g., 285 http://www.your.isp.example/security/) that you may use to check for 286 expanded details on the above. You should also be able to find contact 287 information for your ISP in Whois and in the routing registry [RFC1786]. 289 2.2.5. After Hours 291 ** What are the hours of operation of customer support or opera- 292 tions personnel? 294 ** If reduced support is available "after hours", how can support 295 personnel be reached in the case of a security incident? 297 You should recieve information for reaching customer support or 298 operations personnel. If the ISP does not maintain 24x7 (24 hours, 7 299 days per week) operations (NOC, Customer Support, etc.), then some means 300 should still be available for reaching customer support for security 301 incidents (suspected or actual) and receiving a response in real-time. 303 2.2.6. Communication and Authentication 305 ** How would your ISP communicate with you if a security incident 306 were to occur? 308 ** What information would be communicated with others? 310 You should expect your ISP to have clear policies and procedures on 311 the sharing of information about a security incident with you, other 312 ISPs or SIRTs, with law enforcement, and with the press and the general 313 public. If your jurisdiction permits, you should expect to be able to 314 conduct such communication with your ISP over a secure channel (e.g., 315 secure web, secure Email, telephone, attended fax, etc.). 317 2.3. Layer 2 Security 319 ** What measures do you take to prevent traffic taking unauthor- 320 ised routes into or via your network? 322 ** Are the networks that support your connectivity consumers and 323 your hosting consumers segmented? 325 ** What general measures do you take to protect your Internet 326 facing equipment providing production services from denial of 327 service attacks, break-ins or spoofing? 329 Most ISPs have firewalls of one kind or another that prevent random 331 packets from flowing through their network from the Internet. 333 Methods of segmenting networks include VLANs and non-broadcast net- 334 works. These can prevent one consumer class from affecting another con- 335 sumer class. 337 2.4. Security Patches 339 ** Is the ISP up-to-date in applying security patches to their 340 software/firmware running on their production equipment? 342 Information about available security patches is readily available 343 from the Center for Emergency Response Team (CERT) at 344 http://www.cert.org. You can use telnet to connect to the port numbers 345 of public TCP-based services (SMTP, POP, IMAP, HTTP, etc.) provided by 346 the ISP, and check the announced version numbers for currentness and 347 known security flaws. 349 2.5. Other Security Services 350 For the really serious consumer, additional services may be useful. 352 ** Are port scan audits ever performed on consumer's networks and 353 abnormal findings reported to the consumer? 355 ** If so, how much does it cost? 357 ** Is additional support available for auditing and securing your 358 hosts? 360 ** If so, how much does it cost? 362 ** Does the ISP have a monitoring system that detects host 363 attacks or network attacks in realtime? 365 ** Would it be possible to test the ISP's security by mounting a 366 deliberate attack at a mutually agreed time? 368 Audits run by the ISP provide tests of your own host's security. 369 These can be useful for plugging holes on your systems. 371 Probes of the ISP's network can potentially be seen by them as an 372 attack, and may lead to ramifications against you. So be careful that 373 you do any testing of the ISP's security only with their knowledge. 374 Freely available tools, such as ping, traceroute, SATAN and mscan, 375 attempt a variety of probes. Most ISP's monitoring systems will pick up 376 such probes. Useful tools of this sort can be obtained from 377 ftp://ftp.cert.org. 379 2.6. References 381 ** Will the ISP provide a list of reference customers? 383 If the ISP lets you speak with some reference customers, you might 384 ask them about problems with respect to the reporting or resolution of 385 any security incidents, as well as the security services and advice 386 offered to them by the ISP. 388 3. Concerns Specific to Hosting Service Consumers 390 If you are hosting content on your ISP, you have additional con- 391 cerns. 393 3.1. Acceptable Use Policy (AUP) 395 ** What is the Acceptable Use Policy (AUP) for web content hosted 396 by the ISP? 398 Generally there is a separate AUP from that used for connectivity 399 consumers. 401 3.2. Physical Security 403 ** What is the physical security of the machines used for host- 404 ing? 406 Machines used for hosting may be housed in unlocked cabinets. As 407 such, there must be tight restrictions as to who may have access. Elec- 408 tronic access control, guards, video surveillance, etc., are all fair 409 game. All visitors ESPECIALLY need to be escorted, as the potential for 410 damage is much higher than in a colocation situation. 412 As the consumer is not generally responsible for securing the 413 operating system or applications, there needs to be a heightened under- 414 standing of how the ISP reacts. 416 If you also get connectivity from the ISP (i.e., a T1), you should 417 check to see if security for the managed site is done by a different 418 group and check to see if the procedures for reporting and notification 419 are much different. 421 Providers should do a good deal of proactive testing against, and 422 active patching of the OS and application loads. As these loads tend to 423 be the same from consumer to consumer, the ISP should be responsible in 424 assuring host based security. 426 3.3. Backups 428 ** How often are backups of your web content performed? 430 ** How often are off-site backup services used? 432 Since the ISP is doing backups of your material, you should be 433 aware of their frequency. Most providers also periodically send their 434 backups to off-site locations. You may wish to provide additional back- 435 ups of your own for the content. 437 3.4. Allocation of Network Capacity 439 ** Does the ISP provide any sort of load balancing to prevent 440 saturation of the network capacity by other customers of the 441 ISP? 443 Other customers may legitimately cause a denial of service attack 444 by hogging all of the network capacity. Providers should have standards 445 as far as how saturated their networks may get, and should prevent this 446 from occurring. 448 3.5. Spare Facilities 450 ** What kind of spare facilities are available for use should an 451 incident occur? 453 ** How fast can they be deployed? 455 This information is useful if high availability is important to 456 you. Cold site facilities and hot spare hardware can be important when 457 recovering from an incident. 459 3.6. Managed Security Services 461 ** Does the ISP provide a managed security service? 462 Many providers offer a managed security service for additional 463 fees. Consumers are encouraged to find out what is included in the 464 service that they are paying for, and to explore options as far as 465 what they can do. 467 3.7. Content Management 469 ** What kind of access is provided to the machine for managing 470 your content? 472 ** What kind of content is permitted to be hosted? 473 Modifying the content of your site can be performed in a multitude 474 of ways. Some ISP's allow the content to be managed through web pages 475 only. Some ISP's allow you to use FTP to send new content to the site. 476 Some ISP's provide support for vendor-specific access (e.g., Microsoft 477 FrontPage) support. Some ISP's provide a shell account for you to log 478 in and modify the content accordingly. Some ISP's provide staging areas 479 for you to test new content before publishing it in the normal loca- 480 tions. Some ISP's provide complete access to the machine being used for 481 hosting the content, including administrative control (root access) of 482 the machine. 484 Some ISP's permit only web pages to be stored. Some ISP's provide 485 some canned CGI programs to be used. Some ISP's provide support for 486 streaming audio or video. Some ISP's allow reviewed CGI programs to be 487 stored. Some ISP's allow you to write and use your own CGI programs. 488 Some ISP's provide access to other vendor-specific server facilities 489 (e.g., Fast CGI, Server Side Scripting). 491 3.8. Secure Web Servers 493 ** Does the ISP provide secure web servers (https)? 495 ** If so, is their host certificate issued by a well-known Certi- 496 ficate Authority (CA)? 498 ** Is the content provided by the secure web servers well 499 separated from that available on their non-secure web server? 501 ** Is the content provided by the secure web servers inaccessible 502 by other customers? 504 ** How would you upload content to the secure web servers? 506 Secure web servers provide an additional layer of security to the 507 content. Such content must not be accessible from the non-secure web 508 servers, nor should be accessible by other customers. The mechanisms 509 used to upload content to the secure web server area may be different 510 from those used to upload content to the non-secure area. 512 4. Concerns Specific to Co-location Consumers 514 If you have co-located equipment at your ISP's facility, the physi- 515 cal security of the installation should be given appropriate considera- 516 tion. This is particularly so for co-located facilities to which people 517 from different organisations and with different security policies have 518 access. Many issues arise surrounding consumer access to their co- 519 located equipment. 521 4.1. Acceptable Use Policy (AUP) 523 ** What is the Acceptable Use Policy (AUP) for co-located consu- 524 mers? 526 The AUP for co-located consumers is usually different from that 527 used by connectivity consumers. 529 4.2. Physical Security 531 ** What forms of physical security are provided for your equip- 532 ment? 534 ** What forms of supervision are provided while visiting your 535 equipment? 537 Ideally you and each other consumer should have a fully enclosed 538 locking 'cage', akin to a small room with walls and ceiling of heavy 539 wire mesh fencing, containing the racks in which their equipment is 540 mounted. Each consumer would be allowed access to their own cage under 541 escort by one of the ISP's employees, by a guard, with keys or elec- 542 tronic access control that grant access specifically to their cage, or 543 some combination thereof. 545 This assignment of separate cages is expensive in terms of space 546 however, so many ISPs compromise by putting all co-located equipment 547 together in a single machine room, and managing the actions of escorted 548 consumers very closely. However this may be insufficient to prevent 549 mishaps such as the accidental disconnection of another consumer's 550 equipment. If a single machine room is used then the ISP should provide 551 separate locking cabinets for each co-location consumer in preferance to 552 an open common area. Another alternative are cabinets which can 553 separate all of the facilities within the same cabinet, and have 554 independent locking mechanisms for each portion of the rack. 556 You should expect to always be supervised while in the physical 557 presence of any equipment that is not yours, and should not expect to be 558 allowed to touch, photograph, or examine equipment belonging to another 559 consumer. 561 4.3. Layer 1 Security 563 ** How is co-located equipment protected electrically from other 564 consumer's co-located equipment? 566 Also of importance is "layer 1" security of co-located equipment. 567 Other consumers should not blow the same fuse that you are on by power- 568 ing all their machines up at once. The ISP can control this by having 569 separate breakers and circuits for each consumer, or by overbuilding the 570 power system and keeping track of the power ratings of all equipment in 571 use. 573 4.4. Layer 2 Security 575 ** How is co-located equipment protected on the network from 576 other consumer's co-located equipment? 578 Also of concern is layer 2 security of co-located equipment. Your 579 equipment should not be allowed to share a physical network segment with 580 hosts belonging to anyone else, whether another consumer or the ISP 581 themselves. It's common for crackers to exploit weak security or unen- 582 crypted remote logins on co-located consumer-owned equipment to take 583 control of that equipment and put it into promiscuous listening mode on 584 the local network segment, thereby potentially compromising the privacy 585 and security of any other devices on that segment. The use of a switch 586 is generally recommended for this sort of thing. 588 5. References 590 [BCP21] Brownlee, N and E. Guttman, "Expectations for Computer 591 Security Incident Response", BCP 21, RFC 2350, June 1998. 593 [RFC1786] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., 594 Karrenberg, D., Terpstra, M., and J. Yu, "Representation 595 of IP Routing Policies in a Routing Registry (ripe- 596 81++)", RFC 1786, March 1995. 598 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles 599 and Functions", RFC 2142, May 1997. 601 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September 602 1997. 604 6. Acknowledgements 606 This document is the product of input from many people and many 607 sources. The constructive comments received from Nevil Brownlee, Randy 608 Bush, Bill Cheswick, Barbara Y. Fraser, Randall Gellens, Erik Guttman, 609 Larry J. Hughes Jr., Klaus-Peter Kossakowski, Michael A. Patton, Don 610 Stikvoort, Bill Woodcock and Chris Kuivenhoven are gratefully ack- 611 nowledged. 613 7. Security 615 This entire document discusses security issues. 617 8. Author's Address 619 Tony Hansen 620 AT&T Laboratories 621 Lincroft, NJ 07738 622 USA 624 Phone: +1 732 576-3207 625 E-Mail: tony@att.com 627 9. Full Copyright Statement 629 Copyright (C) The Internet Society (1999). All Rights Reserved. 631 This document and translations of it may be copied and furnished to 632 others, and derivative works that comment on or otherwise explain it or 633 assist in its implmentation may be prepared, copied, published and dis- 634 tributed, in whole or in part, without restriction of any kind, provided 635 that the above copyright notice and this paragraph are included on all 636 such copies and derivative works. However, this document itself may not 637 be modified in any way, such as by removing the copyright notice or 638 references to the Internet Society or other Internet organisations, 639 except as needed for the purpose of developing Internet standards in 640 which case the procedures for copyrights defined in the Internet Stan- 641 dards process must be followed, or as required to translate it into 642 languages other than English. 644 The limited permissions granted above are perpetual and will not be 645 revoked by the Internet Society or its successors or assigns. 647 This document and the information contained herein is provided on 648 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 649 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 650 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 651 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 652 FITNESS FOR A PARTICULAR PURPOSE. 654 This document expires December 1999. 656 Appendix A Security Checklist for ISP Consumers June 25, 1999 658 Appendix A - Collected Questions 660 2. Concerns Specific to Connectivity Service Consumers 662 2.1. Policies 664 2.1.1. Security Policy 666 ** Does the ISP have a written Security Policy? 668 ** If so, how can you receive a copy of it? 670 2.1.2. Appropriate Use Policy 672 ** Does the ISP have a written Acceptable Use Policy (AUP)? 674 ** If so, how can you receive a copy of it? 676 2.1.3. Sanctions 678 ** If there is an AUP, what sanctions will be enforced in the 679 event of inappropriate behaviour? 681 2.1.4. Announcement of Policies 683 ** If the AUP changes, will you be notified of changes to it, and 684 if so, how? 686 2.2. Incident Handling 688 2.2.1. ISPs and Security Incident Response Teams 690 ** Does the ISP have a Security Incident Response Team (SIRT)? 692 ** If so, 694 ** What is the charter, policies and services of the 695 team? 697 ** What is the escalation chain that I would follow? 699 ** Is it published somewhere (on the web)? 701 ** What is the cost of using the SIRT's different ser- 702 vices? 704 ** If not, 705 Appendix A Security Checklist for ISP Consumers June 25, 1999 707 ** What role will the ISP take in response to a secu- 708 rity incident? 710 ** Is there another SIRT to whom you can turn? 712 ** What other security resources are available from the ISP? 714 ** If so, at what cost? 716 ** What other security-related services are available from the 717 ISP? 719 ** If so, at what cost? 721 2.2.2. Assistance with Inbound Security Incidents 723 ** Will the ISP inform you of attacks against you? 725 ** Will the ISP provide assistance to trace an attack? 727 ** Will the ISP collect and protect evidence of the incident? 729 ** Will the ISP guard against destruction of such evidence? 731 ** Will the ISP guard against unintentional announcement of such 732 evidence. 734 2.2.3. Notification of Vulnerabilities and Reporting of Incidents 736 ** What information will the ISP make available to you as secu- 737 rity vulnerabilities are discovered in their services? 739 ** Will they be proactive or reactive in informing you? 741 ** How and where will that information be communicated to you? 743 ** What information will be included in such reports? 745 2.2.4. Contact Information 747 ** Who should you contact via email for network security issues? 749 ** Who should you contact via email to report inappropriate pub- 750 lic behaviour? 752 ** Who should you contact via email for issues relating to net- 753 work infrastructure? 754 Appendix A Security Checklist for ISP Consumers June 25, 1999 756 ** Who should you contact via email for network security issues? 758 ** ???? Anything else from the email list? 760 2.2.5. After Hours 762 ** What are the hours of operation of customer support or opera- 763 tions personnel? 765 ** If reduced support is available "after hours", how can support 766 personnel be reached in the case of a security incident? 768 2.2.6. Communication and Authentication 770 ** How would your ISP communicate with you if a security incident 771 were to occur? 773 ** What information would be communicated with others? 775 2.3. Layer 2 Security 777 ** What measures do you take to prevent traffic taking unauthor- 778 ised routes into or via your network? 780 ** Are the networks that support your connectivity consumers and 781 your hosting consumers segmented? 783 ** What general measures do you take to protect your Internet 784 facing equipment providing production services from denial of 785 service attacks, break-ins or spoofing? 787 2.4. Security Patches 789 ** Is the ISP up-to-date in applying security patches to their 790 software/firmware running on their production equipment? 792 2.5. Other Security Services 794 ** Are port scan audits ever performed on consumer's networks and 795 abnormal findings reported to the consumer? 797 ** If so, how much does it cost? 799 ** Is additional support available for auditing and securing your 800 hosts? 802 ** If so, how much does it cost? 804 Appendix A Security Checklist for ISP Consumers June 25, 1999 806 ** Does the ISP have a monitoring system that detects host 807 attacks or network attacks in realtime? 809 ** Would it be possible to test the ISP's security by mounting a 810 deliberate attack at a mutually agreed time? 812 2.6. References 814 ** Will the ISP provide a list of reference customers? 816 3. Concerns Specific to Hosting Service Consumers 818 3.1. Acceptable Use Policy (AUP) 820 ** What is the Acceptable Use Policy (AUP) for web content hosted 821 by the ISP? 823 3.2. Physical Security 825 ** What is the physical security of the machines used for host- 826 ing? 828 3.3. Backups 830 ** How often are backups of your web content performed? 832 ** How often are off-site backup services used? 834 3.4. Allocation of Network Capacity 836 ** Does the ISP provide any sort of load balancing to prevent 837 saturation of the network capacity by other customers of the 838 ISP? 840 3.5. Spare Facilities 842 ** What kind of spare facilities are available for use should an 843 incident occur? 845 ** How fast can they be deployed? 847 3.6. Managed Security Services 849 ** Does the ISP provide a managed security service? 851 3.7. Content Management 853 ** What kind of access is provided to the machine for managing 855 Appendix A Security Checklist for ISP Consumers June 25, 1999 857 your content? 859 ** What kind of content is permitted to be hosted? 861 3.8. Secure Web Servers 863 ** Does the ISP provide secure web servers (https)? 865 ** If so, is their host certificate issued by a well-known Certi- 866 ficate Authority (CA)? 868 ** Is the content provided by the secure web servers well 869 separated from that available on their non-secure web server? 871 ** Is the content provided by the secure web servers inaccessible 872 by other customers? 874 ** How would you upload content to the secure web servers? 876 4. Concerns Specific to Co-location Consumers 878 4.1. Acceptable Use Policy (AUP) 880 ** What is the Acceptable Use Policy (AUP) for co-located consu- 881 mers? 883 4.2. Physical Security 885 ** What forms of physical security are provided for your equip- 886 ment? 888 ** What forms of supervision are provided while visiting your 889 equipment? 891 4.3. Layer 1 Security 893 ** How is co-located equipment protected electrically from other 894 consumer's co-located equipment? 896 4.4. Layer 2 Security 898 ** How is co-located equipment protected on the network from 899 other consumer's co-located equipment?