draft-ietf-grip-user-01.txt   draft-ietf-grip-user-02.txt 
Internet Draft T. Hansen Internet Draft T. Hansen
draft-ietf-grip-user-01.txt AT&T Laboratories draft-ietf-grip-user-02.txt AT&T Laboratories
Valid for six months T. Killalea Valid for six months
January 31, 1999 June 25, 1999
Security Expectations for Internet Service Provider Consumers Security Checklist for
Internet Service Provider (ISP)
Consumers
<draft-ietf-grip-user-01.txt> <draft-ietf-grip-user-02.txt>
Author's version: 1.7 Author's version: 1.11
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents at months and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see 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. http://www.ietf.org/shadow.html.
This memo and its companions are discussed on the GRIP working This memo and its companions are discussed on the GRIP working
group mailing list, grip-wg[-request]@uu.net. group mailing list, grip-wg[-request]@uu.net.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
The purpose of this document is to provide information to the gen- The purpose of this document is to provide a checklist for the gen-
eral Internet community regarding security expectations of Internet Ser- eral Internet community to use when discussing security with Internet
vice Providers (ISPs). Service Providers (ISPs). These questions can serve as a framework for
discussion of security expectations with current and prospective service
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. providers.
Companion documents provide information from the ISP perspective.
1. Introduction 1. Introduction
The purpose of this document, and its companions [RFCisp] and The purpose of this document is to provide a checklist for the gen-
[RFCsshadd], is to express the general Internet community's expectations eral Internet community to use when discussing security with Internet
of Internet Service Providers (ISPs) with respect to security. 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.
A goal is that customers could have a framework to facilitate the This document is addressed to Internet service purchasing
discussion of security with prospective service providers; regrettably, decision-makers (consumers). Three types of consumers are considered in
such a discussion rarely takes place today. this document: connectivity consumers, hosting service consumers, and
co-located consumers.
Additionally, in informing ISPs of what the community hopes and Additionally, in informing ISPs of what the community will be ask-
expects of them, a further goal is to encourage ISPs to become proactive ing of them, a further goal is to encourage ISPs to become proactive in
in making security not only a priority, but something to which they making security not only a priority, but something to which they point
point with pride when selling their services. 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.
This document is addressed to Internet service purchasing Note that these are broad categories and individual consumers may
decision-makers (customers). not fall exactly into these categories; as such, not all questions will
apply to all consumers, nor will all questions apply to all ISPs.
It has been argued that vendors begin to care about security only Companion documents, [RFCisp] and [RFCsshadd], express the general
when prompted by customers. We hope that these documents will encourage Internet community's expectations of ISPs with respect to security.
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 The questions have been collected together into Appendix A for easy
connectivity customers, then hosting customers, and finally co-located reference.
customers.
1.1. Conventions Used in this Document 2. Concerns Specific to Connectivity Service Consumers
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 2.1. Policies
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 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
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, A Security Incident Response Team (SIRT) is a team that performs,
coordinates, and supports the response to security incidents that coordinates, and supports the response to security incidents that
involve sites within a defined constituency. The Internet community's involve sites within a defined constituency. The Internet community's
expectations of SIRTs are described in [BCP21]. expectations of SIRTs are described in [BCP21].
2.1. ISPs and Security Incident Response Teams 2.2.1. ISPs and Security Incident Response Teams
Some ISPs have Security Incident Response Teams (SIRTs). However ** Does the ISP have a Security Incident Response Team (SIRT)?
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 ** If so,
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 ** What is the charter, policies and services of the
Private Network (VPN) and firewall management, as well as intrusion team?
detection for a substantial fee.
** 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- Thus it's important to determine what incident response and secu-
rity resources are available to you, and define your incident response rity resources are available to you, and define your incident response
escalation chain BEFORE an incident occurs. escalation chain BEFORE an incident occurs. You should find out if your
You should find out if your ISP has a SIRT, and if so what the ISP has a SIRT, and if so what the charter, policies and services of
charter, policies and services of that team are. (This information is that team are. (This information is best expressed using the SIRT tem-
best expressed using the SIRT template as shown in Appendix D of plate as shown in Appendix D of [BCP21].)
[BCP21].)
If the ISP doesn't have a SIRT, you should find out what role, if 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 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 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- 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- tract these services from third-party companies to perform these ser-
vices on a routine or one-time basis. vices on a routine or one-time basis.
2.2. Assistance with Inbound Security Incidents 2.2.2. Assistance with Inbound Security Incidents
When a security incident targeting one of their connectivity custo- ** Will the ISP inform you of attacks against you?
mers occurs, you should expect your ISP to inform you of the attack,
provide assistance to trace the attack, and collect and protect evidence ** Will the ISP provide assistance to trace an attack?
of the incident and guard against its destruction or unintentional
announcement. If the event continues, you may ask the ISP to provide ** Will the ISP collect and protect evidence of the incident?
logging in order to further diagnose the problem, or to perform filter-
ing of certain types of traffic. ** 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 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 out if another consumer is the party attacking you to determine whether
or not their response is acceptable to you. Some providers may give or not their response is acceptable to you. Some providers may give
this information freely, while others will not release the identity of this information freely, while others will not release the identity of
the attacker without a court order. the attacker without a court order.
2.3. Notification of Vulnerabilities and Reporting of Incidents 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?
You should expect your ISP to be proactive in notifying you of You should expect your ISP to be proactive in notifying you of
security vulnerabilities in the services they provide. In addition, as security vulnerabilities in the services they provide. In addition, as
new vulnerabilities in systems and software are discovered, they should new vulnerabilities in systems and software are discovered, they should
indicate whether their services are threatened by these risks. indicate whether their services are threatened by these risks.
When security incidents occur that affect components of an ISP's When security incidents occur that affect components of an ISP's
infrastructure, your ISP SHOULD promptly report to you: infrastructure, your ISP should promptly report to you:
- who is coordinating response to the incident - who is coordinating response to the incident
- the vulnerability - the vulnerability
- how service was affected - how service was affected
- what is being done to respond to the incident - what is being done to respond to the incident
- whether customer data may have been compromised - whether customer data may have been compromised
- what is being done to eliminate the vulnerability - what is being done to eliminate the vulnerability
- the expected schedule for response, assuming it can be - the expected schedule for response, assuming it can be
predicted predicted
- the trouble ticket number being used to track the incident by - the trouble ticket number being used to track the incident by
the provider, or other suitable means of identifying the the provider, or other suitable means of identifying the
incident at a later date. incident at a later date.
2.4. Contact Information 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 If you need to contact someone at your ISP, you should use the
address SECURITY@your.isp.example for network security issues, address SECURITY@your.isp.example for network security issues,
ABUSE@your.isp.example for issues relating to inappropriate public ABUSE@your.isp.example for issues relating to inappropriate public
behaviour, and NOC@your.isp.example for issues relating to network behaviour, and NOC@your.isp.example for issues relating to network
infrastructure. ([RFC2142] states that sites (including ISPs) must infrastructure. ([RFC2142] states that sites (including ISPs) should
maintain these mailboxes, as well as additional mailboxes that are maintain these mailboxes, as well as additional mailboxes that are
defined for receiving queries and reports relating to specific ser- defined for receiving queries and reports relating to specific ser-
vices.) Your ISP may also have web site addresses (e.g., vices.) Your ISP may also have web site addresses (e.g.,
http://www.your.isp.example/security/) that you may use to check for 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 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]. information for your ISP in Whois and in the routing registry [RFC1786].
2.4.1. After Hours 2.2.5. 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 ** 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 You should expect your ISP to have clear policies and procedures on
the sharing of information about a security incident with you, other the sharing of information about a security incident with you, other
ISPs or SIRTs, with law enforcement, and with the press and the general 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 public. If your jurisdiction permits, you should expect to be able to
conduct such communication with your ISP over a secure channel. conduct such communication with your ISP over a secure channel (e.g.,
secure web, secure Email, telephone, attended fax, etc.).
3. Policies 2.3. Layer 2 Security
3.1. Security Policy ** What measures do you take to prevent traffic taking unauthor-
ised routes into or via your network?
You should expect your ISP to have a policy with regard to privacy, ** Are the networks that support your connectivity consumers and
authentication, accountability, application of security patches, availa- your hosting consumers segmented?
bility and violations reporting.
A more detailed discussion of Security Policy can be found in the ** What general measures do you take to protect your Internet
Site Security Handbook [RFC2196]. facing equipment providing production services from denial of
service attacks, break-ins or spoofing?
3.2. Appropriate Use Policy Most ISPs have firewalls of one kind or another that prevent random
When you establish a contract with your ISP to provide connectivity packets from flowing through their network from the Internet.
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 Methods of segmenting networks include VLANs and non-broadcast net-
should also expect your ISP to proactively notify you as their policies works. These can prevent one consumer class from affecting another con-
are updated. sumer class.
3.3. Sanctions 2.4. Security Patches
You should expect the AUP to be clear in stating what sanctions ** Is the ISP up-to-date in applying security patches to their
will be enforced in the event of inappropriate behaviour. You should software/firmware running on their production equipment?
also expect your ISP to be forthcoming in announcing to the community
when such sanctions are imposed.
3.4. Announcement of Policies 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.
You should expect your ISP to publish their security and appropri- 2.5. Other Security Services
ate use policies in a public place such as their web site. This way, For the really serious consumer, additional services may be useful.
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 ** Are port scan audits ever performed on consumer's networks and
abnormal findings reported to the consumer?
Your ISP is responsible for managing the network infrastructure of ** If so, how much does it cost?
their portion of the Internet in such a way that it is:
- reasonably resistant to known security vulnerabilities ** Is additional support available for auditing and securing your
- not easily hijacked by attackers for use in subsequent attacks hosts?
- capable of preventing internal illegal traffic (bogus route ** If so, how much does it cost?
announcements, spoofed traffic, etc.) generated by its custo-
mers from reaching the global Internet
5. Concerns Specific to Hosting Service Customers ** Does the ISP have a monitoring system that detects host
attacks or network attacks in realtime?
[Ed: this section is totally new and needs lots of work.] ** 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.
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- If you are hosting content on your ISP, you have additional con-
cerns. cerns.
- Generally there is a separate AUP from that used for connec- 3.1. Acceptable Use Policy (AUP)
tivity customers.
- These machines may be housed in unlocked cabinets. As such, ** What is the Acceptable Use Policy (AUP) for web content hosted
there must be tight restrictions as to who may have access. by the ISP?
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 Generally there is a separate AUP from that used for connectivity
operating system or applications, there needs to be a consumers.
heightened understanding of how the ISP reacts.
- If you also get connectivity from the ISP (i.e., a T1), you 3.2. Physical Security
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 ** What is the physical security of the machines used for host-
doing the majority of these. Most providers also have off- ing?
site backup services.
- Other customers may legitimately cause a denial of service Machines used for hosting may be housed in unlocked cabinets. As
attack by hogging all of the network capacity. Providers such, there must be tight restrictions as to who may have access. Elec-
should have standards as far as how saturated their networks tronic access control, guards, video surveillance, etc., are all fair
may get, and should prevent this from occurring. game. All visitors ESPECIALLY need to be escorted, as the potential for
damage is much higher than in a colocation situation.
- Cold site facilities, and hot spare hardware can be important As the consumer is not generally responsible for securing the
when recovering from an incident. Customers should inquire operating system or applications, there needs to be a heightened under-
with the ISP if this is important to them. standing of how the ISP reacts.
- Providers should do a good deal of proactive testing against, If you also get connectivity from the ISP (i.e., a T1), you should
and active patching of the OS and application loads. As these check to see if security for the managed site is done by a different
loads tend to be the same from customer to customer, the ISP group and check to see if the procedures for reporting and notification
should be responsible in assuring host based security. are much different.
- Many providers offer a managed security service for additional Providers should do a good deal of proactive testing against, and
fees. Customers are encouraged to find out what is included active patching of the OS and application loads. As these loads tend to
in the service that they are paying for, and to explore be the same from consumer to consumer, the ISP should be responsible in
options as far as what they can do. assuring host based security.
- Generally there is option of whether or not the customer even 3.3. Backups
has root privs.
6. Concerns Specific to Co-location Customers ** 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?
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- If you have co-located equipment at your ISP's facility, the physi-
cal security of the installation should be given appropriate considera- cal security of the installation should be given appropriate considera-
tion. This is particularly so for co-located facilities to which people tion. This is particularly so for co-located facilities to which people
from different organisations and with different security policies have from different organisations and with different security policies have
access. Many issues arise surrounding customer access to their co- access. Many issues arise surrounding consumer access to their co-
located equipment. located equipment.
6.1. Acceptable Use Policy 4.1. Acceptable Use Policy (AUP)
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 ** What is the Acceptable Use Policy (AUP) for co-located consu-
mers?
Ideally you and each other customer SHOULD have a fully enclosed 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 locking 'cage', akin to a small room with walls and ceiling of heavy
wire mesh fencing, containing the racks in which their equipment is wire mesh fencing, containing the racks in which their equipment is
mounted. Each customer would be allowed access to their own cage under 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- 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 tronic access control that grant access specifically to their cage, or
some combination thereof. some combination thereof.
This assignment of separate cages is expensive in terms of space This assignment of separate cages is expensive in terms of space
however, so many ISPs compromise by putting all co-located equipment however, so many ISPs compromise by putting all co-located equipment
together in a single machine room, and managing the actions of escorted together in a single machine room, and managing the actions of escorted
customers very closely. However this may be insufficient to prevent consumers very closely. However this may be insufficient to prevent
mishaps such as the accidental disconnection of another customer's mishaps such as the accidental disconnection of another consumer's
equipment. If a single machine room is used then the ISP SHOULD provide equipment. If a single machine room is used then the ISP should provide
separate locking cabinets for each co-location customer in preferance to separate locking cabinets for each co-location consumer in preferance to
an open common area. Another alternative are cabinets which can an open common area. Another alternative are cabinets which can
separate all of the facilities within the same cabinet, and have separate all of the facilities within the same cabinet, and have
independent locking mechanisms for each portion of the rack. independent locking mechanisms for each portion of the rack.
You should expect to always be supervised while in the physical 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 presence of any equipment that is not yours, and should not expect to be
allowed to touch, photograph, or examine equipment belonging to another allowed to touch, photograph, or examine equipment belonging to another
customer. consumer.
6.3. Layer 1 Security 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. 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- 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 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
separate breakers and circuits for each consumer, or by overbuilding the
power system and keeping track of the power ratings of all equipment in power system and keeping track of the power ratings of all equipment in
use. use.
6.4. Layer 2 Security 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 Also of concern is layer 2 security of co-located equipment. Your
equipment SHOULD NOT be allowed to share a physical network segment with equipment should not be allowed to share a physical network segment with
hosts belonging to anyone else, whether another customer or the ISP hosts belonging to anyone else, whether another consumer or the ISP
themselves. It's common for crackers to exploit weak security or unen- themselves. It's common for crackers to exploit weak security or unen-
crypted remote logins on co-located customer-owned equipment to take crypted remote logins on co-located consumer-owned equipment to take
control of that equipment and put it into promiscuous listening mode on control of that equipment and put it into promiscuous listening mode on
the local network segment, thereby potentially compromising the privacy the local network segment, thereby potentially compromising the privacy
and security of any other devices on that segment. The use of a switch and security of any other devices on that segment. The use of a switch
is generally recommended for this sort of thing. is generally recommended for this sort of thing.
7. References 5. References
[BCP21] Brownlee, N and E. Guttman, "Expectations for Computer [BCP21] Brownlee, N and E. Guttman, "Expectations for Computer
Security Incident Response", BCP 21, RFC 2350, June 1998. Security Incident Response", BCP 21, RFC 2350, June 1998.
[RFC1786] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., [RFC1786] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M.,
Karrenberg, D., Terpstra, M., and J. Yu, "Representation Karrenberg, D., Terpstra, M., and J. Yu, "Representation
of IP Routing Policies in a Routing Registry (ripe- of IP Routing Policies in a Routing Registry (ripe-
81++)", RFC 1786, March 1995. 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 [RFC2142] Crocker, D., "Mailbox Names for Common Services, Roles
and Functions", RFC 2142, May 1997. 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 [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September
1997. 1997.
8. Acknowledgements 6. Acknowledgements
We gratefully acknowledge the constructive comments received from
Nevil Brownlee, Randy Bush, Bill Cheswick, Barbara Y. Fraser, Randall This document is the product of input from many people and many
Gellens, Erik Guttman, Larry J. Hughes Jr., Klaus-Peter Kossakowski, sources. The constructive comments received from Nevil Brownlee, Randy
Michael A. Patton, Don Stikvoort, Bill Woodcock and Chris Kuivenhoven. 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.
9. Security 7. Security
This entire document discusses security issues. This entire document discusses security issues.
10. Authors' Addresses 8. Author's Address
Tony Hansen Tony Hansen
AT&T Laboratories AT&T Laboratories
Lincroft, NJ 07738 Lincroft, NJ 07738
USA USA
Phone: +1 732 576-3207 Phone: +1 732 576-3207
E-Mail: tony@att.com E-Mail: tony@att.com
Tom Killalea 9. Full Copyright Statement
1516 2nd Ave
Seattle, WA 98101
USA
Phone: +1 206 694-2196
E-Mail: tomk@neart.ie
11. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or others, and derivative works that comment on or otherwise explain it or
assist in its implmentation may be prepared, copied, published and dis- assist in its implmentation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or be modified in any way, such as by removing the copyright notice or
skipping to change at page 10, line 12 skipping to change at page 14, line 42
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE. FITNESS FOR A PARTICULAR PURPOSE.
This document expires August 1999. This document expires December 1999.
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,
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?
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?
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
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?
 End of changes. 84 change blocks. 
198 lines changed or deleted 417 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/