Site security contacts proposal

[J Paul Holbrook <[e-mail]>]

Here's another position statement for the Internet Security Policy
effort.  This one addresses the topic of who has authority and
responsibility at a site to deal with security problems and how does
someone outside that site get in touch with them.

Again, this is just a first cut: fire away, and copy the group.

J. Paul Holbrook
ssphwg co-chair
Internet: <[e-mail]>
[phone]


			SITE SECURITY CONTACTS
		       DRAFT Position Statement
			   J. Paul Holbrook
				6/1/90

In this proposal, I use the term `site' to mean every resource-owning
organization, including regional networks and other entities.  I've
used the terms 'MUST' and 'SHOULD' in capitals to help point out
suggested policy directions.

    [Comments in brackets are notes to help explain the reasoning
     behind some of the statements.  These comments would not appear
     as part of a policy, though they might appear as a commentary
     that goes along with the policy.]


Site Security Contact

Every site MUST have a site security contact.  This may or may not be
the same as the normal site contact or network manager.  A site
security contact can be an individual or an organization.  The site
security contact SHOULD be familiar with the technology and security
of all systems at that site.  If that is not possible, the security
contact MUST be able to get in touch with the people that have this
knowledge 24 hours a day.

    [At the CERT we've been got in touch with sites only to find out
     that they have no idea who is responsible for security or how to
     get in touch with them.]

    [A point of terminology: in his `responsibility' writeup, James
     VanBokkelen refers to `network managers' and `host managers'.
     The site security contact is a peer to the network manager; it
     might even be the same person.  Others in the Internet community
     have used the term `site contact', which I've used because it
     helps to emphasize that a site security contact may have to deal
     with both network and host issues.  Certainly a regional network
     or other network provider can (and should) have a `site security
     contact.'  However, the terminology is certainly open to change.]


Security Contact Availability

The site security contact MUST provide other designated organizations
in the Internet with a 24 hour point of contact.  At a minimum, this
should be a phone number which is answered during `business hours' 5
days a week, and equipped with an answering machine that is checked at
least once every day (including weekends) to cover off hours.  Sites
SHOULD consider providing `real time' response: e.g., home phone
numbers, pager numbers, or other means of contacting people.  However,
being able to get directly in touch with the security contact at any
time is not required.

     [This is a compromise statement; it's hard to require a site to
     provide around-the-clock response without proof that it would be
     worth the cost.  At the CERT we've found almost all problems can
     be dealt with by having a contact who is available during
     business hours.  However, large sites or sites that care about
     the availability and security of their systems will probably want
     to provide 24 hour access to their security contact.]

Sites MUST ensure that some backup security contact can be reached if
the primary security contact is unavailable.  This can take the form
of a secondary contact person or organization.  If outside
organizations must use some different procedure to get to the backup
security contact, sites MUST ensure that these procedures are
communicated to the outside organizations.

The `designated' or `outside' organizations have this contact information
might be a local Network Control Center or Network Information Center,
or might be security response centers such as CERT.  Since
security organizations might need access to this information anytime,
organizations that keep this information MUST make it available 24
hours a day.

    [ The User Connectivity Problem (UCP) working group is working on
    the problem of how to get site contact information propagated
    around so that network problems can be dealt with.  We should
    consider using whatever means they come up with for distributing
    this kind of information.  In any case, the specifics of how this
    works are an operational matter that doesn't belong in a policy. ]


Security Policy Issues

Although the initial response to a security incident is often a
technical one, policy issues also need to be dealt with.  Should an
intruder be shut out or watched?  Should law enforcement be involved?
Should a site disconnect itself from the network to avoid a worm or
intruders?  These decisions are not strictly technical; they may
affect many people.  Sites MUST ensure that people with the authority
to decide these kinds of issues are available in the event of a
serious security problem.

If the site security contact does not have the authority to make these
kinds of decisions, sites are encouraged to have a 24 hour
administrative contact.  (This administrative contact does not need to
be visible to people outside the site.)  Sites SHOULD also have
policies that state who has the authority to make decisions and take
actions in response to security problems, and under what circumstances
administrators or decision makers should be brought in on an active
security incident.  The goal should be that a site security contact
can quickly (i.e., in a few hours) take action to deal with a security
problem, if necessary getting in touch with someone who can authorize
their actions.

At some sites, policy makers could give advance authorization to the
site security contact and other system managers.  For example, the site may
give their technical people the authority and license to make their
best efforts to deal with security problems.  In this case, the policy
also protects the technical people from `retribution' from policy
makers after the fact.


     [The motivation here is that policy makers should be involved
     early on if a serious security incident is underway.  Policy
     makers may have little to do with the day-to-day operation of
     systems, but they will be concerned if a serious security
     incident has serious impact on a site and it's operation.  Among
     other things, if decision makers are not involved and understand
     the nature of security problems, they might impose policies after
     the fact to `deal with the security problem.'  For example, the
     CERT has heard of sites where the local policy maker's response
     to a security incident was to advocate permanently disconnecting
     from the Internet.

     However, since this issue is mostly a matter of site internal
     policies, the Internet Security Policy should not mandate an
     administrative contact.  The Site Security Policy Handbook will
     help flesh out this area by going into detail about how site
     policy makers should be involved in setting security policy and
     procedures.]