[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-grip-user-02.txt just sent to the Internet-Drafts repository
Thanks Tony. I was just over at the IETF site and the 02 draft is not
there. So, those of you attending the meeting should probably make sure
they have an electronic or hard copy of it.
Barb
At 04:32 PM 6/25/99 -0400, Tony Hansen wrote:
>The enclosed draft was just sent to the Internet-Drafts repository.
>Hopefully it's received before the deadline.
>
>I'm sorry I didn't get this out sooner.
>
>See you all in Oslo!
>
> Tony Hansen
> tony@att.com
>
>
>
>
>
>Internet Draft T. Hansen
>draft-ietf-grip-user-02.txt AT&T Laboratories
>Valid for six months
> June 25, 1999
>
>
>
> Security Checklist for
> Internet Service Provider (ISP)
> Consumers
>
> <draft-ietf-grip-user-02.txt>
>
> Author's version: 1.11
>
> 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."
>
> The list of current Internet-Drafts can be accessed at
>http://www.ietf.org/ietf/1id-abstracts.txt.
>
> The list of Internet-Draft Shadow Directories can be accessed at
>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 (1999). All Rights Reserved.
>
>Abstract
>
> The purpose of this document is to provide a checklist for the gen-
>eral Internet community to use when discussing security with Internet
>Service Providers (ISPs). These questions can serve as a framework for
>discussion of security expectations with current and prospective service
>
>
>
>Hansen [Page 1]
>
>Internet Draft Security Checklist for ISP Consumers June 25, 1999
>
>
>providers.
>
>
>1. Introduction
>
> The purpose of this document is to provide a checklist for the gen-
>eral Internet community to use when discussing security with Internet
>Service Providers (ISPs). These questions can serve as a framework for
>discussion of security expectations with current and prospective service
>providers. Regrettably, such a discussion rarely takes place today.
>
> This document is addressed to Internet service purchasing
>decision-makers (consumers). Three types of consumers are considered in
>this document: connectivity consumers, hosting service consumers, and
>co-located consumers.
>
> Additionally, in informing ISPs of what the community will be ask-
>ing 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. It has been argued that vendors
>begin to care about security only when prompted by consumers. We hope
>that these documents will encourage both parties to more readily express
>how much they care about security, and that discussion between the com-
>munity and its ISPs will be increased.
>
> Note that these are broad categories and individual consumers may
>not fall exactly into these categories; as such, not all questions will
>apply to all consumers, nor will all questions apply to all ISPs.
>
> Companion documents, [RFCisp] and [RFCsshadd], express the general
>Internet community's expectations of ISPs with respect to security.
>
> The questions have been collected together into Appendix A for easy
>reference.
>
>2. Concerns Specific to Connectivity Service Consumers
>
>2.1. Policies
>
>
>2.1.1. Security Policy
>
> ** Does the ISP have a written Security Policy?
>
> ** If so, how can you receive a copy of it?
>
> A Security Policy covers such issues as privacy, authentication,
>accountability, application of security patches, availability and
>
>
>
>Hansen [Page 2]
>
>Internet Draft Security Checklist for ISP Consumers June 25, 1999
>
>
>violations reporting. A more detailed discussion of Security Policies
>can be found in the Site Security Handbook [RFC2196].
>
>2.1.2. Appropriate Use Policy
>
> ** Does the ISP have a written Acceptable Use Policy (AUP)?
>
> ** If so, how can you receive a copy of it?
>
> When you establish a contract with your ISP to provide connectivity
>to the Internet, most contracts are governed by an Appropriate Use Pol-
>icy (AUP). An 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.
>
>2.1.3. Sanctions
>
> ** If there is an AUP, what sanctions will be enforced in the
> event of inappropriate behaviour?
>
> An AUP should 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.
>
>2.1.4. Announcement of Policies
>
> ** If the AUP changes, will you be notified of changes to it, and
> if so, how?
>
> 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 actions to expect in the event of inappropriate behaviour.
>
>2.2. Incident Handling
>
> 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].
>
>
>
>
>
>Hansen [Page 3]
>
>Internet Draft Security Checklist for ISP Consumers June 25, 1999
>
>
>2.2.1. ISPs and Security Incident Response Teams
>
>
> ** Does the ISP have a Security Incident Response Team (SIRT)?
>
> ** If so,
>
> ** What is the charter, policies and services of the
> team?
>
> ** What is the escalation chain that I would follow?
>
> ** Is it published somewhere (on the web)?
>
> ** What is the cost of using the SIRT's different ser-
> vices?
>
> ** If not,
>
> ** What role will the ISP take in response to a secu-
> rity incident?
>
> ** Is there another SIRT to whom you can turn?
>
> ** What other security resources are available from the ISP?
>
> ** If so, at what cost?
>
> ** What other security-related services are available from the
> ISP?
>
> ** If so, at what cost?
>
> Some ISPs have Security Incident Response Teams (SIRT's). Some
>don't. In some ISPs, the SIRT consists of a single person; in others, a
>large group of people. Some ISP's provide SIRT's as an added-cost ser-
>vice, with the team defining as their constituency only those who
>specifically subscribe to (and perhaps pay for) Incident Response ser-
>vices.
>
> Some of the services provided by SIRT's include: responding to
>attacks on the ISP's consumers, responding to attacks on other sites by
>consumers of the ISP, Virtual Private Network (VPN) and firewall manage-
>ment, and intrusion detection.
>
> 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
>
>
>
>Hansen [Page 4]
>
>Internet Draft Security Checklist for ISP Consumers June 25, 1999
>
>
>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 tem-
>plate 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 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.2. Assistance with Inbound Security Incidents
>
>
> ** Will the ISP inform you of attacks against you?
>
> ** Will the ISP provide assistance to trace an attack?
>
> ** Will the ISP collect and protect evidence of the incident?
>
> ** Will the ISP guard against destruction of such evidence?
>
> ** Will the ISP guard against unintentional announcement of such
> evidence.
>
> When a security incident targeting you occurs, you should expect
>your ISP to inform you of the attack, provide assistance to trace the
>attack, 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 filtering of cer-
>tain types of traffic.
>
> You should ask your ISP what information they will be able to give
>out if another consumer 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.2.3. Notification of Vulnerabilities and Reporting of Incidents
>
> ** What information will the ISP make available to you as secu-
> rity vulnerabilities are discovered in their services?
>
> ** Will they be proactive or reactive in informing you?
>
> ** How and where will that information be communicated to you?
>
>
>
>Hansen [Page 5]
>
>Internet Draft Security Checklist for ISP Consumers June 25, 1999
>
>
> ** What information will be included in such reports?
>
> 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.2.4. Contact Information
>
> ** Who should you contact via email for network security issues?
>
> ** Who should you contact via email to report inappropriate pub-
> lic behaviour?
>
> ** Who should you contact via email for issues relating to net-
> work infrastructure?
>
> ** Who should you contact via email for network security issues?
>
> ** ???? Anything else from the email list?
>
> 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) should
>
>
>
>Hansen [Page 6]
>
>Internet Draft Security Checklist for ISP Consumers June 25, 1999
>
>
>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.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.2.5. After Hours
>
> ** What are the hours of operation of customer support or opera-
> tions personnel?
>
> ** If reduced support is available "after hours", how can support
> personnel be reached in the case of a security incident?
>
> You should recieve information for reaching customer support or
>operations personnel. If the ISP does not maintain 24x7 (24 hours, 7
>days per week) operations (NOC, Customer Support, etc.), then some means
>should still be available for reaching customer support for security
>incidents (suspected or actual) and receiving a response in real-time.
>
>2.2.6. Communication and Authentication
>
> ** How would your ISP communicate with you if a security incident
> were to occur?
>
> ** What information would be communicated with others?
>
> 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 (e.g.,
>secure web, secure Email, telephone, attended fax, etc.).
>
>2.3. Layer 2 Security
>
> ** What measures do you take to prevent traffic taking unauthor-
> ised routes into or via your network?
>
> ** Are the networks that support your connectivity consumers and
> your hosting consumers segmented?
>
> ** What general measures do you take to protect your Internet
> facing equipment providing production services from denial of
> service attacks, break-ins or spoofing?
>
> Most ISPs have firewalls of one kind or another that prevent random
>
>
>
>Hansen [Page 7]
>
>Internet Draft Security Checklist for ISP Consumers June 25, 1999
>
>
>packets from flowing through their network from the Internet.
>
> Methods of segmenting networks include VLANs and non-broadcast net-
>works. These can prevent one consumer class from affecting another con-
>sumer class.
>
>2.4. Security Patches
>
> ** Is the ISP up-to-date in applying security patches to their
> software/firmware running on their production equipment?
>
> Information about available security patches is readily available
>from the Center for Emergency Response Team (CERT) at
>http://www.cert.org. You can use telnet to connect to the port numbers
>of public TCP-based services (SMTP, POP, IMAP, HTTP, etc.) provided by
>the ISP, and check the announced version numbers for currentness and
>known security flaws.
>
>2.5. Other Security Services
>For the really serious consumer, additional services may be useful.
>
> ** Are port scan audits ever performed on consumer's networks and
> abnormal findings reported to the consumer?
>
> ** If so, how much does it cost?
>
> ** Is additional support available for auditing and securing your
> hosts?
>
> ** If so, how much does it cost?
>
> ** Does the ISP have a monitoring system that detects host
> attacks or network attacks in realtime?
>
> ** Would it be possible to test the ISP's security by mounting a
> deliberate attack at a mutually agreed time?
>
> Audits run by the ISP provide tests of your own host's security.
>These can be useful for plugging holes on your systems.
>
> Probes of the ISP's network can potentially be seen by them as an
>attack, and may lead to ramifications against you. So be careful that
>you do any testing of the ISP's security only with their knowledge.
>Freely available tools, such as ping, traceroute, SATAN and mscan,
>attempt a variety of probes. Most ISP's monitoring systems will pick up
>such probes. Useful tools of this sort can be obtained from
>ftp://ftp.cert.org.
>
>
>
>
>Hansen [Page 8]
>
>Internet Draft Security Checklist for ISP Consumers June 25, 1999
>
>
>2.6. References
>
> ** Will the ISP provide a list of reference customers?
>
> If the ISP lets you speak with some reference customers, you might
>ask them about problems with respect to the reporting or resolution of
>any security incidents, as well as the security services and advice
>offered to them by the ISP.
>
>3. Concerns Specific to Hosting Service Consumers
>
> If you are hosting content on your ISP, you have additional con-
>cerns.
>
>3.1. Acceptable Use Policy (AUP)
>
> ** What is the Acceptable Use Policy (AUP) for web content hosted
> by the ISP?
>
> Generally there is a separate AUP from that used for connectivity
>consumers.
>
>3.2. Physical Security
>
> ** What is the physical security of the machines used for host-
> ing?
>
> Machines used for hosting may be housed in unlocked cabinets. As
>such, there must be tight restrictions as to who may have access. Elec-
>tronic 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 consumer is not generally responsible for securing the
>operating system or applications, there needs to be a heightened under-
>standing 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.
>
> 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 consumer to consumer, the ISP should be responsible in
>assuring host based security.
>
>
>
>
>
>Hansen [Page 9]
>
>Internet Draft Security Checklist for ISP Consumers June 25, 1999
>
>
>3.3. Backups
>
> ** How often are backups of your web content performed?
>
> ** How often are off-site backup services used?
>
> Since the ISP is doing backups of your material, you should be
>aware of their frequency. Most providers also periodically send their
>backups to off-site locations. You may wish to provide additional back-
>ups of your own for the content.
>
>3.4. Allocation of Network Capacity
>
> ** Does the ISP provide any sort of load balancing to prevent
> saturation of the network capacity by other customers of the
> ISP?
>
> 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.
>
>3.5. Spare Facilities
>
> ** What kind of spare facilities are available for use should an
> incident occur?
>
> ** How fast can they be deployed?
>
> This information is useful if high availability is important to
>you. Cold site facilities and hot spare hardware can be important when
>recovering from an incident.
>
>3.6. Managed Security Services
>
> ** Does the ISP provide a managed security service?
> Many providers offer a managed security service for additional
> fees. Consumers 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.
>
>3.7. Content Management
>
> ** What kind of access is provided to the machine for managing
> your content?
>
> ** What kind of content is permitted to be hosted?
>
>
>
>
>Hansen [Page 10]
>
>Internet Draft Security Checklist for ISP Consumers June 25, 1999
>
>
> Modifying the content of your site can be performed in a multitude
>of ways. Some ISP's allow the content to be managed through web pages
>only. Some ISP's allow you to use FTP to send new content to the site.
>Some ISP's provide support for vendor-specific access (e.g., Microsoft
>FrontPage) support. Some ISP's provide a shell account for you to log
>in and modify the content accordingly. Some ISP's provide staging areas
>for you to test new content before publishing it in the normal loca-
>tions. Some ISP's provide complete access to the machine being used for
>hosting the content, including administrative control (root access) of
>the machine.
>
> Some ISP's permit only web pages to be stored. Some ISP's provide
>some canned CGI programs to be used. Some ISP's provide support for
>streaming audio or video. Some ISP's allow reviewed CGI programs to be
>stored. Some ISP's allow you to write and use your own CGI programs.
>Some ISP's provide access to other vendor-specific server facilities
>(e.g., Fast CGI, Server Side Scripting).
>
>3.8. Secure Web Servers
>
> ** Does the ISP provide secure web servers (https)?
>
> ** If so, is their host certificate issued by a well-known Certi-
> ficate Authority (CA)?
>
> ** Is the content provided by the secure web servers well
> separated from that available on their non-secure web server?
>
> ** Is the content provided by the secure web servers inaccessible
> by other customers?
>
> ** How would you upload content to the secure web servers?
>
> Secure web servers provide an additional layer of security to the
>content. Such content must not be accessible from the non-secure web
>servers, nor should be accessible by other customers. The mechanisms
>used to upload content to the secure web server area may be different
>from those used to upload content to the non-secure area.
>
>4. Concerns Specific to Co-location Consumers
>
> 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 consumer access to their co-
>located equipment.
>
>
>
>
>Hansen [Page 11]
>
>Internet Draft Security Checklist for ISP Consumers June 25, 1999
>
>
>4.1. Acceptable Use Policy (AUP)
>
> ** What is the Acceptable Use Policy (AUP) for co-located consu-
> mers?
>
> The AUP for co-located consumers is usually different from that
>used by connectivity consumers.
>
>4.2. Physical Security
>
> ** What forms of physical security are provided for your equip-
> ment?
>
> ** What forms of supervision are provided while visiting your
> equipment?
>
> Ideally you and each other consumer 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 consumer would be allowed access to their own cage under
>escort by one of the ISP's employees, by a guard, with keys or elec-
>tronic access control that grant access specifically to their 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
>consumers very closely. However this may be insufficient to prevent
>mishaps such as the accidental disconnection of another consumer's
>equipment. If a single machine room is used then the ISP should provide
>separate locking cabinets for each co-location consumer 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
>consumer.
>
>4.3. Layer 1 Security
>
> ** How is co-located equipment protected electrically from other
> consumer's co-located equipment?
>
> Also of importance is "layer 1" security of co-located equipment.
>Other consumers 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
>
>
>
>Hansen [Page 12]
>
>Internet Draft Security Checklist for ISP Consumers June 25, 1999
>
>
>separate breakers and circuits for each consumer, or by overbuilding the
>power system and keeping track of the power ratings of all equipment in
>use.
>
>4.4. Layer 2 Security
>
> ** How is co-located equipment protected on the network from
> other consumer's co-located equipment?
>
> 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 consumer or the ISP
>themselves. It's common for crackers to exploit weak security or unen-
>crypted remote logins on co-located consumer-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. The use of a switch
>is generally recommended for this sort of thing.
>
>5. 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.
>
> [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles
> and Functions", RFC 2142, May 1997.
>
> [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September
> 1997.
>
>6. Acknowledgements
>
> This document is the product of input from many people and many
>sources. 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, Bill Woodcock and Chris Kuivenhoven are gratefully ack-
>nowledged.
>
>7. Security
>
> This entire document discusses security issues.
>
>
>
>Hansen [Page 13]
>
>Internet Draft Security Checklist for ISP Consumers June 25, 1999
>
>
>8. Author's Address
>
>Tony Hansen
>AT&T Laboratories
>Lincroft, NJ 07738
>USA
>
>Phone: +1 732 576-3207
>E-Mail: tony@att.com
>
>9. Full Copyright Statement
>
> Copyright (C) The Internet Society (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.
>
> This document expires December 1999.
>
>
>
>
>
>
>
>
>
>
>
>
>
>Hansen [Page 14]
>
>Appendix A Security Checklist for ISP Consumers June 25, 1999
>
>
> Appendix A - Collected Questions
>
>2. Concerns Specific to Connectivity Service Consumers
>
>2.1. Policies
>
>2.1.1. Security Policy
>
> ** Does the ISP have a written Security Policy?
>
> ** If so, how can you receive a copy of it?
>
>2.1.2. Appropriate Use Policy
>
> ** Does the ISP have a written Acceptable Use Policy (AUP)?
>
> ** If so, how can you receive a copy of it?
>
>2.1.3. Sanctions
>
> ** If there is an AUP, what sanctions will be enforced in the
> event of inappropriate behaviour?
>
>2.1.4. Announcement of Policies
>
> ** If the AUP changes, will you be notified of changes to it, and
> if so, how?
>
>2.2. Incident Handling
>
>2.2.1. ISPs and Security Incident Response Teams
>
> ** Does the ISP have a Security Incident Response Team (SIRT)?
>
> ** If so,
>
> ** What is the charter, policies and services of the
> team?
>
> ** What is the escalation chain that I would follow?
>
> ** Is it published somewhere (on the web)?
>
> ** What is the cost of using the SIRT's different ser-
> vices?
>
> ** If not,
>
>
>
>
>Hansen [Page 15]
>
>Appendix A Security Checklist for ISP Consumers June 25, 1999
>
>
> ** What role will the ISP take in response to a secu-
> rity incident?
>
> ** Is there another SIRT to whom you can turn?
>
> ** What other security resources are available from the ISP?
>
> ** If so, at what cost?
>
> ** What other security-related services are available from the
> ISP?
>
> ** If so, at what cost?
>
>2.2.2. Assistance with Inbound Security Incidents
>
> ** Will the ISP inform you of attacks against you?
>
> ** Will the ISP provide assistance to trace an attack?
>
> ** Will the ISP collect and protect evidence of the incident?
>
> ** Will the ISP guard against destruction of such evidence?
>
> ** Will the ISP guard against unintentional announcement of such
> evidence.
>
>2.2.3. Notification of Vulnerabilities and Reporting of Incidents
>
> ** What information will the ISP make available to you as secu-
> rity vulnerabilities are discovered in their services?
>
> ** Will they be proactive or reactive in informing you?
>
> ** How and where will that information be communicated to you?
>
> ** What information will be included in such reports?
>
>2.2.4. Contact Information
>
> ** Who should you contact via email for network security issues?
>
> ** Who should you contact via email to report inappropriate pub-
> lic behaviour?
>
> ** Who should you contact via email for issues relating to net-
> work infrastructure?
>
>
>
>
>Hansen [Page 16]
>
>Appendix A Security Checklist for ISP Consumers June 25, 1999
>
>
> ** Who should you contact via email for network security issues?
>
> ** ???? Anything else from the email list?
>
>2.2.5. After Hours
>
> ** What are the hours of operation of customer support or opera-
> tions personnel?
>
> ** If reduced support is available "after hours", how can support
> personnel be reached in the case of a security incident?
>
>2.2.6. Communication and Authentication
>
> ** How would your ISP communicate with you if a security incident
> were to occur?
>
> ** What information would be communicated with others?
>
>2.3. Layer 2 Security
>
> ** What measures do you take to prevent traffic taking unauthor-
> ised routes into or via your network?
>
> ** Are the networks that support your connectivity consumers and
> your hosting consumers segmented?
>
> ** What general measures do you take to protect your Internet
> facing equipment providing production services from denial of
> service attacks, break-ins or spoofing?
>
>2.4. Security Patches
>
> ** Is the ISP up-to-date in applying security patches to their
> software/firmware running on their production equipment?
>
>2.5. Other Security Services
>
> ** Are port scan audits ever performed on consumer's networks and
> abnormal findings reported to the consumer?
>
> ** If so, how much does it cost?
>
> ** Is additional support available for auditing and securing your
> hosts?
>
> ** If so, how much does it cost?
>
>
>
>
>Hansen [Page 17]
>
>Appendix A Security Checklist for ISP Consumers June 25, 1999
>
>
> ** Does the ISP have a monitoring system that detects host
> attacks or network attacks in realtime?
>
> ** Would it be possible to test the ISP's security by mounting a
> deliberate attack at a mutually agreed time?
>
>2.6. References
>
> ** Will the ISP provide a list of reference customers?
>
>3. Concerns Specific to Hosting Service Consumers
>
>3.1. Acceptable Use Policy (AUP)
>
> ** What is the Acceptable Use Policy (AUP) for web content hosted
> by the ISP?
>
>3.2. Physical Security
>
> ** What is the physical security of the machines used for host-
> ing?
>
>3.3. Backups
>
> ** How often are backups of your web content performed?
>
> ** How often are off-site backup services used?
>
>3.4. Allocation of Network Capacity
>
> ** Does the ISP provide any sort of load balancing to prevent
> saturation of the network capacity by other customers of the
> ISP?
>
>3.5. Spare Facilities
>
> ** What kind of spare facilities are available for use should an
> incident occur?
>
> ** How fast can they be deployed?
>
>3.6. Managed Security Services
>
> ** Does the ISP provide a managed security service?
>
>3.7. Content Management
>
> ** What kind of access is provided to the machine for managing
>
>
>
>Hansen [Page 18]
>
>Appendix A Security Checklist for ISP Consumers June 25, 1999
>
>
> your content?
>
> ** What kind of content is permitted to be hosted?
>
>3.8. Secure Web Servers
>
> ** Does the ISP provide secure web servers (https)?
>
> ** If so, is their host certificate issued by a well-known Certi-
> ficate Authority (CA)?
>
> ** Is the content provided by the secure web servers well
> separated from that available on their non-secure web server?
>
> ** Is the content provided by the secure web servers inaccessible
> by other customers?
>
> ** How would you upload content to the secure web servers?
>
>4. Concerns Specific to Co-location Consumers
>
>4.1. Acceptable Use Policy (AUP)
>
> ** What is the Acceptable Use Policy (AUP) for co-located consu-
> mers?
>
>4.2. Physical Security
>
> ** What forms of physical security are provided for your equip-
> ment?
>
> ** What forms of supervision are provided while visiting your
> equipment?
>
>4.3. Layer 1 Security
>
> ** How is co-located equipment protected electrically from other
> consumer's co-located equipment?
>
>4.4. Layer 2 Security
>
> ** How is co-located equipment protected on the network from
> other consumer's co-located equipment?
>
>
>
>
>
>
>
>
>Hansen [Page 19]