Eight weeks later, the authorities call to inform        you the information in one of these newsletters        was used to disable "911" in a major city for        five hours.      - A user calls in to report that he can't login to his        account at 3 o'clock in the morning on a Saturday.  The        system staffer can't login either.  After rebooting to        single user mode, he finds that password file is empty.        By Monday morning, your staff determines that a number        of privileged file transfers took place between this        machine and a local university.        Tuesday morning a copy of the deleted password file is        found on the university machine along with password        files for a dozen other machines.        A week later you find that your system initialization        files had been altered in a hostile fashion.      - You receive a call saying that a breakin to a government        lab occurred from one of your center's machines.  You        are requested to provide accounting files to help        trackdown the attacker.        A week later you are given a list of machines at your        site that have been broken into.       - A reporter calls up asking about the breakin at your         center.  You haven't heard of any such breakin.        Three days later, you learn that there was a breakin.        The center director had his wife's name as a password.Site Security Policy Handbook Working Group                     [Page 6]RFC 1244                 Site Security Handbook                July 1991      - A change in system binaries is detected.        The day that it is corrected, they again are changed.        This repeats itself for some weeks.      - If an intruder is found on your system, should you        leave the system open to monitor the situation or should        you close down the holes and open them up again later?      - If an intruder is using your site, should you call law        enforcement?  Who makes that decision?  If law enforcement asks        you to leave your site open, who makes that decision?      - What steps should be taken if another site calls you and says        they see activity coming from an account on your system?  What        if the account is owned by a local manager?1.7  Basic Approach   Setting security policies and procedures really means developing a   plan for how to deal with computer security.  One way to approach   this task is suggested by Fites, et. al. [3, FITES]:      -  Look at what you are trying to protect.      -  Look at what you need to protect it from.      -  Determine how likely the threats are.      -  Implement measures which will protect your assets in a         cost-effective manner.      -  Review the process continuously, and improve things every time         a weakness is found.   This handbook will concentrate mostly on the last two steps, but the   first three are critically important to making effective decisions   about security.  One old truism in security is that the cost of   protecting yourself against a threat should be less than the cost   recovering if the threat were to strike you.  Without reasonable   knowledge of what you are protecting and what the likely threats are,   following this rule could be difficult.1.8  Organization of this Document   This document is organized into seven parts in addition to this   introduction.   The basic form of each section is to discuss issues that a site might   want to consider in creating a computer security policy and setting   procedures to implement that policy.  In some cases, possible options   are discussed along with the some of the ramifications of thoseSite Security Policy Handbook Working Group                     [Page 7]RFC 1244                 Site Security Handbook                July 1991   choices.  As far as possible, this document tries not to dictate the   choices a site should make, since these depend on local   circumstances.  Some of the issues brought up may not apply to all   sites.  Nonetheless, all sites should at least consider the issues   brought up here to ensure that they do not miss some important area.   The overall flow of the document is to discuss policy issues followed   by the issues that come up in creating procedures to implement the   policies.   Section 2 discusses setting official site policies for access to   computing resources.  It also goes into the issue of what happens   when the policy is violated.  The policies will drive the procedures   that need to be created, so decision makers will need to make choices   about policies before many of the procedural issues in following   sections can be dealt with.  A key part of creating policies is doing   some kind of risk assessment to decide what really needs to be   protected and the level of resources that should be applied to   protect them.   Once policies are in place, procedures to prevent future security   problems should be established.  Section 3 defines and suggests   actions to take when unauthorized activity is suspected.  Resources   to prevent secruity breaches are also discussed.   Section 4 discusses types of procedures to prevent security problems.   Prevention is a key to security; as an example, the Computer   Emergency Response Team/Coordination Center (CERT/CC) at Carnegie-   Mellon University (CMU) estimates that 80% or more of the problems   they see have to do with poorly chosen passwords.   Section 5 discusses incident handling: what kinds of issues does a   site face when someone violates the security policy.  Many decisions   will have to made on the spot as the incident occurs, but many of the   options and issues can be discussed in advance.  At very least,   responsibilities and methods of communication can be established   before an incident.  Again, the choices here are influenced by the   policies discussed in section 2.   Section 6 deals with what happens after a security violation has been   dealt with.  Security planning is an on-going cycle; just after an   incident has occurred is an excellent opportunity to improve policies   and procedures.   The rest of the document provides references and an annotated   bibliography.Site Security Policy Handbook Working Group                     [Page 8]RFC 1244                 Site Security Handbook                July 19912.  Establishing Official Site Policy on Computer Security2.1  Brief Overview   2.1.1  Organization Issues      The goal in developing an official site policy on computer      security is to define the organization's expectations of proper      computer and network use and to define procedures to prevent and      respond to security incidents.  In order to do this, aspects of      the particular organization must be considered.      First, the goals and direction of the organization should be      considered.  For example, a military base may have very different      security concerns from a those of a university.      Second, the site security policy developed must conform to      existing policies, rules, regulations and laws that the      organization is subject to.  Therefore it will be necessary to      identify these and take them into consideration while developing      the policy.      Third, unless the local network is completely isolated and      standalone, it is necessary to consider security implications in a      more global context.  The policy should address the issues when      local security problems develop as a result of a remote site as      well as when problems occur on remote systems as a result of a      local host or user.   2.1.2  Who Makes the Policy?      Policy creation must be a joint effort by technical personnel, who      understand the full ramifications of the proposed policy and the      implementation of the policy, and by decision makers who have the      power to enforce the policy.  A policy which is neither      implementable nor enforceable is useless.      Since a computer security policy can affect everyone in an      organization, it is worth taking some care to make sure you have      the right level of authority in on the policy decisions.  Though a      particular group (such as a campus information services group) may      have responsibility for enforcing a policy, an even higher group      may have to support and approve the policy.   2.1.3  Who is Involved?      Establishing a site policy has the potential for involving every      computer user at the site in a variety of ways.  Computer usersSite Security Policy Handbook Working Group                     [Page 9]RFC 1244                 Site Security Handbook                July 1991      may be responsible for personal password administration.  Systems      managers are obligated to fix security holes and to oversee the      system.      It is critical to get the right set of people involved at the      start of the process.  There may already be groups concerned with      security who would consider a computer security policy to be their      area.  Some of the types of groups that might be involved include      auditing/control, organizations that deal with physical security,      campus information systems groups, and so forth.  Asking these      types of groups to "buy in" from the start can help facilitate the      acceptance of the policy.   2.1.4  Responsibilities      A key element of a computer security policy is making sure      everyone knows their own responsibility for maintaining security.      A computer security policy cannot anticipate all possibilities;      however, it can ensure that each kind of problem does have someone      assigned to deal with it.      There may be levels of responsibility associated with a policy on      computer security.  At one level, each user of a computing      resource may have a responsibility to protect his account.  A user      who allows his account to be compromised increases the chances of      compromising other accounts or resources.      System managers may form another responsibility level: they must      help to ensure the security of the computer system.  Network      managers may reside at yet another level.2.2  Risk Assessment   2.2.1  General Discussion      One of the most important reasons for creating a computer security      policy is to ensure that efforts spent on security yield cost      effective benefits.  Although this may seem obvious, it is      possible to be mislead about where the effort is needed.  As an      example, there is a great deal of publicity about intruders on      computers systems; yet most surveys of computer security show that      for most organizations, the actual loss from "insiders" is much      greater.      Risk analysis involves determining what you need to protect, what      you need to protect it from, and how to protect it.  Is is the      process of examining all of your risks, and ranking those risks by      level of severity.  This process involves making cost-effectiveSite Security Policy Handbook Working Group                    [Page 10]RFC 1244                 Site Security Handbook                July 1991      decisions on what you want to protect.  The old security adage      says that you should not spend more to protect something than it      is actually worth.      A full treatment of risk analysis is outside the scope of this      document.  [3, FITES] and [16, PFLEEGER] provide introductions to      this topic.  However, there are two elements of a risk analysis      that will be briefly covered in the next two sections:         1. Identifying the assets         2. Identifying the threats      For each asset, the basic goals of security are availability,      confidentiality, and integrity.  Each threat should be examined      with an eye to how the threat could affect these areas.   2.2.2  Identifying the Assets      One step in a risk analysis is to identify all the things that      need to be protected.  Some things are obvious, like all the      various pieces of hardware, but some are overlooked, such as the      people who actually use the systems. The essential point is to      list all things that could be affected by a security problem.