site security handbook.txt

黑客培训教程

Site Security Policy Handbook Working Group                    [Page 21]

RFC 1244                 Site Security Handbook                July 1991


   Protect and Proceed

      1. If assets are not well protected.

      2. If continued penetration could result in great
         financial risk.

      3. If the possibility or willingness to prosecute
         is not present.

      4. If user base is unknown.

      5. If users are unsophisticated and their work is
         vulnerable.

      6. If the site is vulnerable to lawsuits from users, e.g.,
         if their resources are undermined.

   Pursue and Prosecute

      1. If assets and systems are well protected.

      2. If good backups are available.

      3. If the risk to the assets is outweighed by the
         disruption caused by the present and possibly future
         penetrations.

      4. If this is a concentrated attack occurring with great
         frequency and intensity.

      5. If the site has a natural attraction to intruders, and
         consequently regularly attracts intruders.

      6. If the site is willing to incur the financial (or other)
         risk to assets by allowing the penetrator continue.

      7. If intruder access can be controlled.

      8. If the monitoring tools are sufficiently well-developed
         to make the pursuit worthwhile.

      9. If the support staff is sufficiently clever and knowledgable
         about the operating system, related utilities, and systems
         to make the pursuit worthwhile.

      10. If there is willingness on the part of management to
          prosecute.



Site Security Policy Handbook Working Group                    [Page 22]

RFC 1244                 Site Security Handbook                July 1991


      11. If the system adminitrators know in general what kind of
          evidence would lead to prosecution.

      12. If there is established contact with knowledgeable law
          enforcement.

      13. If there is a site representative versed in the relevant
          legal issues.

      14. If the site is prepared for possible legal action from
          its own users if their data or systems become compromised
          during the pursuit.

2.6  Interpreting the Policy

   It is important to define who will interpret the policy.  This could
   be an individual or a committee.  No matter how well written, the
   policy will require interpretation from time to time and this body
   would serve to review, interpret, and revise the policy as needed.

2.7  Publicizing the Policy

   Once the site security policy has been written and established, a
   vigorous process should be engaged to ensure that the policy
   statement is widely and thoroughly disseminated and discussed.  A
   mailing of the policy should not be considered sufficient.  A period
   for comments should be allowed before the policy becomes effective to
   ensure that all affected users have a chance to state their reactions
   and discuss any unforeseen ramifications.  Ideally, the policy should
   strike a balance between protection and productivity.

   Meetings should be held to elicit these comments, and also to ensure
   that the policy is correctly understood.  (Policy promulgators are
   not necessarily noted for their skill with the language.)  These
   meetings should involve higher management as well as line employees.
   Security is a collective effort.

   In addition to the initial efforts to publicize the policy, it is
   essential for the site to maintain a continual awareness of its
   computer security policy.  Current users may need periodic reminders
   New users should have the policy included as part of their site
   introduction packet.  As a condition for using the site facilities,
   it may be advisable to have them sign a statement that they have read
   and understood the policy.  Should any of these users require legal
   action for serious policy violations, this signed statement might
   prove to be a valuable aid.





Site Security Policy Handbook Working Group                    [Page 23]

RFC 1244                 Site Security Handbook                July 1991


3.  Establishing Procedures to Prevent Security Problems

   The security policy defines what needs to be protected.  This section
   discusses security procedures which specify what steps will be used
   to carry out the security policy.

3.1  Security Policy Defines What Needs to be Protected

   The security policy defines the WHAT's: what needs to be protected,
   what is most important, what the priorities are, and what the general
   approach to dealing with security problems should be.

   The security policy by itself doesn't say HOW things are protected.
   That is the role of security procedures, which this section
   discusses.  The security policy should be a high level document,
   giving general strategy.  The security procedures need to set out, in
   detail, the precise steps your site will take to protect itself.

   The security policy should include a general risk assessment of the
   types of threats a site is mostly likely to face and the consequences
   of those threats (see section 2.2).  Part of doing a risk assessment
   will include creating a general list of assets that should be
   protected (section 2.2.2).  This information is critical in devising
   cost-effective procedures.

   It is often tempting to start creating security procedures by
   deciding on different mechanisms first: "our site should have logging
   on all hosts, call-back modems, and smart cards for all users."  This
   approach could lead to some areas that have too much protection for
   the risk they face, and other areas that aren't protected enough.
   Starting with the security policy and the risks it outlines should
   ensure that the procedures provide the right level of protect for all
   assets.

3.2  Identifing Possible Problems

   To determine risk, vulnerabilities must be identified.  Part of the
   purpose of the policy is to aid in shoring up the vulnerabilities and
   thus to decrease the risk in as many areas as possible.  Several of
   the more popular problem areas are presented in sections below.  This
   list is by no means complete.  In addition, each site is likely to
   have a few unique vulnerabilities.

   3.2.1  Access Points

      Access points are typically used for entry by unauthorized users.
      Having many access points increases the risk of access to an
      organization's computer and network facilities.



Site Security Policy Handbook Working Group                    [Page 24]

RFC 1244                 Site Security Handbook                July 1991


      Network links to networks outside the organization allow access
      into the organization for all others connected to that external
      network.  A network link typically provides access to a large
      number of network services, and each service has a potential to be
      compromised.

      Dialup lines, depending on their configuration, may provide access
      merely to a login port of a single system.  If connected to a
      terminal server, the dialup line may give access to the entire
      network.

      Terminal servers themselves can be a source of problem.  Many
      terminal servers do not require any kind of authentication.
      Intruders often use terminal servers to disguise their actions,
      dialing in on a local phone and then using the terminal server to
      go out to the local network.  Some terminal servers are configured
      so that intruders can TELNET [19] in from outside the network, and
      then TELNET back out again, again serving to make it difficult to
      trace them.

   3.2.2  Misconfigured Systems

      Misconfigured systems form a large percentage of security holes.
      Today's operating systems and their associated software have
      become so complex that understanding how the system works has
      become a full-time job.  Often, systems managers will be non-
      specialists chosen from the current organization's staff.

      Vendors are also partly responsible for misconfigured systems. To
      make the system installation process easier, vendors occasionally
      choose initial configurations that are not secure in all
      environments.

   3.2.3  Software Bugs

      Software will never be bug free.  Publicly known security bugs are
      common methods of unauthorized entry.  Part of the solution to
      this problem is to be aware of the security problems and to update
      the software when problems are detected.  When bugs are found,
      they should be reported to the vendor so that a solution to the
      problem can be implemented and distributed.

   3.2.4  "Insider" Threats

      An insider to the organization may be a considerable threat to the
      security of the computer systems.  Insiders often have direct
      access to the computer and network hardware components.  The
      ability to access the components of a system makes most systems



Site Security Policy Handbook Working Group                    [Page 25]

RFC 1244                 Site Security Handbook                July 1991


      easier to compromise.  Most desktop workstations can be easily
      manipulated so that they grant privileged access.  Access to a
      local area network provides the ability to view possibly sensitive
      data traversing the network.

3.3  Choose Controls to Protect Assets in a Cost-Effective Way

   After establishing what is to be protected, and assessing the risks
   these assets face, it is necessary to decide how to implement the
   controls which protect these assets.  The controls and protection
   mechanisms should be selected in a way so as to adequately counter
   the threats found during risk assessment, and to implement those
   controls in a cost effective manner.  It makes little sense to spend
   an exorbitant sum of money and overly constrict the user base if the
   risk of exposure is very small.

   3.3.1  Choose the Right Set of Controls

      The controls that are selected represent the physical embodiment
      of your security policy.  They are the first and primary line of
      defense in the protection of your assets.  It is therefore most
      important to ensure that the controls that you select are the
      right set of controls.  If the major threat to your system is
      outside penetrators, it probably doesn't make much sense to use
      biometric devices to authenticate your regular system users.  On
      the other hand, if the major threat is unauthorized use of
      computing resources by regular system users, you'll probably want
      to establish very rigorous automated accounting procedures.

   3.3.2  Use Common Sense

      Common sense is the most appropriate tool that can be used to
      establish your security policy.  Elaborate security schemes and
      mechanisms are impressive, and they do have their place, yet there
      is little point in investing money and time on an elaborate
      implementation scheme if the simple controls are forgotten.  For
      example, no matter how elaborate a system you put into place on
      top of existing security controls, a single user with a poor
      password can still leave your system open to attack.

3.4  Use Multiple Strategies to Protect Assets

   Another method of protecting assets is to use multiple strategies.
   In this way, if one strategy fails or is circumvented, another
   strategy comes into play to continue protecting the asset.  By using
   several simpler strategies, a system can often be made more secure
   than if one very sophisticated method were used in its place.  For
   example, dial-back modems can be used in conjunction with traditional



Site Security Policy Handbook Working Group                    [Page 26]

RFC 1244                 Site Security Handbook                July 1991


   logon mechanisms.  Many similar approaches