Internet Draft						       T. Hansen
draft-ietf-grip-user-01.txt
draft-ietf-grip-user-02.txt			       AT&T Laboratories
Valid for six months					     T.	Killalea
							January	31,
							   June	25, 1999

			 Security Expectations Checklist for
		    Internet Service Provider (ISP)
			       Consumers

		     <draft-ietf-grip-user-01.txt>

		     <draft-ietf-grip-user-02.txt>

			 Author's version: 1.7 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."

     To	 view  the

     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,   see 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	information to	a checklist for	the gen-
eral  Internet	community	regarding  to use when discussing security expectations	of with	Internet Ser-
vice
Service	Providers (ISPs).

     It	is not the intent of this document to define a set  of	require-
ments  that would be appropriate for all ISPs, but rather to provide the
community with  These questions can serve as	a framework  for
discussion of security expectations with current and prospective service

providers.

     This document is written from  the	 perspective  of  the  consumer.
Companion documents provide information	from the ISP perspective.

1.  Introduction

     The purpose of this  document,  and  its  companions  [RFCisp]  and
[RFCsshadd], document is to express	provide	a checklist for	the general gen-
eral  Internet	community's expectations
of	community  to use when discussing security with	Internet
Service	Providers (ISPs) with respect to security.

     A goal is that customers could have (ISPs).  These questions can serve as	a framework to	 facilitate  the  for
discussion of security expectations with current and prospective service providers; regrettably,
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  hopes  and
expects 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.

     This  document  is	 addressed  to	 Internet   service   purchasing
decision-makers	(customers).	 It has	been argued that vendors
begin to care about security only when prompted	by customers. 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  community  com-
munity and its ISPs will be increased.

     Three types of customers

     Note that these are considered in	 this  document:   first
connectivity  customers,  then hosting customers, broad categories and finally co-located
customers.

1.1.  Conventions Used in this Document

     The key words "REQUIRED", "MUST",	"MUST  NOT",  "SHOULD",	 "SHOULD
NOT",  and  "MAY" in this document are to be interpreted individual  consumers  may
not  fall exactly into these categories; as described in
"Key words for use in RFCs such, not all questions will
apply to Indicate Requirement Levels" [RFC2119].

2.  Incident Response

     A Security	Incident Response Team (SIRT) is a team	 that  performs,
coordinates, all consumers,	nor will all questions apply to	all ISPs.

     Companion documents, [RFCisp] and  supports [RFCsshadd], express the  response  to	security  incidents that
involve	sites within a defined constituency.  The	 general
Internet community's expectations of	SIRTs are described in [BCP21].

2.1.  ISPs and Security	Incident Response Teams

     Some ISPs with respect to security.

     The questions have Security Incident Response Teams  (SIRTs).	 However
it should not be assumed that either	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's connectivity customers or ISP have a site being attacked by written Security Policy?

     **	  If so, how can you receive a customer copy of that ISP	can automatically  avail it?

     A Security	Policy covers such issues  as  privacy,	 authentication,
accountability,	  application  of the services  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's SIRT. ISP	SIRTs are frequently provided as
an added-cost service, have a written Acceptable Use Policy (AUP)?

     **	  If so, how can you receive a copy of it?

     When you establish	a contract with the	team defining as their constituency only
those  who  specifically  subscribe	your ISP to	 (and  perhaps pay for)	Incident
Response services.

     Some providers go even further and	offer services such  as	 Virtual
Private	 Network  (VPN)	 and  firewall	management, as well as intrusion
detection for a	substantial fee.

     Thus it's important provide connectivity
to determine what incident response  and  secu-
rity  resources  the	Internet, most contracts are available to you, and define your incident	response
escalation chain BEFORE governed by an incident occurs.

     You Appropriate	Use Pol-
icy (AUP).  An AUP should	find out if your ISP has a SIRT,  and  if  so clearly identify what  the
charter,  policies	you may	and	services may	 not  do
on  the	 various components of that team are.  (This information is
best expressed using the  SIRT	template  as  shown  in	 Appendix  D system or network, including	the type
of
[BCP21].)

     If traffic allowed on the ISP	doesn't	have a SIRT, you networks.  The AUP should	find out what  role,  if
any,  they  WILL  take in response be	as  explicit  as
possible 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 avoid ambiguity or one-time basis.

2.2.  Assistance with Inbound Security Incidents

     When a security incident targeting	one of their connectivity custo-
mers  occurs, misunderstanding.

     The AUP should be reviewed	each time you renew your contract.   You
should	also expect your ISP to inform	proactively notify you of the attack,
provide	assistance to trace the	attack,	and collect and	protect	evidence
of  the	 incident  and	guard  against	its destruction	or unintentional
announcement. as their	policies
are updated.

2.1.3.	Sanctions

     **	  If there is an AUP, what sanctions will  be  enforced	 in  the
	  event continues, you may ask the	ISP  to	 provide
logging	of inappropriate behaviour?

     An	AUP should be clear in stating what sanctions will  be	enforced
in order to further diagnose  the problem, or to perform filter-
ing of certain types	 event	of	traffic. inappropriate behaviour.  You should	ask	also expect your
ISP what information they will	be able	to  give
out  if	another	customer is the	party attacking	you to determine whether
or not their response is acceptable be forthcoming in announcing to you.   Some  providers  may  give
this  information  freely, while others	will not release the identity community when such sanctions
are imposed.

2.1.4.	Announcement of	Policies

     **	  If the attacker without a court order.

2.3.  Notification AUP changes, will you be notified of Vulnerabilities changes to it, and Reporting of Incidents
	  if so, how?

     You should	expect your ISP	to be  proactive  in  notifying	 you  of publish their security  vulnerabilities and  appropri-
ate  use  policies  in the services they provide.	 In addition, a public	place such 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 web	site.  This way,
the community can be aware of  an  ISP's
infrastructure,	your what the ISP SHOULD	promptly report	to you:

     -	  who is coordinating response considers appropriate and can
know what actions to expect in the incident

     -	  the vulnerability

     -	  how service was affected

     -	  what event of inappropriate behaviour.

2.2.  Incident Handling

     A Security	Incident Response Team (SIRT) is being	done to	respond a team	 that  performs,
coordinates,  and  supports  the  response  to	security  incidents that
involve	sites within a defined constituency.  The  Internet  community's
expectations of	SIRTs are described in [BCP21].

2.2.1.	ISPs and Security Incident Response Teams

     **	  Does the incident

     -	  whether customer data	may ISP have been compromised

     -	  what a Security Incident	Response Team (SIRT)?

	  **   If so,

	       **   What is being	done to	eliminate the vulnerability

     -	charter, policies and  services	 of  the  expected	 schedule  for	response,  assuming  it	 can  be
	  predicted

     -
		    team?

	       **   What is the trouble ticket number being used to track	escalation chain that I	would follow?

	       **   Is it published somewhere (on the incident  by web)?

	       **   What is the  provider,  or  other  suitable  means	cost of identifying	using the
	  incident at a	later date.

2.4.  Contact Information SIRT's different  ser-
		    vices?

	  **   If	you need to contact someone at your  ISP,  you	should	use not,

	       **   What role will the
address	  SECURITY@your.isp.example   for   network   security	 issues,
ABUSE@your.isp.example	for  issues  relating ISP take	in response to  inappropriate  public
behaviour,  and	 NOC@your.isp.example  for  issues  relating	a  secu-
		    rity incident?

	       **   Is there another SIRT to network
infrastructure.	 ([RFC2142] states  that  sites	 (including  ISPs)  must
maintain  these	 mailboxes,  as	 well  as  additional mailboxes	that whom you can turn?

     **	  What other security resources	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 available from the routing registry [RFC1786].

2.4.1.	After Hours
You should recieve information for reaching customer support  or  opera-
tions personnel	on a 24x7 (24 hours, 7 days per	week) basis. ISP?

	  **   If so, at what cost?

     **	  What other security-related services are  available  from  the ISP
does not maintain 24x7 operations (NOC,	Customer  Support,  etc.)   then
	  ISP?

	  **   If so, at what cost?

     Some ISPs have Security Incident  Response	 Teams	(SIRT's).   Some
don't.	In some  means	ISPs, the SIRT consists	of	 reaching  customer  support  after  hours  for	security
incidents should be relayed to you a single person; in advance.

2.5.  Communication and	Authentication

     You should	expect your ISP 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 have	clear policies and procedures (and perhaps pay for)	Incident  Response  ser-
vices.

     Some of the services provided by  SIRT's  include:	  responding  to
attacks	 on the  sharing  of  information  about a security	incident with you,	ISP's consumers, responding to attacks on other
ISPs or	SIRTs, with law	enforcement, and with	sites by
consumers of the press ISP, Virtual Private Network (VPN) and the	 general

public.	  If  your jurisdiction	permits, you should expect	firewall manage-
ment, and intrusion detection.

     Thus it's important to be able determine what incident response  and  secu-
rity  resources	 are available to
conduct	such communication with you, and define your ISP over a	secure channel.

3.  Policies

3.1.  Security Policy incident	response
escalation chain BEFORE	an incident occurs.  You should	expect	find out if your

ISP	to have  has  a policy with regard to	privacy,
authentication,	accountability,	application of security	patches, availa-
bility  SIRT,  and violations reporting.

     A more detailed discussion	if so what the charter,	policies and services of Security Policy can be found
that team are.	(This information is best expressed using the SIRT  tem-
plate as shown in Appendix D of	[BCP21].)

     If	the
Site Security Handbook [RFC2196].

3.2.  Appropriate Use Policy

     When ISP	doesn't	have a SIRT, you establish 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 contract routine or one-time basis.

2.2.2.	Assistance with	your	Inbound	Security Incidents

     **	  Will the ISP inform you of attacks against you?

     **	  Will the ISP to provide connectivity assistance to  the	Internet, that contract	SHOULD be governed by trace an Appropriate Use
Policy (AUP).  The AUP SHOULD clearly identify what you	may and	may  not
do  on attack?

     **	  Will the  various  components ISP collect and protect evidence of the	system or network, including incident?

     **	  Will the
type ISP guard against destruction of	traffic	allowed	on such evidence?

     **	  Will the networks.  The AUP should be as	explicit
as possible to avoid ambiguity or misunderstanding.

     The AUP should be reviewed	each time ISP guard against unintentional announcement	of  such
	  evidence.

     When a security incident targeting	you occurs,  you renew your contract.   You  should	also  expect
your  ISP  to	proactively notify  inform you as their	policies
are updated.

3.3.  Sanctions

     You should	expect of the AUP attack, provide assistance to be clear  in	stating	 what  sanctions
will  be  enforced  in 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 event of inappropriate behaviour.  You should
also expect your ISP to	be forthcoming provide  logging  in announcing
order  to  further diagnose the  community
when such sanctions are	imposed.

3.4.  Announcement	problem, or to perform filtering of Policies cer-
tain types of traffic.

     You should	expect	ask 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 information they will	be able	to  give
out  if	another	consumer is the ISP considers appropriate and can
know what action	party attacking	you to expect in determine whether
or not their response is acceptable to you.   Some  providers  may  give
this  information  freely, while others	will not release the event identity of inappropriate behaviour.

4.  Network Infrastructure

     Your ISP is responsible for managing
the network infrastructure attacker without a court order.

2.2.3.	Notification of
their portion	Vulnerabilities	and Reporting of Incidents

     **	  What information will	the Internet ISP	make available to you  as  secu-
	  rity vulnerabilities are discovered in such a	way their services?

     **	  Will they be proactive or reactive in	informing you?

     **	  How and where	will that it is:

     -	  reasonably resistant information be communicated to known you?
     **	  What information will	be included in such reports?

     You should	expect your ISP	to be  proactive  in  notifying	 you  of
security  vulnerabilities
     -	  not easily hijacked by attackers for use in subsequent attacks

     -	  capable of preventing	internal illegal  traffic  (bogus  route
	  announcements,  spoofed traffic, etc.) generated by its custo-
	  mers from reaching the global	Internet

5.  Concerns Specific to Hosting Service Customers

     [Ed: this section is totally services they provide.	 In addition, as
new vulnerabilities in systems and needs	lots of	work.]

     If	you software are	hosting	content	on your	ISP, you  have	additional  con-
cerns.

     -	  Generally there is a separate	AUP from that used  for	 connec-
	  tivity customers.

     -	  These	machines may be	housed in unlocked cabinets.   As  such,
	  there	 must  be  tight restrictions as to who	may have access.
	  Electronic access control, guards, video  surveillance,  etc.,	discovered, they  should
indicate whether their services	are  all  fair  game.	  All  visitors	 ESPECIALLY  need threatened by these	risks.

     When security incidents occur that	affect components  of  an  ISP's
infrastructure,	your ISP should	promptly report	to be
	  escorted, as the potential for damage	is much	higher than in a
	  colocation situation. you:

     -	  As the customer	  who is not generally responsible for securing  the
	  operating   system  or  applications,	 there	needs coordinating response to  be  a
	  heightened understanding of how the ISP reacts. incident

     -	  If you also get connectivity from	  the	ISP (i.e.,  a  T1),  you
	  should  check vulnerability

     -	  how service was affected

     -	  what is being	done to	respond	to see	if security for the managed site incident

     -	  whether customer data	may have been compromised

     -	  what is being	done
	  by a different group and check to see	if	eliminate the	 procedures  for
	  reporting and	notification are much different. vulnerability

     -	  A modality	  the  expected	 schedule  for backups must	response,  assuming  it	 can  be included, as
	  predicted

     -	  the  ISP	will  be
	  doing trouble ticket number being used to track	the  majority	of these.  Most	providers also have off-
	  site backup services.

     -	  Other	customers may legitimately cause  a  denial  of	 service
	  attack incident  by  hogging  all
	  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 capacity.  Providers security	issues?

     **	  Who should have standards	as far as how saturated	 their	networks
	  may get, and you contact via email to report inappropriate  pub-
	  lic behaviour?

     **	  Who should prevent this from	occurring.

     -	  Cold site facilities,	and hot	spare hardware can be  important
	  when	recovering  from  an incident.	Customers you contact via email for issues relating	to  net-
	  work infrastructure?

     **	  Who should inquire
	  with you contact via email for network security	issues?

     **	  ???? Anything	else from the ISP if this is important email list?

     If	you need to them.

     -	  Providers contact someone at your  ISP,  you	should do a	good deal of proactive testing	against,
	  and active patching of	use  the OS
address	  SECURITY@your.isp.example   for   network   security	 issues,
ABUSE@your.isp.example	for  issues  relating  to  inappropriate  public
behaviour,  and application	loads.	As	 NOC@your.isp.example  for  issues  relating  to network
infrastructure.	 ([RFC2142] states that	sites  (including  ISPs)  should

maintain  these
	  loads	tend	 mailboxes,  as	 well  as  additional mailboxes	that are
defined	for receiving queries and  reports  relating  to	be the same from customer  specific  ser-
vices.)	   Your	  ISP	may   also   have   web	 site  addresses  (e.g.,
http://www.your.isp.example/security/) that you	may  use  to customer,  check  for
expanded  details on the  ISP above.	 You should also be responsible	in assuring host based security.

     -	  Many providers offer a managed security service for additional
	  fees.	  Customers  are encouraged able to find out	what is	included contact
information for	your ISP in Whois and in the service that  they routing registry [RFC1786].

2.2.5.	After Hours

     **	  What are  paying  for,	and  to	 explore
	  options as far as what they can do.

     -	  Generally there is option of whether or not the hours of	operation of customer  even
	  has root privs.

6.  Concerns Specific to Co-location Customers support or  opera-
	  tions	personnel?

     **	  If	you have co-located equipment at your ISP's facility, reduced support is	available "after hours", how can support
	  personnel be reached in the physi-
cal  security case of the installation a	security incident?

     You should be given appropriate considera-
tion.  This is particularly so	recieve	information for co-located facilities to which people
from  different	 organisations and	 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	different you if a security policies have
access.	 Many issues arise surrounding	customer  access	incident
	  were to  their  co-
located	equipment.

6.1.  Acceptable Use Policy
The AUP	for co-located customers is usually different from that	used  by
connectivity customers. occur?

     **	  What information would be communicated with others?

     You should inquire about the AUP.

6.2.  Separated	Equipment

     Ideally you and each other	customer SHOULD	have  a	 fully	enclosed
locking	 'cage',  akin	expect your ISP	to have	clear policies and procedures on
the  sharing  of  information  about a small room security	incident with walls you, other
ISPs or	SIRTs, with law	enforcement, and	ceiling	of heavy
wire mesh fencing, containing with the racks	 in  which  their  equipment  is
mounted.   Each	customer would press	and the	 general
public.	  If  your jurisdiction	permits, you should expect to be allowed access able to their own cage under
escort by one of the ISP's employees, by a guard,
conduct	such communication with	 keys	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  elec-
tronic	access	control via your network?

     **	  Are the networks that grant access specifically	support	your connectivity consumers  and
	  your hosting consumers segmented?

     **	  What general measures	do you take  to their	cage,	 protect  your	Internet
	  facing  equipment providing production services from denial of
	  service attacks, break-ins or
some combination thereof.

     This assignment	spoofing?

     Most ISPs have firewalls of	separate cages is expensive in	terms one kind or another that prevent random

packets	from flowing through their network from	the Internet.

     Methods of  space
however,  so  many  ISPs  compromise by	putting	all co-located equipment
together in a single machine room,	segmenting networks include VLANs and managing	the actions of	escorted
customers  very	 closely.   However  this may be insufficient to non-broadcast net-
works.	These can prevent
mishaps	such as	 the  accidental  disconnection	 of one consumer class from affecting another  customer's
equipment.  If a single	machine	room is	used then con-
sumer class.

2.4.  Security Patches

     **	  Is the ISP SHOULD provide
separate locking cabinets for each co-location customer up-to-date	in preferance applying security  patches  to
an  open  common  area.	  Another  alternative	are  cabinets  which can
separate all of	 the  facilities  within  their
	  software/firmware running on their production	equipment?

     Information about available security patches is  readily  available
from	the  same  cabinet,  and  have
independent locking mechanisms    Center	 for each	portion	of the rack.   Emergency   Response   Team   (CERT)   at
http://www.cert.org.  You should	expect can use telnet to connect to always be supervised	while  in the	physical
presence port	 numbers
of any	equipment that is not yours,  public  TCP-based services (SMTP, POP, IMAP, HTTP, etc.) provided by
the ISP, and should	not expect to 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
allowed useful.

     **	  Are port scan	audits ever performed on consumer's networks and
	  abnormal findings reported to touch, photograph,	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 examine equipment belonging network attacks in	realtime?

     **	  Would	it be possible to	 another
customer.

6.3.  Layer 1 Security

     Also of importance	is "layer 1" security of  co-located  equipment.
Other  customers should	not blow test the same fuse that you	are on ISP's security by power-
ing all	their machines up mounting  a
	  deliberate attack at once.  The a mutually agreed time?

     Audits run	by the ISP provide tests of your  own  host's  security.
These can	control	this  by  having
separate breakers and circuits be useful for each	customer, or by	overbuilding	plugging holes on your systems.

     Probes of the
power system and keeping track 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 power ratings of all equipment  in
use.

6.4.  Layer 2 Security

     Also of concern is	layer 2 ISP's	 security  only	 with  their  knowledge.
Freely	available  tools,  such	 as  ping,  traceroute,	SATAN and mscan,
attempt	a variety of co-located equipment.   Your
equipment SHOULD NOT probes.  Most ISP's monitoring systems will pick up
such   probes.	  Useful  tools	 of  this  sort	 can  be	allowed	to share  obtained  from
ftp://ftp.cert.org.

2.6.  References

     **	  Will the ISP provide a physical network segment with
hosts belonging	to anyone else,	whether	 another  customer  or list of reference customers?

     If	the ISP
themselves.   It's common for crackers	lets you speak with some reference customers, you  might
ask  them  about problems with respect to exploit weak security the reporting	or unen-
crypted	remote logins on co-located  customer-owned  equipment	to  take
control resolution of that equipment and put it into promiscuous listening mode on
the local network segment, thereby potentially compromising
any security incidents,	as well	as  the	 privacy
and	 security of any other devices  services  and  advice
offered	to them	by the ISP.

3.  Concerns Specific to Hosting Service Consumers

     If	you are	hosting	content	on that segment.  The use of	a switch your	ISP, you  have	additional  con-
cerns.

3.1.  Acceptable Use Policy (AUP)

     **	  What is generally recommended the Acceptable Use Policy (AUP) for this sort of thing.

7.  References

     [BCP21]   Brownlee, N and E. Guttman,  "Expectations web content hosted
	  by the ISP?

     Generally there is	a separate AUP from that used  for	Computer  connectivity
consumers.

3.2.  Physical 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

     **	  What is the physical security	of IP Routing  Policies	in  a  Routing	Registry  (ripe-
	       81++)", RFC 1786, March 1995.

     [RFC2119] Bradner,	S., "Key words the machines	used  for  use  host-
	  ing?

     Machines used for hosting may be housed in  RFCs	unlocked  cabinets.   As
such, there must be tight restrictions as to	Indicate
	       Requirement Levels", RFC	2119, March 1997.

     [RFC2142] Crocker,	D., "Mailbox Names 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	Common	Services,  Roles
	       and Functions", RFC 2142, May 1997.

     [RFC2195] Klensin,	J.,  Catoe,  R.,  and  P.  Krumviede,  "IMAP/POP
	       AUTHorize  Extension
damage is much higher than in a	colocation situation.

     As	the consumer is	 not  generally	 responsible  for Simple	Challenge/Response", RFC
	       2195, September 1997.

     [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, September
	       1997.

8.  Acknowledgements

     We	gratefully acknowledge  securing  the constructive	comments  received
operating  system or applications, there needs to be a heightened under-
standing of how	the ISP	reacts.

     If	you also get connectivity 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.

9.  Security

     This entire document discusses the ISP (i.e., a	T1), you  should
check  to  see	if  security issues.

10.  Authors' Addresses

Tony Hansen
AT&T Laboratories
Lincroft, NJ 07738
USA

Phone: +1 732 576-3207
E-Mail:	tony@att.com

Tom Killalea
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.

     This document for the managed site is done by a different
group and translations 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.

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?
     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.

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

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.

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.

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 it may	operation of customer support or  opera-
	  tions	personnel?

     **	  If reduced support is	available "after hours", how can support
	  personnel be copied reached in the case of a	security incident?

2.2.6.	Communication and furnished Authentication

     **	  How would your ISP communicate with you if a security	incident
	  were to
others,	 and derivative	works that comment on 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 otherwise explain it 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
assist	spoofing?

2.4.  Security Patches

     **	  Is the ISP up-to-date	in its implmentation may	be prepared, copied, published 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  dis-
tributed, in whole
	  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 part, without restriction	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 any kind,	provided
that reference customers?

3.  Concerns Specific to Hosting Service Consumers

3.1.  Acceptable Use Policy (AUP)

     **	  What is 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 Acceptable Use Policy (AUP) for web content hosted
	  by  removing the  copyright  notice  or
references 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  Internet  Society	or network capacity by other Internet organisations,
except as needed	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 purpose ISP provide a managed security service?

3.7.  Content Management

     **	  What kind of  developing	 Internet  standards  in
which  case access is provided to the procedures  machine  for	copyrights defined in the Internet Stan-
dards process must be followed,	or as  required	managing

Appendix A	  Security Checklist for ISP Consumers	   June	25, 1999

	  your content?

     **	  What kind of content is permitted to  translate	it  into
languages other	than English.

     The limited permissions granted above are perpetual and will not be
revoked 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 Internet	Society	or its successors or assigns.

     This document and  content  provided  by	 the information contained herein  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
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 August 1999.  the  network  from
	  other	consumer's co-located equipment?