Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 1244

Site Security Handbook

Pages: 101
Obsoleted by:  2196
Part 2 of 4 – Pages 24 to 55
First   Prev   Next

ToP   noToC   RFC1244 - Page 24   prevText
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

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.
ToP   noToC   RFC1244 - Page 25
      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

      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

      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

   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
ToP   noToC   RFC1244 - Page 26
      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
ToP   noToC   RFC1244 - Page 27
   logon mechanisms.  Many similar approaches could be devised that
   provide several levels of protection for assets.  However, it's very
   easy to go overboard with extra mechanisms.  One must keep in mind
   exactly what it is that needs to be protected.

3.5  Physical Security

   It is a given in computer security if the system itself is not
   physically secure, nothing else about the system can be considered
   secure.  With physical access to a machine, an intruder can halt the
   machine, bring it back up in privileged mode, replace or alter the
   disk, plant Trojan horse programs (see section, or take any
   number of other undesirable (and hard to prevent) actions.

   Critical communications links, important servers, and other key
   machines should be located in physically secure areas.  Some security
   systems (such as Kerberos) require that the machine be physically

   If you cannot physically secure machines, care should be taken about
   trusting those machines.  Sites should consider limiting access from
   non-secure machines to more secure machines.  In particular, allowing
   trusted access (e.g., the BSD Unix remote commands such as rsh) from
   these kinds of hosts is particularly risky.

   For machines that seem or are intended to be physically secure, care
   should be taken about who has access to the machines.  Remember that
   custodial and maintenance staff often have keys to rooms.

3.6   Procedures to Recognize Unauthorized Activity

   Several simple procedures can be used to detect most unauthorized
   uses of a computer system.  These procedures use tools provided with
   the operating system by the vendor, or tools publicly available from
   other sources.

   3.6.1  Monitoring System Use

      System monitoring can be done either by a system administrator, or
      by software written for the purpose.  Monitoring a system involves
      looking at several parts of the system and searching for anything
      unusual.  Some of the easier ways to do this are described in this

      The most important thing about monitoring system use is that it be
      done on a regular basis.  Picking one day out of the month to
      monitor the system is pointless, since a security breach can be
      isolated to a matter of hours.  Only by maintaining a constant
ToP   noToC   RFC1244 - Page 28
      vigil can you expect to detect security violations in time to
      react to them.

   3.6.2  Tools for Monitoring the System

      This section describes tools and methods for monitoring a system
      against unauthorized access and use.  Logging

         Most operating systems store numerous bits of information in
         log files.  Examination of these log files on a regular basis
         is often the first line of defense in detecting unauthorized
         use of the system.

            - Compare lists of currently logged in users and past
              login histories.  Most users typically log in and out
              at roughly the same time each day.  An account logged
              in outside the "normal" time for the account may be in
              use by an intruder.

            - Many systems maintain accounting records for billing
              purposes.  These records can also be used to determine
              usage patterns for the system; unusual accounting records
              may indicate unauthorized use of the system.

            - System logging facilities, such as the UNIX "syslog"
              utility, should be checked for unusual error messages
              from system software.  For example, a large number of
              failed login attempts in a short period of time may
              indicate someone trying to guess passwords.

            - Operating system commands which list currently executing
              processes can be used to detect users running programs
              they are not authorized to use, as well as to detect
              unauthorized programs which have been started by an
              intruder.  Monitoring Software

         Other monitoring tools can easily be constructed using standard
         operating system software, by using several, often unrelated,
         programs together.  For example, checklists of file ownerships
         and permission settings can be constructed (for example, with
         "ls" and "find" on UNIX) and stored off-line.  These lists can
         then be reconstructed periodically and compared against the
         master checklist (on UNIX, by using the "diff" utility).
         Differences may indicate that unauthorized modifications have
ToP   noToC   RFC1244 - Page 29
         been made to the system.

         Still other tools are available from third-party vendors and
         public software distribution sites.  Section 3.9.9 lists
         several sources from which you can learn what tools are
         available and how to get them.  Other Tools

         Other tools can also be used to monitor systems for security
         violations, although this is not their primary purpose.  For
         example, network monitors can be used to detect and log
         connections from unknown sites.

   3.6.3  Vary the Monitoring Schedule

      The task of system monitoring is not as daunting as it may seem.
      System administrators can execute many of the commands used for
      monitoring periodically throughout the day during idle moments
      (e.g., while talking on the telephone), rather than spending fixed
      periods of each day monitoring the system.  By executing the
      commands frequently, you will rapidly become used to seeing
      "normal" output, and will easily spot things which are out of the
      ordinary.  In addition, by running various monitoring commands at
      different times throughout the day, you make it hard for an
      intruder to predict your actions.  For example, if an intruder
      knows that each day at 5:00 p.m. the system is checked to see that
      everyone has logged off, he will simply wait until after the check
      has completed before logging in.  But the intruder cannot guess
      when a system administrator might type a command to display all
      logged-in users, and thus he runs a much greater risk of

      Despite the advantages that regular system monitoring provides,
      some intruders will be aware of the standard logging mechanisms in
      use on systems they are attacking.  They will actively pursue and
      attempt to disable monitoring mechanisms.  Regular monitoring
      therefore is useful in detecting intruders, but does not provide
      any guarantee that your system is secure, nor should monitoring be
      considered an infallible method of detecting unauthorized use.

3.7  Define Actions to Take When Unauthorized Activity is Suspected

      Sections 2.4 and 2.5 discussed the course of action a site should
      take when it suspects its systems are being abused.  The computer
      security policy should state the general approach towards dealing
      with these problems.
ToP   noToC   RFC1244 - Page 30
      The procedures for dealing with these types of problems should be
      written down.  Who has authority to decide what actions will be
      taken?  Should law enforcement be involved?  Should your
      organization cooperate with other sites in trying to track down an
      intruder?  Answers to all the questions in section 2.4 should be
      part of the incident handling procedures.

      Whether you decide to lock out or pursue intruders, you should
      have tools and procedures ready to apply.  It is best to work up
      these tools and procedures before you need them.  Don't wait until
      an intruder is on your system to figure out how to track the
      intruder's actions; you will be busy enough if an intruder

3.8  Communicating Security Policy

   Security policies, in order to be effective, must be communicated to
   both the users of the system and the system maintainers.  This
   section describes what these people should be told, and how to tell

   3.8.1  Educating the Users

      Users should be made aware of how the computer systems are
      expected to be used, and how to protect themselves from
      unauthorized users.  Proper Account/Workstation Use

         All users should be informed about what is considered the
         "proper" use of their account or workstation ("proper" use is
         discussed in section 2.3.2).  This can most easily be done at
         the time a user receives their account, by giving them a policy
         statement.  Proper use policies typically dictate things such
         as whether or not the account or workstation may be used for
         personal activities (such as checkbook balancing or letter
         writing), whether profit-making activities are allowed, whether
         game playing is permitted, and so on.  These policy statements
         may also be used to summarize how the computer facility is
         licensed and what software licenses are held by the
         institution; for example, many universities have educational
         licenses which explicitly prohibit commercial uses of the
         system.  A more complete list of items to consider when writing
         a policy statement is given in section 2.3.  Account/Workstation Management Procedures

         Each user should be told how to properly manage their account
ToP   noToC   RFC1244 - Page 31
         and workstation.  This includes explaining how to protect files
         stored on the system, how to log out or lock the terminal or
         workstation, and so on.  Much of this information is typically
         covered in the "beginning user" documentation provided by the
         operating system vendor, although many sites elect to
         supplement this material with local information.

         If your site offers dial-up modem access to the computer
         systems, special care must be taken to inform users of the
         security problems inherent in providing this access.  Issues
         such as making sure to log out before hanging up the modem
         should be covered when the user is initially given dial-up

         Likewise, access to the systems via local and wide-area
         networks presents its own set of security problems which users
         should be made aware of.  Files which grant "trusted host" or
         "trusted user" status to remote systems and users should be
         carefully explained.  Determining Account Misuse

         Users should be told how to detect unauthorized access to their
         account.  If the system prints the last login time when a user
         logs in, he or she should be told to check that time and note
         whether or not it agrees with the last time he or she actually
         logged in.

         Command interpreters on some systems (e.g., the UNIX C shell)
         maintain histories of the last several commands executed.
         Users should check these histories to be sure someone has not
         executed other commands with their account.  Problem Reporting Procedures

         A procedure should be developed to enable users to report
         suspected misuse of their accounts or other misuse they may
         have noticed.  This can be done either by providing the name
         and telephone number of a system administrator who manages
         security of the computer system, or by creating an electronic
         mail address (e.g., "security") to which users can address
         their problems.

   3.8.2  Educating the Host Administrators

      In many organizations, computer systems are administered by a wide
      variety of people.  These administrators must know how to protect
      their own systems from attack and unauthorized use, as well as how
ToP   noToC   RFC1244 - Page 32
      to communicate successful penetration of their systems to other
      administrators as a warning.  Account Management Procedures

         Care must be taken when installing accounts on the system in
         order to make them secure.  When installing a system from
         distribution media, the password file should be examined for
         "standard" accounts provided by the vendor.  Many vendors
         provide accounts for use by system services or field service
         personnel.  These accounts typically have either no password or
         one which is common knowledge.  These accounts should be given
         new passwords if they are needed, or disabled or deleted from
         the system if they are not.

         Accounts without passwords are generally very dangerous since
         they allow anyone to access the system.  Even accounts which do
         not execute a command interpreter (e.g., accounts which exist
         only to see who is logged in to the system) can be compromised
         if set up incorrectly.  A related concept, that of "anonymous"
         file transfer (FTP) [20], allows users from all over the
         network to access your system to retrieve files from (usually)
         a protected disk area.  You should carefully weigh the benefits
         that an account without a password provides against the
         security risks of providing such access to your system.

         If the operating system provides a "shadow" password facility
         which stores passwords in a separate file accessible only to
         privileged users, this facility should be used.  System V UNIX,
         SunOS 4.0 and above, and versions of Berkeley UNIX after 4.3BSD
         Tahoe, as well as others, provide this feature.  It protects
         passwords by hiding their encrypted values from unprivileged
         users.  This prevents an attacker from copying your password
         file to his or her machine and then attempting to break the
         passwords at his or her leisure.

         Keep track of who has access to privileged user accounts (e.g.,
         "root" on UNIX or "MAINT" on VMS).  Whenever a privileged user
         leaves the organization or no longer has need of the privileged
         account, the passwords on all privileged accounts should be
         changed.  Configuration Management Procedures

         When installing a system from the distribution media or when
         installing third-party software, it is important to check the
         installation carefully.  Many installation procedures assume a
         "trusted" site, and hence will install files with world write
ToP   noToC   RFC1244 - Page 33
         permission enabled, or otherwise compromise the security of

         Network services should also be examined carefully when first
         installed.  Many vendors provide default network permission
         files which imply that all outside hosts are to be "trusted",
         which is rarely the case when connected to wide-area networks
         such as the Internet.

         Many intruders collect information on the vulnerabilities of
         particular system versions.  The older a system, the more
         likely it is that there are security problems in that version
         which have since been fixed by the vendor in a later release.
         For this reason, it is important to weigh the risks of not
         upgrading to a new operating system release (thus leaving
         security holes unplugged) against the cost of upgrading to the
         new software (possibly breaking third-party software, etc.).
         Bug fixes from the vendor should be weighed in a similar
         fashion, with the added note that "security" fixes from a
         vendor usually address fairly serious security problems.

         Other bug fixes, received via network mailing lists and the
         like, should usually be installed, but not without careful
         examination.  Never install a bug fix unless you're sure you
         know what the consequences of the fix are - there's always the
         possibility that an intruder has suggested a "fix" which
         actually gives him or her access to your system.  Recovery Procedures - Backups

         It is impossible to overemphasize the need for a good backup
         strategy.  File system backups not only protect you in the
         event of hardware failure or accidental deletions, but they
         also protect you against unauthorized changes made by an
         intruder.  Without a copy of your data the way it's "supposed"
         to be, it can be difficult to undo something an attacker has

         Backups, especially if run daily, can also be useful in
         providing a history of an intruder's activities.  Looking
         through old backups can establish when your system was first
         penetrated.  Intruders may leave files around which, although
         deleted later, are captured on the backup tapes.  Backups can
         also be used to document an intruder's activities to law
         enforcement agencies if necessary.

         A good backup strategy will dump the entire system to tape at
         least once a month.  Partial (or "incremental") dumps should be
ToP   noToC   RFC1244 - Page 34
         done at least twice a week, and ideally they should be done
         daily.  Commands specifically designed for performing file
         system backups (e.g., UNIX "dump" or VMS "BACKUP") should be
         used in preference to other file copying commands, since these
         tools are designed with the express intent of restoring a
         system to a known state.  Problem Reporting Procedures

         As with users, system administrators should have a defined
         procedure for reporting security problems.  In large
         installations, this is often done by creating an electronic
         mail alias which contains the names of all system
         administrators in the organization.  Other methods include
         setting up some sort of response team similar to the CERT, or
         establishing a "hotline" serviced by an existing support group.

3.9  Resources to Prevent Security Breaches

   This section discusses software, hardware, and procedural resources
   that can be used to support your site security policy.

   3.9.1  Network Connections and Firewalls

      A "firewall" is put in place in a building to provide a point of
      resistance to the entry of flames into another area.  Similarly, a
      secretary's desk and reception area provides a point of
      controlling access to other office spaces.  This same technique
      can be applied to a computer site, particularly as it pertains to
      network connections.

      Some sites will be connected only to other sites within the same
      organization and will not have the ability to connect to other
      networks.  Sites such as these are less susceptible to threats
      from outside their own organization, although intrusions may still
      occur via paths such as dial-up modems.  On the other hand, many
      other organizations will be connected to other sites via much
      larger networks, such as the Internet.  These sites are
      susceptible to the entire range of threats associated with a
      networked environment.

      The risks of connecting to outside networks must be weighed
      against the benefits.  It may be desirable to limit connection to
      outside networks to those hosts which do not store sensitive
      material, keeping "vital" machines (such as those which maintain
      company payroll or inventory systems) isolated.  If there is a
      need to participate in a Wide Area Network (WAN), consider
      restricting all access to your local network through a single
ToP   noToC   RFC1244 - Page 35
      system.  That is, all access to or from your own local network
      must be made through a single host computer that acts as a
      firewall between you and the outside world.  This firewall system
      should be rigorously controlled and password protected, and
      external users accessing it should also be constrained by
      restricting the functionality available to remote users.  By using
      this approach, your site could relax some of the internal security
      controls on your local net, but still be afforded the protection
      of a rigorously controlled host front end.

      Note that even with a firewall system, compromise of the firewall
      could result in compromise of the network behind the firewall.
      Work has been done in some areas to construct a firewall which
      even when compromised, still protects the local network [6,

   3.9.2  Confidentiality

      Confidentiality, the act of keeping things hidden or secret, is
      one of the primary goals of computer security practitioners.
      Several mechanisms are provided by most modern operating systems
      to enable users to control the dissemination of information.
      Depending upon where you work, you may have a site where
      everything is protected, or a site where all information is
      usually regarded as public, or something in-between.  Most sites
      lean toward the in-between, at least until some penetration has

      Generally, there are three instances in which information is
      vulnerable to disclosure: when the information is stored on a
      computer system, when the information is in transit to another
      system (on the network), and when the information is stored on
      backup tapes.

      The first of these cases is controlled by file permissions, access
      control lists, and other similar mechanisms.  The last can be
      controlled by restricting access to the backup tapes (by locking
      them in a safe, for example).  All three cases can be helped by
      using encryption mechanisms.  Encryption (hardware and software)

         Encryption is the process of taking information that exists in
         some readable form and converting it into a non-readable form.
         There are several types of commercially available encryption
         packages in both hardware and software forms.  Hardware
         encryption engines have the advantage that they are much faster
         than the software equivalent, yet because they are faster, they
ToP   noToC   RFC1244 - Page 36
         are of greater potential benefit to an attacker who wants to
         execute a brute-force attack on your encrypted information.

         The advantage of using encryption is that, even if other access
         control mechanisms (passwords, file permissions, etc.) are
         compromised by an intruder, the data is still unusable.
         Naturally, encryption keys and the like should be protected at
         least as well as account passwords.

         Information in transit (over a network) may be vulnerable to
         interception as well.  Several solutions to this exist, ranging
         from simply encrypting files before transferring them (end-to-
         end encryption) to special network hardware which encrypts
         everything it sends without user intervention (secure links).
         The Internet as a whole does not use secure links, thus end-
         to-end encryption must be used if encryption is desired across
         the Internet.
  Data Encryption Standard (DES)

            DES is perhaps the most widely used data encryption
            mechanism today.  Many hardware and software implementations
            exist, and some commercial computers are provided with a
            software version.  DES transforms plain text information
            into encrypted data (or ciphertext) by means of a special
            algorithm and "seed" value called a key.  So long as the key
            is retained (or remembered) by the original user, the
            ciphertext can be restored to the original plain text.

            One of the pitfalls of all encryption systems is the need to
            remember the key under which a thing was encrypted (this is
            not unlike the password problem discussed elsewhere in this
            document).  If the key is written down, it becomes less
            secure.  If forgotten, there is little (if any) hope of
            recovering the original data.

            Most UNIX systems provide a DES command that enables a user
            to encrypt data using the DES algorithm.

            Similar to the DES command, the UNIX "crypt" command allows
            a user to encrypt data.  Unfortunately, the algorithm used
            by "crypt" is very insecure (based on the World War II
            "Enigma" device), and files encrypted with this command can
            be decrypted easily in a matter of a few hours.  Generally,
            use of the "crypt" command should be avoided for any but the
            most trivial encryption tasks.
ToP   noToC   RFC1244 - Page 37  Privacy Enhanced Mail

         Electronic mail normally transits the network in the clear
         (i.e., anyone can read it).  This is obviously not the optimal
         solution.  Privacy enhanced mail provides a means to
         automatically encrypt electronic mail messages so that a person
         eavesdropping at a mail distribution node is not (easily)
         capable of reading them.  Several privacy enhanced mail
         packages are currently being developed and deployed on the

         The Internet Activities Board Privacy Task Force has defined a
         draft standard, elective protocol for use in implementing
         privacy enhanced mail.  This protocol is defined in RFCs 1113,
         1114, and 1115 [7,8,9].  Please refer to the current edition of
         the "IAB Official Protocol Standards" (currently, RFC 1200
         [21]) for the standardization state and status of these

   3.9.3  Origin Authentication

      We mostly take it on faith that the header of an electronic mail
      message truly indicates the originator of a message.  However, it
      iseasy to "spoof", or forge the source of a mail message.  Origin
      authentication provides a means to be certain of the originator of
      a message or other object in the same way that a Notary Public
      assures a signature on a legal document.  This is done by means of
      a "Public Key" cryptosystem.

      A public key cryptosystem differs from a private key cryptosystem
      in several ways.  First, a public key system uses two keys, a
      Public Key that anyone can use (hence the name) and a Private Key
      that only the originator of a message uses.  The originator uses
      the private key to encrypt the message (as in DES).  The receiver,
      who has obtained the public key for the originator, may then
      decrypt the message.

      In this scheme, the public key is used to authenticate the
      originator's use of his or her private key, and hence the identity
      of the originator is more rigorously proven.  The most widely
      known implementation of a public key cryptosystem is the RSA
      system [26].  The Internet standard for privacy enhanced mail
      makes use of the RSA system.

   3.9.4  Information Integrity

      Information integrity refers to the state of information such that
      it is complete, correct, and unchanged from the last time in which
ToP   noToC   RFC1244 - Page 38
      it was verified to be in an "integral" state.  The value of
      information integrity to a site will vary.  For example, it is
      more important for military and government installations to
      prevent the "disclosure" of classified information, whether it is
      right or wrong.  A bank, on the other hand, is far more concerned
      with whether the account information maintained for its customers
      is complete and accurate.

      Numerous computer system mechanisms, as well as procedural
      controls, have an influence on the integrity of system
      information.  Traditional access control mechanisms maintain
      controls over who can access system information.  These mechanisms
      alone are not sufficient in some cases to provide the degree of
      integrity required.  Some other mechanisms are briefly discussed

      It should be noted that there are other aspects to maintaining
      system integrity besides these mechanisms, such as two-person
      controls, and integrity validation procedures.  These are beyond
      the scope of this document.  Checksums

         Easily the simplest mechanism, a simple checksum routine can
         compute a value for a system file and compare it with the last
         known value.  If the two are equal, the file is probably
         unchanged.  If not, the file has been changed by some unknown

         Though it is the easiest to implement, the checksum scheme
         suffers from a serious failing in that it is not very
         sophisticated and a determined attacker could easily add enough
         characters to the file to eventually obtain the correct value.

         A specific type of checksum, called a CRC checksum, is
         considerably more robust than a simple checksum.  It is only
         slightly more difficult to implement and provides a better
         degree of catching errors.  It too, however, suffers from the
         possibility of compromise by an attacker.

         Checksums may be used to detect the altering of information.
         However, they do not actively guard against changes being made.
         For this, other mechanisms such as access controls and
         encryption should be used.
ToP   noToC   RFC1244 - Page 39  Cryptographic Checksums

         Cryptographic checksums (also called cryptosealing) involve
         breaking a file up into smaller chunks, calculating a (CRC)
         checksum for each chunk, and adding the CRCs together.
         Depending upon the exact algorithm used, this can result in a
         nearly unbreakable method of determining whether a file has
         been changed.  This mechanism suffers from the fact that it is
         sometimes computationally intensive and may be prohibitive
         except in cases where the utmost integrity protection is

         Another related mechanism, called a one-way hash function (or a
         Manipulation Detection Code (MDC)) can also be used to uniquely
         identify a file.  The idea behind these functions is that no
         two inputs can produce the same output, thus a modified file
         will not have the same hash value.  One-way hash functions can
         be implemented efficiently on a wide variety of systems, making
         unbreakable integrity checks possible.  (Snefru, a one-way hash
         function available via USENET as well as the Internet is just
         one example of an efficient one-way hash function.) [10]

   3.9.5  Limiting Network Access

      The dominant network protocols in use on the Internet, IP (RFC
      791) [11], TCP (RFC 793) [12], and UDP (RFC 768) [13], carry
      certain control information which can be used to restrict access
      to certain hosts or networks within an organization.

      The IP packet header contains the network addresses of both the
      sender and recipient of the packet.  Further, the TCP and UDP
      protocols provide the notion of a "port", which identifies the
      endpoint (usually a network server) of a communications path.  In
      some instances, it may be desirable to deny access to a specific
      TCP or UDP port, or even to certain hosts and networks altogether.  Gateway Routing Tables

         One of the simplest approaches to preventing unwanted network
         connections is to simply remove certain networks from a
         gateway's routing tables.  This makes it "impossible" for a
         host to send packets to these networks.  (Most protocols
         require bidirectional packet flow even for unidirectional data
         flow, thus breaking one side of the route is usually

         This approach is commonly taken in "firewall" systems by
         preventing the firewall from advertising local routes to the
ToP   noToC   RFC1244 - Page 40
         outside world.  The approach is deficient in that it often
         prevents "too much" (e.g., in order to prevent access to one
         system on the network, access to all systems on the network is
         disabled).  Router Packet Filtering

         Many commercially available gateway systems (more correctly
         called routers) provide the ability to filter packets based not
         only on sources or destinations, but also on source-destination
         combinations.  This mechanism can be used to deny access to a
         specific host, network, or subnet from any other host, network,
         or subnet.

         Gateway systems from some vendors (e.g., cisco Systems) support
         an even more complex scheme, allowing finer control over source
         and destination addresses.  Via the use of address masks, one
         can deny access to all but one host on a particular network.
         The cisco Systems also allow packet screening based on IP
         protocol type and TCP or UDP port numbers [14].

         This can also be circumvented by "source routing" packets
         destined for the "secret" network.  Source routed packets may
         be filtered out by gateways, but this may restrict other
         legitimate activities, such as diagnosing routing problems.

   3.9.6  Authentication Systems

      Authentication refers to the process of proving a claimed identity
      to the satisfaction of some permission-granting authority.
      Authentication systems are hardware, software, or procedural
      mechanisms that enable a user to obtain access to computing
      resources.  At the simplest level, the system administrator who
      adds new user accounts to the system is part of the system
      authentication mechanism.  At the other end of the spectrum,
      fingerprint readers or retinal scanners provide a very high-tech
      solution to establishing a potential user's identity.  Without
      establishing and proving a user's identity prior to establishing a
      session, your site's computers are vulnerable to any sort of

      Typically, a user authenticates himself or herself to the system
      by entering a password in response to a prompt.
      Challenge/Response mechanisms improve upon passwords by prompting
      the user for some piece of information shared by both the computer
      and the user (such as mother's maiden name, etc.).
ToP   noToC   RFC1244 - Page 41  Kerberos

         Kerberos, named after the dog who in mythology is said to stand
         at the gates of Hades, is a collection of software used in a
         large network to establish a user's claimed identity.
         Developed at the Massachusetts Institute of Technology (MIT),
         it uses a combination of encryption and distributed databases
         so that a user at a campus facility can login and start a
         session from any computer located on the campus.  This has
         clear advantages in certain environments where there are a
         large number of potential users who may establish a connection
         from any one of a large number of workstations.  Some vendors
         are now incorporating Kerberos into their systems.

         It should be noted that while Kerberos makes several advances
         in the area of authentication, some security weaknesses in the
         protocol still remain [15].  Smart Cards

         Several systems use "smart cards" (a small calculator-like
         device) to help authenticate users.  These systems depend on
         the user having an object in their possession.  One such system
         involves a new password procedure that require a user to enter
         a value obtained from a "smart card" when asked for a password
         by the computer.  Typically, the host machine will give the
         user some piece of information that is entered into the
         keyboard of the smart card.  The smart card will display a
         response which must then be entered into the computer before
         the session will be established.  Another such system involves
         a smart card which displays a number which changes over time,
         but which is synchronized with the authentication software on
         the computer.

         This is a better way of dealing with authentication than with
         the traditional password approach.  On the other hand, some say
         it's inconvenient to carry the smart card.  Start-up costs are
         likely to be high as well.

   3.9.7  Books, Lists, and Informational Sources

      There are many good sources for information regarding computer
      security.  The annotated bibliography at the end of this document
      can provide you with a good start.  In addition, information can
      be obtained from a variety of other sources, some of which are
      described in this section.
ToP   noToC   RFC1244 - Page 42  Security Mailing Lists

         The UNIX Security mailing list exists to notify system
         administrators of security problems before they become common
         knowledge, and to provide security enhancement information.  It
         is a restricted-access list, open only to people who can be
         verified as being principal systems people at a site.  Requests
         to join the list must be sent by either the site contact listed
         in the Defense Data Network's Network Information Center's (DDN
         NIC) WHOIS database, or from the "root" account on one of the
         major site machines.  You must include the destination address
         you want on the list, an indication of whether you want to be
         on the mail reflector list or receive weekly digests, the
         electronic mail address and voice telephone number of the site
         contact if it isn't you, and the name, address, and telephone
         number of your organization.  This information should be sent

         The RISKS digest is a component of the ACM Committee on
         Computers and Public Policy, moderated by Peter G. Neumann.  It
         is a discussion forum on risks to the public in computers and
         related systems, and along with discussing computer security
         and privacy issues, has discussed such subjects as the Stark
         incident, the shooting down of the Iranian airliner in the
         Persian Gulf (as it relates to the computerized weapons
         systems), problems in air and railroad traffic control systems,
         software engineering, and so on.  To join the mailing list,
         send a message to RISKS-REQUEST@CSL.SRI.COM.  This list is also
         available in the USENET newsgroup "comp.risks".

         The VIRUS-L list is a forum for the discussion of computer
         virus experiences, protection software, and related topics.
         The list is open to the public, and is implemented as a
         moderated digest.  Most of the information is related to
         personal computers, although some of it may be applicable to
         larger systems.  To subscribe, send the line:

            SUB VIRUS-L your full name

         to the address LISTSERV%LEHIIBM1.BITNET@MITVMA.MIT.EDU.  This
         list is also available via the USENET newsgroup "comp.virus".

         The Computer Underground Digest "is an open forum dedicated to
         sharing information among computerists and to the presentation
         and debate of diverse views."  While not directly a security
         list, it does contain discussions about privacy and other
         security related topics.  The list can be read on USENET as, or to join the mailing list, send mail
ToP   noToC   RFC1244 - Page 43
         to Gordon Myer (
         Submissions may be mailed to:  Networking Mailing Lists

         The TCP-IP mailing list is intended to act as a discussion
         forum for developers and maintainers of implementations of the
         TCP/IP protocol suite.  It also discusses network-related
         security problems when they involve programs providing network
         services, such as "Sendmail".  To join the TCP-IP list, send a
         message to TCP-IP-REQUEST@NISC.SRI.COM.  This list is also
         available in the USENET newsgroup "comp.protocols.tcp-ip".

         SUN-NETS is a discussion list for items pertaining to
         networking on Sun systems.  Much of the discussion is related
         to NFS, NIS (formally Yellow Pages), and name servers.  To
         subscribe, send a message to SUN-NETS-REQUEST@UMIACS.UMD.EDU.

         The USENET groups and also discuss
         security issues. is a moderated group and also
         includes discussions of physical security and locks. is unmoderated.  Response Teams

         Several organizations have formed special groups of people to
         deal with computer security problems.  These teams collect
         information about possible security holes and disseminate it to
         the proper people, track intruders, and assist in recovery from
         security violations.  The teams typically have both electronic
         mail distribution lists as well as a special telephone number
         which can be called for information or to report a problem.
         Many of these teams are members of the CERT System, which is
         coordinated by the National Institute of Standards and
         Technology (NIST), and exists to facilitate the exchange of
         information between the various teams.
  DARPA Computer Emergency Response Team

            The Computer Emergency Response Team/Coordination Center
            (CERT/CC) was established in December 1988 by the Defense
            Advanced Research Projects Agency (DARPA) to address
            computer security concerns of research users of the
            Internet.  It is operated by the Software Engineering
            Institute (SEI) at Carnegie-Mellon University (CMU).  The
            CERT can immediately confer with experts to diagnose and
            solve security problems, and also establish and maintain
            communications with the affected computer users and
ToP   noToC   RFC1244 - Page 44
            government authorities as appropriate.

            The CERT/CC serves as a clearing house for the
            identification and repair of security vulnerabilities,
            informal assessments of existing systems, improvement of
            emergency response capability, and both vendor and user
            security awareness.  In addition, the team works with
            vendors of various systems in order to coordinate the fixes
            for security problems.

            The CERT/CC sends out security advisories to the CERT-
            ADVISORY mailing list whenever appropriate.  They also
            operate a 24-hour hotline that can be called to report
            security problems (e.g., someone breaking into your system),
            as well as to obtain current (and accurate) information
            about rumored security problems.

            To join the CERT-ADVISORY mailing list, send a message to
            CERT@CERT.SEI.CMU.EDU and ask to be added to the mailing
            list.  The material sent to this list also appears in the
            USENET newsgroup "".  Past advisories
            are available for anonymous FTP from the host
            CERT.SEI.CMU.EDU.  The 24-hour hotline number is (412) 268-

            The CERT/CC also maintains a CERT-TOOLS list to encourage
            the exchange of information on tools and techniques that
            increase the secure operation of Internet systems.  The
            CERT/CC does not review or endorse the tools described on
            the list.  To subscribe, send a message to CERT-TOOLS-
            REQUEST@CERT.SEI.CMU.EDU and ask to be added to the mailing

            The CERT/CC maintains other generally useful security
            information for anonymous FTP from CERT.SEI.CMU.EDU.  Get
            the README file for a list of what is available.

            For more information, contact:

               Software Engineering Institute
               Carnegie Mellon University
               Pittsburgh, PA  15213-3890

               (412) 268-7090
ToP   noToC   RFC1244 - Page 45  DDN Security Coordination Center

            For DDN users, the Security Coordination Center (SCC) serves
            a function similar to CERT.  The SCC is the DDN's clearing-
            house for host/user security problems and fixes, and works
            with the DDN Network Security Officer.  The SCC also
            distributes the DDN Security Bulletin, which communicates
            information on network and host security exposures, fixes,
            and concerns to security and management personnel at DDN
            facilities.  It is available online, via kermit or anonymous
            FTP, from the host NIC.DDN.MIL, in SCC:DDN-SECURITY-yy-
            nn.TXT (where "yy" is the year and "nn" is the bulletin
            number).  The SCC provides immediate assistance with DDN-
            related host security problems; call (800) 235-3155 (6:00
            a.m. to 5:00 p.m. Pacific Time) or send email to
            SCC@NIC.DDN.MIL.  For 24 hour coverage, call the MILNET
            Trouble Desk (800) 451-7413 or AUTOVON 231-1713.
  NIST Computer Security Resource and Response Center

            The National Institute of Standards and Technology (NIST)
            has responsibility within the U.S. Federal Government for
            computer science and technology activities.  NIST has played
            a strong role in organizing the CERT System and is now
            serving as the CERT System Secretariat.  NIST also operates
            a Computer Security Resource and Response Center (CSRC) to
            provide help and information regarding computer security
            events and incidents, as well as to raise awareness about
            computer security vulnerabilities.

            The CSRC team operates a 24-hour hotline, at (301) 975-5200.
            For individuals with access to the Internet, on-line
            publications and computer security information can be
            obtained via anonymous FTP from the host CSRC.NCSL.NIST.GOV
            (  NIST also operates a personal computer
            bulletin board that contains information regarding computer
            viruses as well as other aspects of computer security.  To
            access this board, set your modem to 300/1200/2400 BPS, 1
            stop bit, no parity, and 8-bit characters, and call (301)
            948-5717.  All users are given full access to the board
            immediately upon registering.

            NIST has produced several special publications related to
            computer security and computer viruses in particular; some
            of these publications are downloadable.  For further
            information, contact NIST at the following address:
ToP   noToC   RFC1244 - Page 46
               Computer Security Resource and Response Center
               A-216 Technology
               Gaithersburg, MD 20899
               Telephone: (301) 975-3359
               Electronic Mail:
  DOE Computer Incident Advisory Capability (CIAC)

            CIAC is the Department of Energy's (DOE's) Computer Incident
            Advisory Capability.  CIAC is a four-person team of computer
            scientists from Lawrence Livermore National Laboratory
            (LLNL) charged with the primary responsibility of assisting
            DOE sites faced with computer security incidents (e.g.,
            intruder attacks, virus infections, worm attacks, etc.).
            This capability is available to DOE sites on a 24-hour-a-day

            CIAC was formed to provide a centralized response capability
            (including technical assistance), to keep sites informed of
            current events, to deal proactively with computer security
            issues, and to maintain liaisons with other response teams
            and agencies.  CIAC's charter is to assist sites (through
            direct technical assistance, providing information, or
            referring inquiries to other technical experts), serve as a
            clearinghouse for information about threats/known
            incidents/vulnerabilities, develop guidelines for incident
            handling, develop software for responding to
            events/incidents, analyze events and trends, conduct
            training and awareness activities, and alert and advise
            sites about vulnerabilities and potential attacks.

            CIAC's business hours phone number is (415) 422-8193 or FTS
            532-8193.  CIAC's e-mail address is CIAC@TIGER.LLNL.GOV.
  NASA Ames Computer Network Security Response Team

            The Computer Network Security Response Team (CNSRT) is NASA
            Ames Research Center's local version of the DARPA CERT.
            Formed in August of 1989, the team has a constituency that
            is primarily Ames users, but it is also involved in
            assisting other NASA Centers and federal agencies.  CNSRT
            maintains liaisons with the DOE's CIAC team and the DARPA
            CERT.  It is also a charter member of the CERT System.  The
            team may be reached by 24 hour pager at (415) 694-0571, or
            by electronic mail to CNSRT@AMES.ARC.NASA.GOV.
ToP   noToC   RFC1244 - Page 47  DDN Management Bulletins

         The DDN Management Bulletin is distributed electronically by
         the DDN NIC under contract to the Defense Communications Agency
         (DCA).  It is a means of communicating official policy,
         procedures, and other information of concern to management
         personnel at DDN facilities.

         The DDN Security Bulletin is distributed electronically by the
         DDN SCC, also under contract to DCA, as a means of
         communicating information on network and host security
         exposures, fixes, and concerns to security and management
         personnel at DDN facilities.

         Anyone may join the mailing lists for these two bulletins by
         sending a message to NIC@NIC.DDN.MIL and asking to be placed on
         the mailing lists.  These messages are also posted to the
         USENET newsgroup "ddn.mgt-bulletin".  For additional
         information, see section 8.7.  System Administration List

         The SYSADM-LIST is a list pertaining exclusively to UNIX system
         administration.  Mail requests to be added to the list to
         SYSADM-LIST-REQUEST@SYSADMIN.COM.  Vendor Specific System Lists

         The SUN-SPOTS and SUN-MANAGERS lists are discussion groups for
         users and administrators of systems supplied by Sun
         Microsystems.  SUN-SPOTS is a fairly general list, discussing
         everything from hardware configurations to simple UNIX
         questions.  To subscribe, send a message to SUN-SPOTS-
         REQUEST@RICE.EDU.  This list is also available in the USENET
         newsgroup "comp.sys.sun".  SUN-MANAGERS is a discussion list
         for Sun system administrators and covers all aspects of Sun
         system administration.  To subscribe, send a message to SUN-

         The APOLLO list discusses the HP/Apollo system and its
         software.  To subscribe, send a message to APOLLO-
         REQUEST@UMIX.CC.UMICH.EDU.  APOLLO-L is a similar list which
         can be subscribed to by sending

            SUB APOLLO-L your full name

ToP   noToC   RFC1244 - Page 48
         HPMINI-L pertains to the Hewlett-Packard 9000 series and HP/UX
         operating system.  To subscribe, send

            SUB HPMINI-L your full name


         INFO-IBMPC discusses IBM PCs and compatibles, as well as MS-
         DOS.  To subscribe, send a note to INFO-IBMPC-REQUEST@WSMR-

         There are numerous other mailing lists for nearly every popular
         computer or workstation in use today.  For a complete list,
         obtain the file "netinfo/interest-groups" via anonymous FTP
         from the host FTP.NISC.SRI.COM.  Professional Societies and Journals

         The IEEE Technical Committee on Security & Privacy publishes a
         quarterly magazine, "CIPHER".

            IEEE Computer Society,
            1730 Massachusetts Ave. N.W.
            Washington, DC  2036-1903

         The ACM SigSAC (Special Interest Group on Security, Audit, and
         Controls) publishes a quarterly magazine, "SIGSAC Review".

            Association for Computing Machinery
            11 West 42nd St.
            New York, N.Y.  10036

         The Information Systems Security Association publishes a
         quarterly magazine called "ISSA Access".

            Information Systems Security Association
            P.O. Box 9457
            Newport Beach, CA  92658

         "Computers and Security" is an "international journal for the
         professional involved with computer security, audit and
         control, and data integrity."
ToP   noToC   RFC1244 - Page 49
            $266/year, 8 issues (1990)

            Elsevier Advanced Technology
            Journal Information Center
            655 Avenue of the Americas
            New York, NY 10010

         The "Data Security Letter" is published "to help data security
         professionals by providing inside information and knowledgable
         analysis of developments in computer and communications

            $690/year, 9 issues (1990)

            Data Security Letter
            P.O. Box 1593
            Palo Alto, CA 94302

   3.9.8  Problem Reporting Tools  Auditing

         Auditing is an important tool that can be used to enhance the
         security of your installation.  Not only does it give you a
         means of identifying who has accessed your system (and may have
         done something to it) but it also gives you an indication of
         how your system is being used (or abused) by authorized users
         and attackers alike.  In addition, the audit trail
         traditionally kept by computer systems can become an invaluable
         piece of evidence should your system be penetrated.
  Verify Security

            An audit trail shows how the system is being used from day
            to day.  Depending upon how your site audit log is
            configured, your log files should show a range of access
            attempts that can show what normal system usage should look
            like.  Deviation from that normal usage could be the result
            of penetration from an outside source using an old or stale
            user account.  Observing a deviation in logins, for example,
            could be your first indication that something unusual is
  Verify Software Configurations

            One of the ruses used by attackers to gain access to a
            system is by the insertion of a so-called Trojan Horse
            program.  A Trojan Horse program can be a program that does
ToP   noToC   RFC1244 - Page 50
            something useful, or merely something interesting.  It
            always does something unexpected, like steal passwords or
            copy files without your knowledge [25].  Imagine a Trojan
            login program that prompts for username and password in the
            usual way, but also writes that information to a special
            file that the attacker can come back and read at will.
            Imagine a Trojan Editor program that, despite the file
            permissions you have given your files, makes copies of
            everything in your directory space without you knowing about

            This points out the need for configuration management of the
            software that runs on a system, not as it is being
            developed, but as it is in actual operation.  Techniques for
            doing this range from checking each command every time it is
            executed against some criterion (such as a cryptoseal,
            described above) or merely checking the date and time stamp
            of the executable.  Another technique might be to check each
            command in batch mode at midnight.  Tools

         COPS is a security tool for system administrators that checks
         for numerous common security problems on UNIX systems [27].
         COPS is a collection of shell scripts and C programs that can
         easily be run on almost any UNIX variant.  Among other things,
         it checks the following items and sends the results to the
         system administrator:

            - Checks "/dev/kmem" and other devices for world

            - Checks special or important files and directories for
              "bad" modes (world writable, etc.).

            - Checks for easily-guessed passwords.

            - Checks for duplicate user ids, invalid fields in the
              password file, etc..

            - Checks for duplicate group ids, invalid fields in the
              group file, etc..

            - Checks all users' home directories and their ".cshrc",
              ".login", ".profile", and ".rhosts" files for security

            - Checks all commands in the "/etc/rc" files and "cron"
ToP   noToC   RFC1244 - Page 51
              files for world writability.

            - Checks for bad "root" paths, NFS file systems exported
              to the world, etc..

            - Includes an expert system that checks to see if a given
              user (usually "root") can be compromised, given that
              certain rules are true.

            - Checks for changes in the setuid status of programs on the

         The COPS package is available from the "comp.sources.unix"
         archive on "", and also from the UNIX-SW repository
         on the MILNET host "".

   3.9.9  Communication Among Administrators  Secure Operating Systems

         The following list of products and vendors is adapted from the
         National Computer Security Center's (NCSC) Evaluated Products
         List.  They represent those companies who have either received
         an evaluation from the NCSC or are in the process of a product
         evaluation.  This list is not complete, but it is
         representative of those operating systems and add on components
         available in the commercial marketplace.

         For a more detailed listing of the current products appearing
         in the NCSC EPL, contact the NCSC at:

            National Computer Security Center
            9800 Savage Road
            Fort George G. Meade, MD  20755-6000
            (301) 859-4458
ToP   noToC   RFC1244 - Page 52
                                                  Version    Evaluation
Evaluated Product               Vendor            Evaluated  Class
Secure Communications           Honeywell Information    2.1         A1
Processor (SCOMP)               Systems, Inc.

Multics                         Honeywell Information    MR11.0      B2
                                Systems, Inc.

System V/MLS 1.1.2 on UNIX      AT&T                     1.1.2       B1
System V 3.1.1 on AT&T 3B2/500and 3B2/600

OS 1100                         Unisys Corp.             Security    B1
                                                         Release 1

MPE V/E                         Hewlett-Packard Computer G.03.04     C2
                                Systems Division

AOS/VS on MV/ECLIPSE series     Data General Corp.        7.60       C2

VM/SP or VM/SP HPO with CMS,    IBM Corp.                    5       C2

MVS/XA with RACF                IBM Corp.                 2.2,2.3    C2

AX/VMS                          Digital Equipment Corp.      4.3     C2

NOS                             Control Data Corp.         NOS
                                                           Security  C2
                                                       Eval Product

TOP SECRET                      CGA Software Products       3.0/163  C2
                                Group, Inc.

Access Control Facility 2       SKK, Inc.                    3.1.3   C2

UTX/32S                         Gould, Inc. Computer          1.0    C2
                                Systems Division

A Series MCP/AS with            Unisys Corp.                  3.7    C2
InfoGuard Security

Primos                          Prime Computer, Inc.    21.0.1DODC2A C2
Resource Access Control         IBM Corp.                     1.5    C1
Facility (RACF)
ToP   noToC   RFC1244 - Page 53
                                                  Version      Candidate
Candidate Product            Vendor               Evaluated    Class
Boeing MLS LAN                  Boeing Aerospace                  A1 M1

Trusted XENIX                   Trusted Information
                                Systems, Inc.                     B2

VSLAN                           VERDIX Corp.                      B2

System V/MLS                    AT&T                              B1

VM/SP with RACF                 IBM Corp.              5/1.8.2    C2
Wang SVS/OS with CAP            Wang Laboratories, Inc.  1.0      C2  Obtaining Fixes for Known Problems

         It goes without saying that computer systems have bugs.  Even
         operating systems, upon which we depend for protection of our
         data, have bugs.  And since there are bugs, things can be
         broken, both maliciously and accidentally.  It is important
         that whenever bugs are discovered, a should fix be identified
         and implemented as soon as possible.  This should minimize any
         exposure caused by the bug in the first place.

         A corollary to the bug problem is: from whom do I obtain the
         fixes?  Most systems have some support from the manufacturer or
         supplier.  Fixes coming from that source tend to be implemented
         quickly after receipt.  Fixes for some problems are often
         posted on the network and are left to the system administrators
         to incorporate as they can.  The problem is that one wants to
         have faith that the fix will close the hole and not introduce
         any others.  We will tend to trust that the manufacturer's
         fixes are better than those that are posted on the net.  Sun Customer Warning System

         Sun Microsystems has established a Customer Warning System
         (CWS) for handling security incidents.  This is a formal
         process which includes:

            - Having a well advertised point of contact in Sun
              for reporting security problems.
            - Pro-actively alerting customers of worms, viruses,
              or other security holes that could affect their systems.
            - Distributing the patch (or work-around) as quickly
              as possible.
ToP   noToC   RFC1244 - Page 54
         They have created an electronic mail address, SECURITY-
         ALERT@SUN.COM, which will enable customers to report security
         problems.  A voice-mail backup is available at (415) 688-9081.
         A "Security Contact" can be designated by each customer site;
         this person will be contacted by Sun in case of any new
         security problems.  For more information, contact your Sun
         representative.  Trusted Archive Servers

         Several sites on the Internet maintain large repositories of
         public-domain and freely distributable software, and make this
         material available for anonymous FTP.  This section describes
         some of the larger repositories.  Note that none of these
         servers implements secure checksums or anything else
         guaranteeing the integrity of their data.  Thus, the notion of
         "trust" should be taken as a somewhat limited definition.
  Sun Fixes on UUNET

            Sun Microsystems has contracted with UUNET Communications
            Services, Inc., to make fixes for bugs in Sun software
            available via anonymous FTP.  You can access these fixes by
            using the "ftp" command to connect to the host FTP.UU.NET.
            Then change into the directory "sun-dist/security", and
            obtain a directory listing.  The file "README" contains a
            brief description of what each file in this directory
            contains, and what is required to install the fix.
  Berkeley Fixes

            The University of California at Berkeley also makes fixes
            available via anonymous FTP; these fixes pertain primarily
            to the current release of BSD UNIX (currently, release 4.3).
            However, even if you are not running their software, these
            fixes are still important, since many vendors (Sun, DEC,
            Sequent, etc.) base their software on the Berkeley releases.

            The Berkeley fixes are available for anonymous FTP from the
            host UCBARPA.BERKELEY.EDU in the directory "4.3/ucb-fixes".
            The file "INDEX" in this directory describes what each file
            contains.  They are also available from UUNET (see section

            Berkeley also distributes new versions of "sendmail" and
            "named" from this machine.  New versions of these commands
            are stored in the "4.3" directory, usually in the files
            "sendmail.tar.Z" and "bind.tar.Z", respectively.
ToP   noToC   RFC1244 - Page 55  Simtel-20 and UUNET

            The two largest general-purpose software repositories on the
            Internet are the hosts WSMR-SIMTEL20.ARMY.MIL and

            WSMR-SIMTEL20.ARMY.MIL is a TOPS-20 machine operated by the
            U.S. Army at White Sands Missile Range (WSMR), New Mexico.
            The directory "pd2:<unix-c>" contains a large amount of UNIX
            software, primarily taken from the "comp.sources"
            newsgroups.  The directories "pd1:<msdos>" and
            "pd2:<msdos2>" contains software for IBM PC systems, and
            "pd3:<macintosh>" contains software for the Apple Macintosh.

            FTP.UU.NET is operated by UUNET Communications Services,
            Inc. in Falls Church, Virginia.  This company sells Internet
            and USENET access to sites all over the country (and
            internationally).  The software posted to the following
            USENET source newsgroups is stored here, in directories of
            the same name:


            Numerous other distributions, such as all the freely
            distributable Berkeley UNIX source code, Internet Request
            for Comments (RFCs), and so on are also stored on this

            Many vendors make fixes for bugs in their software available
            electronically, either via mailing lists or via anonymous
            FTP.  You should contact your vendor to find out if they
            offer this service, and if so, how to access it.  Some
            vendors that offer these services include Sun Microsystems
            (see above), Digital Equipment Corporation (DEC), the
            University of California at Berkeley (see above), and Apple
            Computer [5, CURRY].

(next page on part 3)

Next Section