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
(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
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
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
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
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
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
(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
(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
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
Failure to observe these procedures can result in invalidation of any
evidence you obtain in a court of law.
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.
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
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.
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
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
(4) An investigation and prosecution of the individuals
who caused the incident should commence, if it is
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.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
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
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
(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
(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
(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
(3) Computer Operations, Audit, and Security Tools (COAST)
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.
identd (not really a security tool)
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.
(1) CERT(TM) Advisory
Send mail to: firstname.lastname@example.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.,
CERT advisories are also published on the USENET newsgroup:
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: email@example.com
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: firstname.lastname@example.org
Message Body: subscribe firewalls user@host
The Firewalls mailing list is a discussion forum for
firewall administrators and implementors.
The comp.security.announce newsgroup is moderated
and is used solely for the distribution of CERT
The comp.security.misc is a forum for the
discussion of computer security, especially as it
relates to the UNIX(r) Operating System.
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.
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.
The comp.risks newsgroup is a moderated forum on
the risks to the public in computers and related
World-Wide Web Pages
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.
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.
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.
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
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
[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,
[Bellovin, 1990] S. Bellovin, and M. Merritt, "Limitations of the
Kerberos Authentication System", Computer Communications Review,
[Bellovin, 1992] S. Bellovin, "There Be Dragon", USENIX: Proceedings
of the Third Usenix Security Symposium, Baltimore, MD. September,
[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
[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
[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,
[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
[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
[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,
[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,
[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
[Gould, 1989] C. Gould, Editor, "The Information Web: Ethical and
Social Implications of Computer Networking", Westview Press, Boulder,
[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 &
[Hess, Safford, and Pooch] D. Hess, D. Safford, and U. Pooch, "A Unix
Network Protocol Security Study: Network Information Service", Texas
[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,
[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
[Levy, 1984] S. Levy, "Hacker: Heroes of the Computer Revolution",
[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
[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
[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,
[NTISSAM, 1987] NTISS, "Advisory Memorandum on Office Automation
Security Guideline", NTISSAM COMPUSEC/1-87, 16 January 1987, 58
[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
[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,
[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
[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
[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
[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
[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
[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,
[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,
[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.
This entire document discusses security issues.
Barbara Y. Fraser
Software Engineering Institute
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213
Phone: (412) 268-5010
Fax: (412) 268-6989