5.3  Identifying an Incident

5.3.1  Is It Real?

   This stage involves determining if a problem really exists.  Of
   course many if not most signs often associated with virus infection,
   system intrusions, malicious users, etc., are simply anomalies such
   as hardware failures or suspicious system/user behavior.  To assist
   in identifying whether there really is an incident, it is usually
   helpful to obtain and use any detection software which may be
   available.  Audit information is also extremely useful, especially in
   determining whether there is a network attack.  It is extremely
   important to obtain a system snapshot as soon as one suspects that
   something is wrong.  Many incidents cause a dynamic chain of events
   to occur, and an initial system snapshot may be the most valuable
   tool for identifying the problem and any source of attack.  Finally,
   it is important to start a log book.  Recording system events,
   telephone conversations, time stamps, etc., can lead to a more rapid
   and systematic identification of the problem, and is the basis for
   subsequent stages of incident handling.

   There are certain indications or "symptoms" of an incident that
   deserve special attention:

   (1)   System crashes.
   (2)   New user accounts (the account RUMPLESTILTSKIN has been
         unexpectedly created), or high activity on a previously
         low usage account.
   (3)   New files (usually with novel or strange file names,
         such as data.xx or k or .xx ).
   (4)   Accounting discrepancies (in a UNIX system you might
         notice the shrinking of an accounting file called
         /usr/admin/lastlog, something that should make you very
         suspicious that there may be an intruder).
   (5)   Changes in file lengths or dates (a user should be
         suspicious if .EXE files in an MS DOS computer have
         unexplainedly grown by over 1800 bytes).
   (6)   Attempts to write to system (a system manager notices
         that a privileged user in a VMS system is attempting to
         alter RIGHTSLIST.DAT).
   (7)   Data modification or deletion (files start to disappear).
   (8)   Denial of service (a system manager and all other users
         become locked out of a UNIX system, now in single user mode).
   (9)   Unexplained, poor system performance
   (10)  Anomalies ("GOTCHA" is displayed on the console or there
         are frequent unexplained "beeps").
   (11)  Suspicious probes (there are numerous unsuccessful login
         attempts from another node).

   (12)  Suspicious browsing (someone becomes a root user on a UNIX
         system and accesses file after file on many user accounts.)
   (13)  Inability of a user to log in due to modifications of his/her
         account.

   By no means is this list comprehensive; we have just listed a number
   of common indicators.  It is best to collaborate with other technical
   and computer security personnel to make a decision as a group about
   whether an incident is occurring.

5.3.2  Types and Scope of Incidents

   Along with the identification of the incident is the evaluation of
   the scope and impact of the problem.  It is important to correctly
   identify the boundaries of the incident in order to effectively deal
   with it and prioritize responses.

   In order to identify the scope and impact a set of criteria should be
   defined which is appropriate to the site and to the type of
   connections available.  Some of the issues include:

   (1)  Is this a multi-site incident?
   (2)  Are many computers at your site affected by this incident?
   (3)  Is sensitive information involved?
   (4)  What is the entry point of the incident (network,
        phone line, local terminal, etc.)?
   (5)  Is the press involved?
   (6)  What is the potential damage of the incident?
   (7)  What is the estimated time to close out the incident?
   (8)  What resources could be required to handle the incident?
   (9)  Is law enforcement involved?

5.3.3  Assessing the Damage and Extent

   The analysis of the damage and extent of the incident can be quite
   time consuming, but should lead to some insight into the nature of
   the incident, and aid investigation and prosecution.  As soon as the
   breach has occurred, the entire system and all of its components
   should be considered suspect.  System software is the most probable
   target.  Preparation is key to be able to detect all changes for a
   possibly tainted system.  This includes checksumming all media from
   the vendor using a algorithm which is resistant to tampering.  (See
   sections 4.3)

   Assuming original vendor distribution media are available, an
   analysis of all system files should commence, and any irregularities
   should be noted and referred to all parties involved in handling the
   incident.  It can be very difficult, in some cases, to decide which

   backup media are showing a correct system status. Consider, for
   example, that the incident may have continued for months or years
   before discovery, and the suspect may be an employee of the site, or
   otherwise have intimate knowledge or access to the systems.  In all
   cases, the pre-incident preparation will determine what recovery is
   possible.

   If the system supports centralized logging (most do), go back over
   the logs and look for abnormalities.  If process accounting and
   connect time accounting is enabled, look for patterns of system
   usage.  To a lesser extent, disk usage may shed light on the
   incident.  Accounting can provide much helpful information in an
   analysis of an incident and subsequent prosecution.  Your ability to
   address all aspects of a specific incident strongly depends on the
   success of this analysis.

5.4  Handling an Incident

   Certain steps are necessary to take during the handling of an
   incident.  In all security related activities, the most important
   point to be made is that all sites should have policies in place.
   Without defined policies and goals, activities undertaken will remain
   without focus. The goals should be defined by management and legal
   counsel in advance.

   One of the most fundamental objectives is to restore control of the
   affected systems and to limit the impact and damage.  In the worst
   case scenario, shutting down the system, or disconnecting the system
   from the network, may the only practical solution.

   As the activities involved are complex, try to get as much help as
   necessary.  While trying to solve the problem alone, real damage
   might occur due to delays or missing information.  Most
   administrators take the discovery of an intruder as a personal
   challenge.  By proceeding this way, other objectives as outlined in
   the local policies may not always be considered.  Trying to catch
   intruders may be a very low priority, compared to system integrity,
   for example.  Monitoring a hacker's activity is useful, but it might
   not be considered worth the risk to allow the continued access.

5.4.1  Types of Notification and Exchange of Information

   When you have confirmed that an incident is occurring, the
   appropriate personnel must be notified.  How this notification is
   achieved is very important to keeping the event under control both
   from a technical and emotional standpoint. The circumstances should
   be described in as much detail as possible, in order to aid prompt
   acknowledgment and understanding of the problem.  Great care should

   be taken when determining to which groups detailed technical
   information is given during the notification.  For example, it is
   helpful to pass this kind of information to an incident handling team
   as they can assist you by providing helpful hints for eradicating the
   vulnerabilities involved in an incident.  On the other hand, putting
   the critical knowledge into the public domain (e.g., via USENET
   newsgroups or mailing lists) may potentially put a large number of
   systems at risk of intrusion.  It is invalid to assume that all
   administrators reading a particular newsgroup have access to
   operating system source code, or can even understand an advisory well
   enough to take adequate steps.

   First of all, any notification to either local or off-site personnel
   must be explicit.  This requires that any statement (be it an
   electronic mail message, phone call, fax, beeper, or semaphone)
   providing information about the incident be clear, concise, and fully
   qualified.  When you are notifying others that will help you handle
   an event, a "smoke screen" will only divide the effort and create
   confusion.  If a division of labor is suggested, it is helpful to
   provide information to each participant about what is being
   accomplished in other efforts.  This will not only reduce duplication
   of effort, but allow people working on parts of the problem to know
   where to obtain information relevant to their part of the incident.

   Another important consideration when communicating about the incident
   is to be factual.  Attempting to hide aspects of the incident by
   providing false or incomplete information may not only prevent a
   successful resolution to the incident, but may even worsen the
   situation.

   The choice of language used when notifying people about the incident
   can have a profound effect on the way that information is received.
   When you use emotional or inflammatory terms, you raise the potential
   for damage and negative outcomes of the incident.  It is important to
   remain calm both in written and spoken communications.

   Another consideration is that not all people speak the same language.
   Due to this fact, misunderstandings and delay may arise, especially
   if it is a multi-national incident. Other international concerns
   include differing legal implications of a security incident and
   cultural differences.  However, cultural differences do not only
   exist between countries.  They even exist within countries, between
   different social or user groups.  For example, an administrator of a
   university system might be very relaxed about attempts to connect to
   the system via telnet, but the administrator of a military system is
   likely to consider the same action as a possible attack.

   Another issue associated with the choice of language is the
   notification of non-technical or off-site personnel.  It is important
   to accurately describe the incident without generating undue alarm or
   confusion.  While it is more difficult to describe the incident to a
   non-technical audience, it is often more important.  A non-technical
   description may be required for upper-level management, the press, or
   law enforcement liaisons.  The importance of these communications
   cannot be underestimated and may make the difference between
   resolving the incident properly and escalating to some higher level
   of damage.

   If an incident response team becomes involved, it might be necessary
   to fill out a template for the information exchange.  Although this
   may seem to be an additional burden and adds a certain delay, it
   helps the team to act on this minimum set of information.  The
   response team may be able to respond to aspects of the incident of
   which the local administrator is unaware. If information is given out
   to someone else, the following minimum information should be
   provided:

   (1)  timezone of logs, ... in GMT or local time
   (2)  information about the remote system, including host names,
        IP addresses and (perhaps) user IDs
   (3)  all log entries relevant for the remote site
   (4)  type of incident (what happened, why should you care)

   If local information (i.e., local user IDs) is included in the log
   entries, it will be necessary to sanitize the entries beforehand to
   avoid privacy issues.  In general, all information which might assist
   a remote site in resolving an incident should be given out, unless
   local policies prohibit this.

5.4.2  Protecting Evidence and Activity Logs

   When you respond to an incident, document all details related to the
   incident.  This will provide valuable information to yourself and
   others as you try to unravel the course of events.  Documenting all
   details will ultimately save you time.  If you don't document every
   relevant phone call, for example, you are likely to forget a
   significant portion of information you obtain, requiring you to
   contact the source of information again.  At the same time, recording
   details will provide evidence for prosecution efforts, providing the
   case moves in that direction.  Documenting an incident will also help
   you perform a final assessment of damage (something your management,
   as well as law enforcement officers, will want to know), and will
   provide the basis for later phases of the handling process:
   eradication, recovery, and follow-up "lessons learned."

   During the initial stages of an incident, it is often infeasible to
   determine whether prosecution is viable, so you should document as if
   you are gathering evidence for a court case.  At a minimum, you
   should record:

   (1)  all system events (audit records)
   (2)  all actions you take (time tagged)
   (3)  all external conversations (including the person with whom
        you talked, the date and time, and the content of the
        conversation)

   The most straightforward way to maintain documentation is keeping a
   log book.  This allows you to go to a centralized, chronological
   source of information when you need it, instead of requiring you to
   page through individual sheets of paper.  Much of this information is
   potential evidence in a court of law.  Thus, when a legal follow-up
   is a possibility, one should follow the prepared procedures and avoid
   jeopardizing the legal follow-up by improper handling of possible
   evidence. If appropriate, the following steps may be taken.

   (1)  Regularly (e.g., every day) turn in photocopied, signed
        copies of your logbook (as well as media you use to record
        system events) to a document custodian.
   (2)  The custodian should store these copied pages in a secure
        place (e.g., a safe).
   (3)  When you submit information for storage, you should
        receive a signed, dated receipt from the document
        custodian.

   Failure to observe these procedures can result in invalidation of any
   evidence you obtain in a court of law.

5.4.3  Containment

   The purpose of containment is to limit the extent of an attack.  An
   essential part of containment is decision making (e.g., determining
   whether to shut a system down, disconnect from a network, monitor
   system or network activity, set traps, disable functions such as
   remote file transfer, etc.).

   Sometimes this decision is trivial; shut the system down if the
   information is classified, sensitive, or proprietary.  Bear in mind
   that removing all access while an incident is in progress obviously
   notifies all users, including the alleged problem users, that the
   administrators are aware of a problem; this may have a deleterious

   effect on an investigation.  In some cases, it is prudent to remove
   all access or functionality as soon as possible, then restore normal
   operation in limited stages.  In other cases, it is worthwhile to
   risk some damage to the system if keeping the system up might enable
   you to identify an intruder.

   This stage should involve carrying out predetermined procedures.
   Your organization or site should, for example, define acceptable
   risks in dealing with an incident, and should prescribe specific
   actions and strategies accordingly.  This is especially important
   when a quick decision is necessary and it is not possible to first
   contact all involved parties to discuss the decision.  In the absence
   of predefined procedures, the person in charge of the incident will
   often not have the power to make difficult management decisions (like
   to lose the results of a costly experiment by shutting down a
   system).  A final activity that should occur during this stage of
   incident handling is the notification of appropriate authorities.

5.4.4  Eradication

   Once the incident has been contained, it is time to eradicate the
   cause.  But before eradicating the cause, great care should be taken
   to collect all necessary information about the compromised system(s)
   and the cause of the incident as they will likely be lost when
   cleaning up the system.

   Software may be available to help you in the eradication process,
   such as anti-virus software.  If any bogus files have been created,
   archive them before deleting them.  In the case of virus infections,
   it is important to clean and reformat any media containing infected
   files.  Finally, ensure that all backups are clean.  Many systems
   infected with viruses become periodically re-infected simply because
   people do not systematically eradicate the virus from backups.  After
   eradication, a new backup should be taken.

   Removing all vulnerabilities once an incident has occurred is
   difficult.  The key to removing vulnerabilities is knowledge and
   understanding of the breach.

   It may be necessary to go back to the original distribution media and
   re-customize the system.  To facilitate this worst case scenario, a
   record of the original system setup and each customization change
   should be maintained.  In the case of a network-based attack, it is
   important to install patches for each operating system vulnerability
   which was exploited.

   As discussed in section 5.4.2, a security log can be most valuable
   during this phase of removing vulnerabilities. The logs showing how
   the incident was discovered and contained can be used later to help
   determine how extensive the damage was from a given incident.  The
   steps taken can be used in the future to make sure the problem does
   not resurface.  Ideally, one should automate and regularly apply the
   same test as was used to detect the security incident.

   If a particular vulnerability is isolated as having been exploited,
   the next step is to find a mechanism to protect your system.  The
   security mailing lists and bulletins would be a good place to search
   for this information, and you can get advice from incident response
   teams.

5.4.5  Recovery

   Once the cause of an incident has been eradicated, the recovery phase
   defines the next stage of action.  The goal of recovery is to return
   the system to normal.  In general, bringing up services in the order
   of demand to allow a minimum of user inconvenience is the best
   practice.  Understand that the proper recovery procedures for the
   system are extremely important and should be specific to the site.

5.4.6  Follow-Up

   Once you believe that a system has been restored to a "safe" state,
   it is still possible that holes, and even traps, could be lurking in
   the system.  One of the most important stages of responding to
   incidents is also the most often omitted, the follow-up stage.  In
   the follow-up stage, the system should be monitored for items that
   may have been missed during the cleanup stage.  It would be prudent
   to utilize some of the tools mentioned in chapter 7 as a start.
   Remember, these tools don't replace continual system monitoring and
   good systems administration practices.

   The most important element of the follow-up stage is performing a
   postmortem analysis.  Exactly what happened, and at what times?  How
   well did the staff involved with the incident perform?  What kind of
   information did the staff need quickly, and how could they have
   gotten that information as soon as possible?  What would the staff do
   differently next time?

   After an incident, it is prudent to write a report describing the
   exact sequence of events: the method of discovery, correction
   procedure, monitoring procedure, and a summary of lesson learned.
   This will aid in the clear understanding of the problem.  Creating a
   formal chronology of events (including time stamps) is also important
   for legal reasons.

   A follow-up report is valuable for many reasons.  It provides a
   reference to be used in case of other similar incidents.  It is also
   important to, as quickly as possible obtain a monetary estimate of
   the amount of damage the incident caused. This estimate should
   include costs associated with any loss of software and files
   (especially the value of proprietary data that may have been
   disclosed), hardware damage, and manpower costs to restore altered
   files, reconfigure affected systems, and so forth.  This estimate may
   become the basis for subsequent prosecution activity.  The report can
   also help justify an organization's computer security effort to
   management.

5.5  Aftermath of an Incident

   In the wake of an incident, several actions should take place.  These
   actions can be summarized as follows:

   (1)  An inventory should be taken of the systems' assets,
        (i.e., a careful examination should determine how the
        system was affected by the incident).

   (2)  The lessons learned as a result of the incident
        should be included in revised security plan to
        prevent the incident from re-occurring.

   (3)  A new risk analysis should be developed in light of the
        incident.

   (4)  An investigation and prosecution of the individuals
        who caused the incident should commence, if it is
        deemed desirable.

   If an incident is based on poor policy, and unless the policy is
   changed, then one is doomed to repeat the past.  Once a site has
   recovered from and incident, site policy and procedures should be
   reviewed to encompass changes to prevent similar incidents.  Even
   without an incident, it would be prudent to review policies and
   procedures on a regular basis.  Reviews are imperative due to today's
   changing computing environments.

   The whole purpose of this post mortem process is to improve all
   security measures to protect the site against future attacks.  As a
   result of an incident, a site or organization should gain practical
   knowledge from the experience.  A concrete goal of the post mortem is
   to develop new proactive methods.  Another important facet of the
   aftermath may be end user and administrator education to prevent a
   reoccurrence of the security problem.

5.6  Responsibilities

5.6.1  Not Crossing the Line

   It is one thing to protect one's own network, but quite another to
   assume that one should protect other networks.  During the handling
   of an incident, certain system vulnerabilities of one's own systems
   and the systems of others become apparent.  It is quite easy and may
   even be tempting to pursue the intruders in order to track them.
   Keep in mind that at a certain point it is possible to "cross the
   line," and, with the best of intentions, become no better than the
   intruder.

   The best rule when it comes to propriety is to not use any facility
   of remote sites which is not public.  This clearly excludes any entry
   onto a system (such as a remote shell or login session) which is not
   expressly permitted.  This may be very tempting; after a breach of
   security is detected, a system administrator may have the means to
   "follow it up," to ascertain what damage is being done to the remote
   site.  Don't do it!  Instead, attempt to reach the appropriate point
   of contact for the affected site.

5.6.2  Good Internet Citizenship

   During a security incident there are two choices one can make.
   First, a site can choose to watch the intruder in the hopes of
   catching him; or, the site can go about cleaning up after the
   incident and shut the intruder out of the systems.  This is a
   decision that must be made very thoughtfully, as there may be legal
   liabilities if you choose to leave your site open, knowing that an
   intruder is using your site as a launching pad to reach out to other
   sites.  Being a good Internet citizen means that you should try to
   alert other sites that may have been impacted by the intruder.  These
   affected sites may be readily apparent after a thorough review of
   your log files.

5.6.3  Administrative Response to Incidents

   When a security incident involves a user, the site's security policy
   should describe what action is to be taken.  The transgression should
   be taken seriously, but it is very important to be sure of the role
   the user played.  Was the user naive?  Could there be a mistake in
   attributing the security breach to the user?  Applying administrative
   action that assumes the user intentionally caused the incident may

   not be appropriate for a user who simply made a mistake.  It may be
   appropriate to include sanctions more suitable for such a situation
   in your policies (e.g., education or reprimand of a user) in addition
   to more stern measures for intentional acts of intrusion and system
   misuse.

6.  Ongoing Activities

   At this point in time, your site has hopefully developed a complete
   security policy and has developed procedures to assist in the
   configuration and management of your technology in support of those
   policies.  How nice it would be if you could sit back and relax at
   this point and know that you were finished with the job of security.
   Unfortunately, that isn't possible.  Your systems and networks are
   not a static environment, so you will need to review policies and
   procedures on a regular basis.  There are a number of steps you can
   take to help you keep up with the changes around you so that you can
   initiate corresponding actions to address those changes.  The
   following is a starter set and you may add others as appropriate for
   your site.

   (1)  Subscribe to advisories that are issued by various security incident
        response teams, like those of the CERT Coordination Center, and
        update your systems against those threats that apply to your site's
        technology.

   (2)  Monitor security patches that are produced by the vendors of your
        equipment, and obtain and install all that apply.

   (3)  Actively watch the configurations of your systems to identify any
        changes that may have occurred, and investigate all anomalies.

   (4)  Review all security policies and procedures annually (at a minimum).

   (5)  Read relevant mailing lists and USENET newsgroups to keep up to
        date with the latest information being shared by fellow
        administrators.

   (6)  Regularly check for compliance with policies and procedures.  This
        audit should be performed by someone other than the people who
        define or implement the policies and procedures.

7.  Tools and Locations

   This chapter provides a brief list of publicly available security
   technology which can be downloaded from the Internet.  Many of the
   items described below will undoubtedly be surpassed or made obsolete
   before this document is published.

   Some of the tools listed are applications such as end user programs
   (clients) and their supporting system infrastructure (servers).
   Others are tools that a general user will never see or need to use,
   but may be used by applications, or by administrators to troubleshoot
   security problems or to guard against intruders.

   A sad fact is that there are very few security conscious applications
   currently available. Primarily, this is caused by the need for a
   security infrastructure which must first be put into place for most
   applications to operate securely.  There is considerable effort
   currently taking place to build this infrastructure so that
   applications can take advantage of secure communications.

   Most of the tools and applications described below can be found in
   one of the following archive sites:

   (1)  CERT Coordination Center
        ftp://info.cert.org:/pub/tools
   (2)  DFN-CERT
        ftp://ftp.cert.dfn.de/pub/tools/
   (3)  Computer Operations, Audit, and Security Tools (COAST)
        coast.cs.purdue.edu:/pub/tools

   It is important to note that many sites, including CERT and COAST are
   mirrored throughout the Internet.  Be careful to use a "well known"
   mirror site to retrieve software, and to use verification tools (md5
   checksums, etc.) to validate that software.  A clever cracker might
   advertise security software that has intentionally been designed to
   provide access to data or systems.

Tools

   COPS
   DES
   Drawbridge
   identd (not really a security tool)
   ISS
   Kerberos
   logdaemon
   lsof
   MD5
   PEM
   PGP
   rpcbind/portmapper replacement
   SATAN
   sfingerd
   S/KEY
   smrsh

   ssh
   swatch
   TCP-Wrapper
   tiger
   Tripwire*
   TROJAN.PL

8.  Mailing Lists and Other Resources

   It would be impossible to list all of the mail-lists and other
   resources dealing with site security. However, these are some "jump-
   points"  from which the reader can begin. All of these references are
   for the "INTERNET" constituency. More specific (vendor and
   geographical) resources can be found through these references.

   Mailing Lists

   (1)  CERT(TM) Advisory
        Send mail to:  cert-advisory-request@cert.org
        Message Body:  subscribe cert <FIRST NAME> <LAST NAME>

        A CERT advisory provides information on how to obtain a patch or
        details of a workaround for a known computer security problem.
        The CERT Coordination Center works with vendors to produce a
        workaround or a patch for a problem, and does not publish
        vulnerability information until a workaround or a patch is
        available. A CERT advisory may also be a warning to our
        constituency about ongoing attacks (e.g.,
        "CA-91:18.Active.Internet.tftp.Attacks").


        CERT advisories are also published on the USENET newsgroup:
                     comp.security.announce

        CERT advisory archives are available via anonymous FTP from
        info.cert.org in the /pub/cert_advisories directory.

   (2)  VIRUS-L List
        Send mail to:  listserv%lehiibm1.bitnet@mitvma.mit.edu
        Message Body:  subscribe virus-L FIRSTNAME LASTNAME

        VIRUS-L is a moderated mailing list with a focus
        on computer virus issues.  For more information,
        including a copy of the posting guidelines, see
        the file "virus-l.README", available by anonymous
        FTP from cs.ucr.edu.

   (3)  Internet Firewalls
        Send mail to:  majordomo@greatcircle.com
        Message Body:  subscribe firewalls user@host

        The Firewalls mailing list is a discussion forum for
        firewall administrators and implementors.

   USENET newsgroups

   (1)  comp.security.announce
        The comp.security.announce newsgroup is moderated
        and is used solely for the distribution of CERT
        advisories.

   (2)  comp.security.misc
        The comp.security.misc is a forum for the
        discussion of computer security, especially as it
        relates to the UNIX(r) Operating System.

   (3)  alt.security
        The alt.security newsgroup is also a forum for the
        discussion of computer security, as well as other
        issues such as car locks and alarm systems.

   (4)  comp.virus
        The comp.virus newsgroup is a moderated newsgroup
        with a focus on computer virus issues.  For more
        information, including a copy of the posting
        guidelines, see the file "virus-l.README",
        available via anonymous FTP on info.cert.org
        in the /pub/virus-l directory.

   (5)  comp.risks
        The comp.risks newsgroup is a moderated forum on
        the risks to the public in computers and related
        systems.

   World-Wide Web Pages

   (1)  http://www.first.org/

        Computer Security Resource Clearinghouse. The main focus is on
        crisis response information; information on computer
        security-related threats, vulnerabilities, and solutions. At the
        same time, the Clearinghouse strives to be a general index to
        computer security information on a broad variety of subjects,
        including general risks, privacy, legal issues, viruses,
        assurance, policy, and training.

   (2)  http://www.telstra.com.au/info/security.html

        This Reference Index contains a list of links to information
        sources on Network and Computer Security. There is no implied
        fitness to the Tools, Techniques and Documents contained within this
        archive. Many if not all of these items work well, but we do
        not guarantee that this will be so. This information is for the
        education and legitimate use of computer security techniques only.

   (3)  http://www.alw.nih.gov/Security/security.html

        This page features general information about computer security.
        Information is organized by source and each section is organized
        by topic. Recent modifications are noted in What's New page.

   (4)  http://csrc.ncsl.nist.gov

        This archive at the National Institute of Standards and Technology's
        Computer Security Resource Clearinghouse page contains a number of
        announcements, programs, and documents related to computer security.

   * CERT and Tripwire are registered in the U.S. Patent and Trademark Office

9.  References

   The following references may not be available in all countries.

   [Appelman, et. al., 1995] Appelman, Heller, Ehrman, White, and
   McAuliffe, "The Law and The Internet", USENIX 1995 Technical
   Conference on UNIX and Advanced Computing, New Orleans, LA, January
   16-20, 1995.

   [ABA, 1989] American Bar Association, Section of Science and
   Technology, "Guide to the Prosecution of Telecommunication Fraud by
   the Use of Computer Crime Statutes", American Bar Association, 1989.

   [Aucoin, 1989] R. Aucoin, "Computer Viruses: Checklist for Recovery",
   Computers in  Libraries, Vol. 9, No. 2, Pg. 4, February 1989.

   [Barrett, 1996] D. Barrett, "Bandits on the Information
   Superhighway", O'Reilly & Associates, Sebastopol, CA, 1996.

   [Bates, 1992] R. Bates, "Disaster Recovery Planning: Networks,
   Telecommunications and Data Communications", McGraw-Hill, 1992.

   [Bellovin, 1989] S. Bellovin, "Security Problems in the TCP/IP
   Protocol Suite", Computer Communication Review, Vol 19, 2, pp. 32-48,
   April 1989.

   [Bellovin, 1990] S. Bellovin, and M. Merritt, "Limitations of the
   Kerberos Authentication System", Computer Communications Review,
   October 1990.

   [Bellovin, 1992] S. Bellovin, "There Be Dragon", USENIX: Proceedings
   of the Third Usenix Security Symposium, Baltimore, MD. September,
   1992.

   [Bender, 1894] D. Bender, "Computer Law: Evidence and Procedure", M.
   Bender, New York, NY, 1978-present.

   [Bloombecker, 1990] B. Bloombecker, "Spectacular Computer Crimes",
   Dow Jones- Irwin, Homewood, IL. 1990.

   [Brand, 1990] R. Brand, "Coping with the Threat of Computer Security
   Incidents: A Primer from Prevention through Recovery", R. Brand, 8
   June 1990.

   [Brock, 1989] J. Brock, "November 1988 Internet Computer Virus and
   the Vulnerability of National Telecommunications Networks to Computer
   Viruses", GAO/T-IMTEC-89-10, Washington, DC, 20 July 1989.

   [BS 7799] British Standard, BS Tech Cttee BSFD/12, Info. Sec. Mgmt,
   "BS 7799 : 1995 Code of Practice for Information Security
   Management", British Standards Institution, London, 54, Effective 15
   February 1995.

   [Caelli, 1988] W. Caelli, Editor, "Computer Security in the Age of
   Information", Proceedings of the Fifth IFIP International Conference
   on Computer Security, IFIP/Sec '88.

   [Carroll, 1987] J. Carroll, "Computer Security", 2nd Edition,
   Butterworth Publishers, Stoneham, MA, 1987.

   [Cavazos and Morin, 1995] E. Cavazos and G. Morin, "Cyber-Space and
   The Law", MIT Press, Cambridge, MA, 1995.

   [CCH, 1989] Commerce Clearing House, "Guide to Computer Law",
   (Topical Law Reports), Chicago, IL., 1989.

   [Chapman, 1992] B. Chapman, "Network(In) Security Through IP Packet
   Filtering", USENIX: Proceedings of the Third UNIX Security Symposium,
   Baltimore, MD, September 1992.

   [Chapman and Zwicky, 1995] B. Chapman and E. Zwicky, "Building
   Internet Firewalls", O'Reilly and Associates, Sebastopol, CA, 1995.

   [Cheswick, 1990] B. Cheswick, "The Design of a Secure Internet
   Gateway", Proceedings of the Summer Usenix Conference, Anaheim, CA,
   June 1990.

   [Cheswick1] W. Cheswick, "An Evening with Berferd In Which a Cracker
   is Lured, Endured, and Studied", AT&T Bell Laboratories.

   [Cheswick and Bellovin, 1994] W. Cheswick and S. Bellovin, "Firewalls
   and Internet Security: Repelling the Wily Hacker", Addison-Wesley,
   Reading, MA, 1994.

   [Conly, 1989] C. Conly, "Organizing for Computer Crime Investigation
   and Prosecution", U.S. Dept. of Justice, Office of Justice Programs,
   Under Contract  Number OJP-86-C-002, National Institute of Justice,
   Washington, DC, July 1989.

   [Cooper, 1989] J. Cooper, "Computer and Communications Security:
   Strategies for the 1990s", McGraw-Hill, 1989.

   [CPSR, 1989] Computer Professionals for Social Responsibility, "CPSR
   Statement on the Computer Virus", CPSR, Communications of the ACM,
   Vol. 32, No. 6, Pg. 699, June 1989.

   [CSC-STD-002-85, 1985] Department of Defense, "Password Management
   Guideline", CSC-STD-002-85, 12 April 1985, 31 pages.

   [Curry, 1990] D. Curry, "Improving the Security of Your UNIX System",
   SRI International Report ITSTD-721-FR-90-21, April 1990.

   [Curry, 1992] D. Curry, "UNIX System Security: A Guide for Users and
   Systems Administrators", Addision-Wesley, Reading, MA, 1992.

   [DDN88] Defense Data Network, "BSD 4.2 and 4.3 Software Problem
   Resolution", DDN MGT Bulletin #43, DDN Network Information Center, 3
   November 1988.

   [DDN89] DCA DDN Defense Communications System, "DDN Security Bulletin
   03", DDN Security Coordination Center, 17 October 1989.

   [Denning, 1990] P. Denning, Editor, "Computers Under Attack:
   Intruders, Worms, and Viruses", ACM Press, 1990.

   [Eichin and Rochlis, 1989] M. Eichin, and J. Rochlis, "With
   Microscope and Tweezers: An Analysis of the Internet Virus of
   November 1988", Massachusetts Institute of Technology, February 1989.

   [Eisenberg, et. al., 89] T. Eisenberg, D. Gries, J. Hartmanis, D.
   Holcomb, M. Lynn, and T. Santoro, "The Computer Worm", Cornell
   University, 6 February 1989.

   [Ermann, Willians, and Gutierrez, 1990] D. Ermann, M. Williams, and
   C. Gutierrez, Editors, "Computers, Ethics, and Society", Oxford
   University Press, NY, 1990.  (376 pages, includes bibliographical
   references).

   [Farmer and Spafford, 1990] D. Farmer and E. Spafford, "The COPS
   Security Checker System", Proceedings of the Summer 1990 USENIX
   Conference, Anaheim, CA, Pgs. 165-170, June 1990.

   [Farrow, 1991] Rik Farrow, "UNIX Systems Security", Addison-Wesley,
   Reading, MA, 1991.

   [Fenwick, 1985] W. Fenwick, Chair, "Computer Litigation, 1985: Trial
   Tactics and Techniques", Litigation Course Handbook Series No. 280,
   Prepared for distribution at the Computer Litigation, 1985: Trial
   Tactics and Techniques Program, February-March 1985.

   [Fites 1989] M. Fites, P. Kratz, and A. Brebner, "Control and
   Security of Computer Information Systems", Computer Science Press,
   1989.

   [Fites, Johnson, and Kratz, 1992] Fites, Johnson, and Kratz, "The
   Computer Virus Crisis", Van Hostrand Reinhold, 2nd edition, 1992.

   [Forester and Morrison, 1990] T. Forester, and P. Morrison, "Computer
   Ethics: Tales and Ethical Dilemmas in Computing", MIT Press,
   Cambridge, MA, 1990.

   [Foster and Morrision, 1990] T. Forester, and P. Morrison, "Computer
   Ethics: Tales and Ethical Dilemmas in Computing", MIT Press,
   Cambridge, MA, 1990.  (192 pages including index.)

   [GAO/IMTEX-89-57, 1989] U.S. General Accounting Office, "Computer
   Security - Virus Highlights Need for Improved Internet Management",
   United States General Accounting Office, Washington, DC, 1989.

   [Garfinkel and Spafford, 1991] S. Garfinkel, and E. Spafford,
   "Practical Unix Security", O'Reilly & Associates, ISBN 0-937175-72-2,
   May 1991.

   [Garfinkel, 1995] S. Garfinkel, "PGP:Pretty Good Privacy", O'Reilly &
   Associates, Sebastopol, CA, 1996.

   [Garfinkel and Spafford, 1996] S. Garfinkel and E. Spafford,
   "Practical UNIX and Internet Security", O'Reilly & Associates,
   Sebastopol, CA, 1996.

   [Gemignani, 1989] M. Gemignani, "Viruses and Criminal Law",
   Communications of the ACM, Vol. 32, No. 6, Pgs. 669-671, June 1989.

   [Goodell, 1996] J. Goodell, "The Cyberthief and the Samurai: The True
   Story of Kevin Mitnick-And The Man Who Hunted Him Down", Dell
   Publishing, 1996.

   [Gould, 1989] C. Gould, Editor, "The Information Web: Ethical and
   Social Implications of Computer Networking", Westview Press, Boulder,
   CO, 1989.

   [Greenia, 1989] M. Greenia, "Computer Security Information
   Sourcebook", Lexikon Services, Sacramento, CA, 1989.

   [Hafner and Markoff, 1991] K. Hafner and J. Markoff, "Cyberpunk:
   Outlaws and Hackers on the Computer Frontier", Touchstone, Simon &
   Schuster, 1991.

   [Hess, Safford, and Pooch] D. Hess, D. Safford, and U. Pooch, "A Unix
   Network Protocol Security Study: Network Information Service", Texas
   A&M University.

   [Hoffman, 1990] L. Hoffman, "Rogue Programs: Viruses, Worms, and
   Trojan Horses", Van Nostrand Reinhold, NY, 1990.  (384 pages,
   includes bibliographical references and index.)

   [Howard, 1995] G. Howard, "Introduction to Internet Security: From
   Basics to Beyond", Prima Publishing, Rocklin, CA, 1995.

   [Huband and Shelton, 1986] F. Huband, and R. Shelton, Editors,
   "Protection of Computer Systems and Software: New Approaches for
   Combating Theft of Software and Unauthorized Intrusion", Papers
   presented at a workshop sponsored by the National Science Foundation,
   1986.

   [Hughes, 1995] L. Hughes Jr., "Actually Useful Internet Security
   Techniques", New Riders Publishing, Indianapolis, IN, 1995.

   [IAB-RFC1087, 1989] Internet Activities Board, "Ethics and the
   Internet", RFC 1087, IAB, January 1989.  Also appears in the
   Communications of the ACM, Vol. 32, No. 6, Pg. 710, June 1989.

   [Icove, Seger, and VonStorch, 1995] D. Icove, K. Seger, and W.
   VonStorch, "Computer Crime: A Crimefighter's Handbook", O'Reilly &
   Associates, Sebastopol, CA, 1995.

   [IVPC, 1996] IVPC, "International Virus Prevention Conference '96
   Proceedings", NCSA, 1996.

   [Johnson and Podesta] D. Johnson, and J. Podesta, "Formulating A
   Company Policy on Access to and Use and Disclosure of Electronic Mail
   on Company Computer Systems".

   [Kane, 1994] P. Kane, "PC Security and Virus Protection Handbook: The
   Ongoing War Against Information Sabotage", M&T Books, 1994.

   [Kaufman, Perlman, and Speciner, 1995] C. Kaufman, R. Perlman, and M.
   Speciner, "Network Security: PRIVATE Communication in a PUBLIC
   World", Prentice Hall, Englewood Cliffs, NJ, 1995.

   [Kent, 1990] S. Kent, "E-Mail Privacy for the Internet: New Software
   and Strict Registration Procedures will be Implemented this Year",
   Business Communications Review, Vol. 20, No. 1, Pg. 55, 1 January
   1990.

   [Levy, 1984] S. Levy, "Hacker: Heroes of the Computer Revolution",
   Delta, 1984.

   [Lewis, 1996] S. Lewis, "Disaster Recovery Yellow Pages", The Systems
   Audit Group, 1996.

   [Littleman, 1996] J. Littleman, "The Fugitive Game: Online with Kevin
   Mitnick", Little, Brown, Boston, MA., 1996.

   [Lu and Sundareshan, 1989] W. Lu and M. Sundareshan, "Secure
   Communication in Internet Environments: A Hierarchical Key Management
   Scheme for End-to-End Encryption", IEEE Transactions on
   Communications, Vol. 37, No. 10, Pg. 1014, 1 October 1989.

   [Lu and Sundareshan, 1990] W. Lu and M. Sundareshan, "A Model for
   Multilevel Security in Computer Networks", IEEE Transactions on
   Software Engineering, Vol. 16, No. 6, Page 647, 1 June 1990.

   [Martin and Schinzinger, 1989] M. Martin, and R. Schinzinger, "Ethics
   in Engineering", McGraw Hill, 2nd Edition, 1989.

   [Merkle] R. Merkle, "A Fast Software One Way Hash Function", Journal
   of Cryptology, Vol. 3, No. 1.

   [McEwen, 1989] J. McEwen, "Dedicated Computer Crime Units", Report
   Contributors: D. Fester and H. Nugent, Prepared for the National
   Institute of Justice, U.S. Department of Justice, by Institute for
   Law and Justice, Inc., under contract number OJP-85-C-006,
   Washington, DC, 1989.

   [MIT, 1989] Massachusetts Institute of Technology, "Teaching Students
   About Responsible Use of Computers", MIT, 1985-1986.  Also reprinted
   in the Communications of the ACM, Vol. 32, No. 6, Pg. 704, Athena
   Project, MIT, June 1989.

   [Mogel, 1989] Mogul, J., "Simple and Flexible Datagram Access
   Controls for UNIX-based Gateways", Digital Western Research
   Laboratory Research Report 89/4, March 1989.

   [Muffett, 1992] A. Muffett, "Crack Version 4.1: A Sensible Password
   Checker for Unix"

   [NCSA1, 1995] NCSA, "NCSA Firewall Policy Guide", 1995.

   [NCSA2, 1995] NCSA, "NCSA's Corporate Computer Virus Prevention
   Policy Model", NCSA, 1995.

   [NCSA, 1996] NCSA, "Firewalls & Internet Security Conference '96
   Proceedings", 1996.

   [NCSC-89-660-P, 1990] National Computer Security Center, "Guidelines
   for Formal Verification Systems", Shipping list no.: 89-660-P, The
   Center, Fort George G. Meade, MD, 1 April 1990.

   [NCSC-89-254-P, 1988] National Computer Security Center, "Glossary of
   Computer Security Terms", Shipping list no.: 89-254-P, The Center,
   Fort George G. Meade, MD, 21 October 1988.

   [NCSC-C1-001-89, 1989] Tinto, M., "Computer Viruses: Prevention,
   Detection, and Treatment", National Computer Security Center C1
   Technical Report C1-001-89, June 1989.

   [NCSC Conference, 1989] National Computer Security Conference, "12th
   National Computer Security Conference: Baltimore Convention Center,
   Baltimore, MD, 10-13 October, 1989: Information Systems Security,
   Solutions for Today - Concepts for Tomorrow", National Institute of
   Standards and National Computer Security Center, 1989.

   [NCSC-CSC-STD-003-85, 1985] National Computer Security Center,
   "Guidance for Applying the Department of Defense Trusted Computer
   System Evaluation Criteria in Specific Environments", CSC-STD-003-85,
   NCSC, 25 June 1985.

   [NCSC-STD-004-85, 1985] National Computer Security Center, "Technical
   Rationale Behind CSC-STD-003-85: Computer Security Requirements",
   CSC-STD-004-85, NCSC, 25 June 1985.

   [NCSC-STD-005-85, 1985] National Computer Security Center, "Magnetic
   Remanence Security Guideline", CSC-STD-005-85, NCSC, 15 November
   1985.

   [NCSC-TCSEC, 1985] National Computer Security Center, "Trusted
   Computer System Evaluation Criteria", DoD 5200.28-STD, CSC-STD-001-
   83, NCSC, December 1985.

   [NCSC-TG-003, 1987] NCSC, "A Guide to Understanding DISCRETIONARY
   ACCESS CONTROL in Trusted Systems", NCSC-TG-003, Version-1, 30
   September 1987, 29 pages.

   [NCSC-TG-001, 1988] NCSC, "A Guide to Understanding AUDIT in Trusted
   Systems", NCSC-TG-001, Version-2, 1 June 1988, 25 pages.

   [NCSC-TG-004, 1988] National Computer Security Center, "Glossary of
   Computer Security Terms", NCSC-TG-004, NCSC, 21 October 1988.

   [NCSC-TG-005, 1987] National Computer Security Center, "Trusted
   Network Interpretation", NCSC-TG-005, NCSC, 31 July 1987.

   [NCSC-TG-006, 1988] NCSC, "A Guide to Understanding CONFIGURATION
   MANAGEMENT in Trusted Systems", NCSC-TG-006, Version-1, 28 March
   1988, 31 pages.

   [NCSC-TRUSIX, 1990] National Computer Security Center, "Trusted UNIX
   Working Group (TRUSIX) rationale for selecting access control list
   features for the UNIX system", Shipping list no.: 90-076-P, The
   Center, Fort George G. Meade, MD, 1990.

   [NRC, 1991] National Research Council, "Computers at Risk: Safe
   Computing in the Information Age", National Academy Press, 1991.

   [Nemeth, et. al, 1995] E. Nemeth, G. Snyder, S. Seebass, and T. Hein,
   "UNIX Systems Administration Handbook", Prentice Hall PTR, Englewood
   Cliffs, NJ, 2nd ed. 1995.

   [NIST, 1989] National Institute of Standards and Technology,
   "Computer Viruses and Related Threats: A Management Guide", NIST
   Special Publication 500-166, August 1989.

   [NSA] National Security Agency, "Information Systems Security
   Products and Services Catalog", NSA, Quarterly Publication.

   [NSF, 1988] National Science Foundation, "NSF Poses Code of
   Networking Ethics", Communications of the ACM, Vol. 32, No. 6, Pg.
   688, June 1989.  Also appears in the minutes of the regular meeting
   of the Division Advisory Panel for Networking and Communications
   Research and Infrastructure, Dave Farber, Chair, November 29-30,
   1988.

   [NTISSAM, 1987] NTISS, "Advisory Memorandum on Office Automation
   Security Guideline", NTISSAM COMPUSEC/1-87, 16 January 1987, 58
   pages.

   [OTA-CIT-310, 1987] United States Congress, Office of Technology
   Assessment, "Defending Secrets, Sharing Data: New Locks and Keys for
   Electronic Information", OTA-CIT-310, October 1987.

   [OTA-TCT-606] Congress of the United States, Office of Technology
   Assessment, "Information Security and Privacy in Network
   Environments", OTA-TCT-606, September 1994.

   [Palmer and Potter, 1989] I. Palmer, and G. Potter, "Computer
   Security Risk Management", Van Nostrand Reinhold, NY, 1989.

   [Parker, 1989] D. Parker, "Computer Crime: Criminal Justice Resource
   Manual", U.S. Dept. of Justice, National Institute of Justice, Office
   of Justice Programs, Under Contract Number OJP-86-C-002, Washington,
   D.C., August 1989.

   [Parker, Swope, and Baker, 1990] D. Parker, S. Swope, and B. Baker,
   "Ethical Conflicts: Information and Computer Science, Technology and
   Business", QED Information Sciences, Inc., Wellesley, MA. (245
   pages).

   [Pfleeger, 1989] C. Pfleeger, "Security in Computing", Prentice-Hall,
   Englewood Cliffs, NJ, 1989.

   [Quarterman, 1990] J. Quarterman, J., "The Matrix: Computer Networks
   and Conferencing Systems Worldwide", Digital Press, Bedford, MA,
   1990.

   [Ranum1, 1992] M. Ranum, "An Internet Firewall", Proceedings of World
   Conference on Systems Management and Security, 1992.

   [Ranum2, 1992] M. Ranum, "A Network Firewall", Digital Equipment
   Corporation Washington Open Systems Resource Center, June 12, 1992.

   [Ranum, 1993] M. Ranum, "Thinking About Firewalls", 1993.

   [Ranum and Avolio, 1994] M. Ranum and F. Avolio, "A Toolkit and
   Methods for Internet Firewalls", Trustest Information Systems, 1994.

   [Reinhardt, 1992] R. Reinhardt, "An Architectural Overview of UNIX
   Network Security"

   [Reinhardt, 1993] R. Reinhardt, "An Architectural Overview of UNIX
   Network Security", ARINC Research Corporation, February 18, 1993.

   [Reynolds-RFC1135, 1989] The Helminthiasis of the Internet, RFC 1135,
   USC/Information Sciences Institute, Marina del Rey, CA, December
   1989.

   [Russell and Gangemi, 1991] D. Russell and G. Gangemi, "Computer
   Security Basics" O'Reilly & Associates, Sebastopol, CA, 1991.

   [Schneier 1996] B. Schneier, "Applied Cryptography: Protocols,
   Algorithms, and Source Code in C", John Wiley & Sons, New York,
   second edition, 1996.

   [Seeley, 1989] D. Seeley, "A Tour of the Worm", Proceedings of 1989
   Winter USENIX Conference, Usenix Association, San Diego, CA, February
   1989.

   [Shaw, 1986] E. Shaw Jr., "Computer Fraud and Abuse Act of 1986",
   Congressional Record (3 June 1986), Washington, D.C., 3 June 1986.

   [Shimomura, 1996] T. Shimomura with J. Markoff, "Takedown:The Pursuit
   and Capture of Kevin Mitnick, America's Most Wanted Computer Outlaw-
   by the Man Who Did It", Hyperion, 1996.

   [Shirey, 1990] R. Shirey, "Defense Data Network Security
   Architecture", Computer Communication Review, Vol. 20, No. 2, Page
   66, 1 April 1990.

   [Slatalla and Quittner, 1995] M. Slatalla and J. Quittner, "Masters
   of Deception: The Gang that Ruled Cyberspace", Harper Collins
   Publishers, 1995.

   [Smith, 1989] M. Smith, "Commonsense Computer Security: Your
   Practical Guide to Preventing Accidental and Deliberate Electronic
   Data Loss", McGraw-Hill, New York, NY, 1989.

   [Smith, 1995] D. Smith, "Forming an Incident Response Team", Sixth
   Annual Computer Security Incident Handling Workshop, Boston, MA, July
   25-29, 1995.

   [Spafford, 1988] E. Spafford, "The Internet Worm Program: An
   Analysis", Computer Communication Review, Vol. 19, No. 1, ACM SIGCOM,
   January 1989.  Also issued as Purdue CS Technical Report CSD-TR-823,
   28 November 1988.

   [Spafford, 1989] G. Spafford, "An Analysis of the Internet Worm",
   Proceedings of the European Software Engineering Conference 1989,
   Warwick England, September 1989.  Proceedings published by Springer-
   Verlag as: Lecture Notes in Computer Science #387.  Also issued as
   Purdue Technical Report #CSD-TR-933.

   [Spafford, Keaphy, and Ferbrache, 1989] E. Spafford, K. Heaphy, and
   D. Ferbrache, "Computer Viruses: Dealing with Electronic Vandalism
   and Programmed Threats", ADAPSO, 1989. (109 pages.)

   [Stallings1, 1995] W. Stallings, "Internet Security Handbook", IDG
   Books, Foster City CA, 1995.

   [Stallings2, 1995] W. Stallings, "Network and InterNetwork Security",
   Prentice Hall, , 1995.

   [Stallings3, 1995] W. Stallings, "Protect Your Privacy: A Guide for
   PGP Users"  PTR Prentice Hall, 1995.

   [Stoll, 1988] C. Stoll, "Stalking the Wily Hacker", Communications of
   the ACM, Vol. 31, No. 5, Pgs. 484-497, ACM, New York, NY, May 1988.

   [Stoll, 1989] C. Stoll, "The Cuckoo's Egg", ISBN 00385-24946-2,
   Doubleday, 1989.

   [Treese and Wolman, 1993] G. Treese and A. Wolman, "X Through the
   Firewall, and Other Applications Relays", Digital Equipment
   Corporation, Cambridge Research Laboratory, CRL 93/10, May 3, 1993.

   [Trible, 1986] P. Trible, "The Computer Fraud and Abuse Act of 1986",
   U.S. Senate Committee on the Judiciary, 1986.

   [Venema] W. Venema, "TCP WRAPPER: Network monitoring, access control,
   and booby traps", Mathematics and Computing Science, Eindhoven
   University of Technology, The Netherlands.

   [USENIX, 1988] USENIX, "USENIX Proceedings: UNIX Security Workshop",
   Portland, OR, August 29-30, 1988.

   [USENIX, 1990] USENIX, "USENIX Proceedings: UNIX Security II
   Workshop", Portland, OR, August 27-28, 1990.

   [USENIX, 1992] USENIX, "USENIX Symposium Proceedings: UNIX Security
   III", Baltimore, MD, September 14-16, 1992.

   [USENIX, 1993] USENIX, "USENIX Symposium Proceedings: UNIX Security
   IV", Santa Clara, CA, October 4-6, 1993.

   [USENIX, 1995] USENIX, "The Fifth USENIX UNIX Security Symposium",
   Salt Lake City, UT, June 5-7, 1995.

   [Wood, et.al., 1987] C. Wood, W. Banks, S. Guarro, A. Garcia, V.
   Hampel, and H. Sartorio, "Computer Security:  A Comprehensive
   Controls Checklist", John Wiley and Sons, Interscience Publication,
   1987.

   [Wrobel, 1993] L. Wrobel, "Writing Disaster Recovery Plans for
   Telecommunications Networks and LANS", Artech House, 1993.

   [Vallabhaneni, 1989] S. Vallabhaneni, "Auditing Computer Security: A
   Manual with Case Studies", Wiley, New York, NY, 1989.

Security Considerations

   This entire document discusses security issues.

Editor Information

   Barbara Y. Fraser
   Software Engineering Institute
   Carnegie Mellon University
   5000 Forbes Avenue
   Pittsburgh, PA 15213

   Phone: (412) 268-5010
   Fax:   (412) 268-6989
   EMail: byf@cert.org