o What is the estimated time to close out the incident?
o What resources could be required
to handle the incident?
5.3 Possible Types of Notification
When you have confirmed that an incident is occurring, the
appropriate personnel must be notified. Who and how this
notification is achieved is very important in keeping the event under
control both from a technical and emotional standpoint.
5.3.1 Explicit
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, or fax) provides
information about the incident that is clear, concise, and fully
qualified. When you are notifying others that will help you to
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 section 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 other information that would help
them resolve a part of the incident.
5.3.2 Factual
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. This is especially true when the press is
involved. When an incident severe enough to gain press attention
is ongoing, it is likely that any false information you provide
will not be substantiated by other sources. This will reflect
badly on the site and may create enough ill-will between the site
and the press to damage the site's public relations.
5.3.3 Choice of Language
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 expectations of damage and negative outcomes of the incident.
It is important to remain calm both in written and spoken
notifications.
Another issue associated with the choice of language is the
notification to non-technical or off-site personnel. It is
important to accurately describe the incident without undue alarm
or confusing messages. 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 notifications cannot be underestimated and may
make the difference between handling the incident properly and
escalating to some higher level of damage.
5.3.4 Notification of Individuals
o Point of Contact (POC) people (Technical, Administrative,
Response Teams, Investigative, Legal, Vendors, Service
providers), and which POCs are visible to whom.
o Wider community (users).
o Other sites that might be affected.
Finally, there is the question of who should be notified during
and after the incident. There are several classes of individuals
that need to be considered for notification. These are the
technical personnel, administration, appropriate response teams
(such as CERT or CIAC), law enforcement, vendors, and other
service providers. These issues are important for the central
point of contact, since that is the person responsible for the
actual notification of others (see section 5.3.6 for further
information). A list of people in each of these categories is an
important time saver for the POC during an incident. It is much
more difficult to find an appropriate person during an incident
when many urgent events are ongoing.
In addition to the people responsible for handling part of the
incident, there may be other sites affected by the incident (or
perhaps simply at risk from the incident). A wider community of
users may also benefit from knowledge of the incident. Often, a
report of the incident once it is closed out is appropriate for
publication to the wider user community.
5.3.5 Public Relations - Press Releases
One of the most important issues to consider is when, who, and how
much to release to the general public through the press. There
are many issues to consider when deciding this particular issue.
First and foremost, if a public relations office exists for the
site, it is important to use this office as liaison to the press.
The public relations office is trained in the type and wording of
information released, and will help to assure that the image of
the site is protected during and after the incident (if possible).
A public relations office has the advantage that you can
communicate candidly with them, and provide a buffer between the
constant press attention and the need of the POC to maintain
control over the incident.
If a public relations office is not available, the information
released to the press must be carefully considered. If the
information is sensitive, it may be advantageous to provide only
minimal or overview information to the press. It is quite
possible that any information provided to the press will be
quickly reviewed by the perpetrator of the incident. As a
contrast to this consideration, it was discussed above that
misleading the press can often backfire and cause more damage than
releasing sensitive information.
While it is difficult to determine in advance what level of detail
to provide to the press, some guidelines to keep in mind are:
o Keep the technical level of detail low. Detailed
information about the incident may provide enough
information for copy-cat events or even damage the
site's ability to prosecute once the event is over.
o Keep the speculation out of press statements.
Speculation of who is causing the incident or the
motives are very likely to be in error and may cause
an inflamed view of the incident.
o Work with law enforcement professionals to assure that
evidence is protected. If prosecution is involved,
assure that the evidence collected is not divulged to
the press.
o Try not to be forced into a press interview before you are
prepared. The popular press is famous for the "2am"
interview, where the hope is to catch the interviewee off
guard and obtain information otherwise not available.
o Do not allow the press attention to detract from the
handling of the event. Always remember that the successful
closure of an incident is of primary importance.
5.3.6 Who Needs to Get Involved?
There now exists a number of incident response teams (IRTs) such
as the CERT and the CIAC. (See sections 3.9.7.3.1 and 3.9.7.3.4.)
Teams exists for many major government agencies and large
corporations. If such a team is available for your site, the
notification of this team should be of primary importance during
the early stages of an incident. These teams are responsible for
coordinating computer security incidents over a range of sites and
larger entities. Even if the incident is believed to be contained
to a single site, it is possible that the information available
through a response team could help in closing out the incident.
In setting up a site policy for incident handling, it may be
desirable to create an incident handling team (IHT), much like
those teams that already exist, that will be responsible for
handling computer security incidents for the site (or
organization). If such a team is created, it is essential that
communication lines be opened between this team and other IHTs.
Once an incident is under way, it is difficult to open a trusted
dialogue between other IHTs if none has existed before.
5.4 Response
A major topic still untouched here is how to actually respond to an
event. The response to an event will fall into the general
categories of containment, eradication, recovery, and follow-up.
Containment
The purpose of containment is to limit the extent of an attack.
For example, it is important to limit the spread of a worm attack
on a network as quickly as possible. An essential part of
containment is decision making (i.e., determining whether to shut
a system down, to disconnect from a network, to monitor system or
network activity, to set traps, to disable functions such as
remote file transfer on a UNIX system, etc.). Sometimes this
decision is trivial; shut the system down if the system is
classified or sensitive, or if proprietary information is at risk!
In other cases, it is worthwhile to risk having some damage to the
system if keeping the system up might enable you to identify an
intruder.
The third stage, containment, 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.
Finally, notification of cognizant authorities should occur during
this stage.
Eradication
Once an incident has been detected, it is important to first think
about containing the incident. Once the incident has been
contained, it is now time to eradicate the cause. Software may be
available to help you in this effort. For example, eradication
software is available to eliminate most viruses which infect small
systems. If any bogus files have been created, it is time to
delete them at this point. In the case of virus infections, it is
important to clean and reformat any disks containing infected
files. Finally, ensure that all backups are clean. Many systems
infected with viruses become periodically reinfected simply
because people do not systematically eradicate the virus from
backups.
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 the case of a network-based
attack, it is important to install patches for any operating
system vulnerability which was exploited.
Follow-up
One of the most important stages of responding to incidents is
also the most often omitted---the follow-up stage. This stage is
important because it helps those involved in handling the incident
develop a set of "lessons learned" (see section 6.3) to improve
future performance in such situations. This stage also provides
information which justifies an organization's computer security
effort to management, and yields information which may be
essential in legal proceedings.
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? A follow-up report is valuable
because it provides a reference to be used in case of other
similar incidents. Creating a formal chronology of events
(including time stamps) is also important for legal reasons.
Similarly, it is also important to as quickly obtain a monetary
estimate of the amount of damage the incident caused in terms of
any loss of software and files, 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 by the FBI, the U.S. Attorney General's
Office, etc..
5.4.1 What Will You Do?
o Restore control.
o Relation to policy.
o Which level of service is needed?
o Monitor activity.
o Constrain or shut down system.
5.4.2 Consider Designating a "Single Point of Contact"
When an incident is under way, a major issue is deciding who is in
charge of coordinating the activity of the multitude of players.
A major mistake that can be made is to have a number of "points of
contact" (POC) that are not pulling their efforts together. This
will only add to the confusion of the event, and will probably
lead to additional confusion and wasted or ineffective effort.
The single point of contact may or may not be the person "in
charge" of the incident. There are two distinct rolls to fill
when deciding who shall be the point of contact and the person in
charge of the incident. The person in charge will make decisions
as to the interpretation of policy applied to the event. The
responsibility for the handling of the event falls onto this
person. In contrast, the point of contact must coordinate the
effort of all the parties involved with handling the event.
The point of contact must be a person with the technical expertise
to successfully coordinate the effort of the system managers and
users involved in monitoring and reacting to the attack. Often
the management structure of a site is such that the administrator
of a set of resources is not a technically competent person with
regard to handling the details of the operations of the computers,
but is ultimately responsible for the use of these resources.
Another important function of the POC is to maintain contact with
law enforcement and other external agencies (such as the CIA, DoD,
U.S. Army, or others) to assure that multi-agency involvement
occurs.
Finally, if legal action in the form of prosecution is involved,
the POC may be able to speak for the site in court. The
alternative is to have multiple witnesses that will be hard to
coordinate in a legal sense, and will weaken any case against the
attackers. A single POC may also be the single person in charge
of evidence collected, which will keep the number of people
accounting for evidence to a minimum. As a rule of thumb, the
more people that touch a potential piece of evidence, the greater
the possibility that it will be inadmissible in court. The
section below (Legal/Investigative) will provide more details for
consideration on this topic.
5.5 Legal/Investigative
5.5.1 Establishing Contacts with Investigative Agencies
It is important to establish contacts with personnel from
investigative agencies such as the FBI and Secret Service as soon
as possible, for several reasons. Local law enforcement and local
security offices or campus police organizations should also be
informed when appropriate. A primary reason is that once a major
attack is in progress, there is little time to call various
personnel in these agencies to determine exactly who the correct
point of contact is. Another reason is that it is important to
cooperate with these agencies in a manner that will foster a good
working relationship, and that will be in accordance with the
working procedures of these agencies. Knowing the working
procedures in advance and the expectations of your point of
contact is a big step in this direction. For example, it is
important to gather evidence that will be admissible in a court of
law. If you don't know in advance how to gather admissible
evidence, your efforts to collect evidence during an incident are
likely to be of no value to the investigative agency with which
you deal. A final reason for establishing contacts as soon as
possible is that it is impossible to know the particular agency
that will assume jurisdiction in any given incident. Making
contacts and finding the proper channels early will make
responding to an incident go considerably more smoothly.
If your organization or site has a legal counsel, you need to
notify this office soon after you learn that an incident is in
progress. At a minimum, your legal counsel needs to be involved
to protect the legal and financial interests of your site or
organization. There are many legal and practical issues, a few of
which are:
1. Whether your site or organization is willing to risk
negative publicity or exposure to cooperate with legal
prosecution efforts.
2. Downstream liability--if you leave a compromised system
as is so it can be monitored and another computer is damaged
because the attack originated from your system, your site or
organization may be liable for damages incurred.
3. Distribution of information--if your site or organization
distributes information about an attack in which another
site or organization may be involved or the vulnerability
in a product that may affect ability to market that
product, your site or organization may again be liable
for any damages (including damage of reputation).
4. Liabilities due to monitoring--your site or organization
may be sued if users at your site or elsewhere discover
that your site is monitoring account activity without
informing users.
Unfortunately, there are no clear precedents yet on the
liabilities or responsibilities of organizations involved in a
security incident or who might be involved in supporting an
investigative effort. Investigators will often encourage
organizations to help trace and monitor intruders -- indeed, most
investigators cannot pursue computer intrusions without extensive
support from the organizations involved. However, investigators
cannot provide protection from liability claims, and these kinds
of efforts may drag out for months and may take lots of effort.
On the other side, an organization's legal council may advise
extreme caution and suggest that tracing activities be halted and
an intruder shut out of the system. This in itself may not
provide protection from liability, and may prevent investigators
from identifying anyone.
The balance between supporting investigative activity and limiting
liability is tricky; you'll need to consider the advice of your
council and the damage the intruder is causing (if any) in making
your decision about what to do during any particular incident.
Your legal counsel should also be involved in any decision to
contact investigative agencies when an incident occurs at your
site. The decision to coordinate efforts with investigative
agencies is most properly that of your site or organization.
Involving your legal counsel will also foster the multi-level
coordination between your site and the particular investigative
agency involved which in turn results in an efficient division of
labor. Another result is that you are likely to obtain guidance
that will help you avoid future legal mistakes.
Finally, your legal counsel should evaluate your site's written
procedures for responding to incidents. It is essential to obtain
a "clean bill of health" from a legal perspective before you
actually carry out these procedures.
5.5.2 Formal and Informal Legal Procedures
One of the most important considerations in dealing with
investigative agencies is verifying that the person who calls
asking for information is a legitimate representative from the
agency in question. Unfortunately, many well intentioned people
have unknowingly leaked sensitive information about incidents,
allowed unauthorized people into their systems, etc., because a
caller has masqueraded as an FBI or Secret Service agent. A
similar consideration is using a secure means of communication.
Because many network attackers can easily reroute electronic mail,
avoid using electronic mail to communicate with other agencies (as
well as others dealing with the incident at hand). Non-secured
phone lines (e.g., the phones normally used in the business world)
are also frequent targets for tapping by network intruders, so be
careful!
There is no established set of rules for responding to an incident
when the U.S. Federal Government becomes involved. Except by
court order, no agency can force you to monitor, to disconnect
from the network, to avoid telephone contact with the suspected
attackers, etc.. As discussed in section 5.5.1, you should
consult the matter with your legal counsel, especially before
taking an action that your organization has never taken. The
particular agency involved may ask you to leave an attacked
machine on and to monitor activity on this machine, for example.
Your complying with this request will ensure continued cooperation
of the agency--usually the best route towards finding the source
of the network attacks and, ultimately, terminating these attacks.
Additionally, you may need some information or a favor from the
agency involved in the incident. You are likely to get what you
need only if you have been cooperative. Of particular importance
is avoiding unnecessary or unauthorized disclosure of information
about the incident, including any information furnished by the
agency involved. The trust between your site and the agency
hinges upon your ability to avoid compromising the case the agency
will build; keeping "tight lipped" is imperative.
Sometimes your needs and the needs of an investigative agency will
differ. Your site may want to get back to normal business by
closing an attack route, but the investigative agency may want you
to keep this route open. Similarly, your site may want to close a
compromised system down to avoid the possibility of negative
publicity, but again the investigative agency may want you to
continue monitoring. When there is such a conflict, there may be
a complex set of tradeoffs (e.g., interests of your site's
management, amount of resources you can devote to the problem,
jurisdictional boundaries, etc.). An important guiding principle
is related to what might be called "Internet citizenship" [22,
IAB89, 23] and its responsibilities. Your site can shut a system
down, and this will relieve you of the stress, resource demands,
and danger of negative exposure. The attacker, however, is likely
to simply move on to another system, temporarily leaving others
blind to the attacker's intention and actions until another path
of attack can be detected. Providing that there is no damage to
your systems and others, the most responsible course of action is
to cooperate with the participating agency by leaving your
compromised system on. This will allow monitoring (and,
ultimately, the possibility of terminating the source of the
threat to systems just like yours). On the other hand, if there
is damage to computers illegally accessed through your system, the
choice is more complicated: shutting down the intruder may prevent
further damage to systems, but might make it impossible to track
down the intruder. If there has been damage, the decision about
whether it is important to leave systems up to catch the intruder
should involve all the organizations effected. Further
complicating the issue of network responsibility is the
consideration that if you do not cooperate with the agency
involved, you will be less likely to receive help from that agency
in the future.
5.6 Documentation 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 good
portion of information you obtain, requiring you to contact the
source of information once again. This wastes yours and others'
time, something you can ill afford. At the same time, recording
details will provide evidence for prosecution efforts, providing the
case moves in this direction. Documenting an incident also will 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 a follow-up analysis in which you can engage in
a valuable "lessons learned" exercise.
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:
o All system events (audit records).
o All actions you take (time tagged).
o All phone 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 you initially
suspect that an incident will result in prosecution or when an
investigative agency becomes involved, you need to 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 who can store these copied pages in a secure place (e.g., a
safe). When you submit information for storage, you should in return
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.
6. Establishing Post-Incident Procedures
6.1 Overview
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.
All four steps should provide feedback to the site security policy
committee, leading to prompt re-evaluation and amendment of the
current policy.
6.2 Removing Vulnerabilities
Removing all vulnerabilities once an incident has occurred is
difficult. The key to removing vulnerabilities is knowledge and
understanding of the breach. In some cases, it is prudent to remove
all access or functionality as soon as possible, and then restore
normal operation in limited stages. Bear in mind that removing all
access while an incident is in progress will obviously notify all
users, including the alleged problem users, that the administrators
are aware of a problem; this may have a deleterious effect on an
investigation. However, allowing an incident to continue may also
open the likelihood of greater damage, loss, aggravation, or
liability (civil or criminal).
If it is determined that the breach occurred due to a flaw in the
systems' hardware or software, the vendor (or supplier) and the CERT
should be notified as soon as possible. Including relevant telephone
numbers (also electronic mail addresses and fax numbers) in the site
security policy is strongly recommended. To aid prompt
acknowledgment and understanding of the problem, the flaw should be
described in as much detail as possible, including details about how
to exploit the flaw.
As soon as the breach has occurred, the entire system and all its
components should be considered suspect. System software is the most
probable target. Preparation is key to recovering from a possibly
tainted system. This includes checksumming all tapes from the vendor
using a checksum algorithm which (hopefully) is resistant to
tampering [10]. (See sections 3.9.4.1, 3.9.4.2.) Assuming original
vendor distribution tapes 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 tapes to
recover from; consider that the incident may have continued for
months or years before discovery, and that 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. At worst-case, restoration from
the original manufactures' media and a re-installation of the systems
will be the most prudent solution.
Review the lessons learned from the incident and always update the
policy and procedures to reflect changes necessitated by the
incident.
6.2.1 Assessing Damage
Before cleanup can begin, the actual system damage must be
discerned. This can be quite time consuming, but should lead into
some of the insight as to the nature of the incident, and aid
investigation and prosecution. It is best to compare previous
backups or original tapes when possible; advance preparation is
the key. 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.
6.2.2 Cleanup
Once the damage has been assessed, it is necessary to develop a
plan for system cleanup. 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.
It may be necessary to go back to the original distributed tapes
and recustomize the system. To facilitate this worst case
scenario, a record of the original systems setup and each
customization change should be kept current with each change to
the system.
6.2.3 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. 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 section 3.9.8.2 (e.g., COPS) as a start. Remember,
these tools don't replace continual system monitoring and good
systems administration procedures.
6.2.4 Keep a Security Log
As discussed in section 5.6, a security log can be most valuable
during this phase of removing vulnerabilities. There are two
considerations here; the first is to keep logs of the procedures
that have been used to make the system secure again. This should
include command procedures (e.g., shell scripts) that can be run
on a periodic basis to recheck the security. Second, keep logs of
important system events. These can be referenced when trying to
determine the extent of the damage of a given incident.
6.3 Capturing Lessons Learned
6.3.1 Understand the Lesson
After an incident, it is prudent to write a report describing the
incident, method of discovery, correction procedure, monitoring
procedure, and a summary of lesson learned. This will aid in the
clear understanding of the problem. Remember, it is difficult to
learn from an incident if you don't understand the source.
6.3.2 Resources
6.3.2.1 Other Security Devices, Methods
Security is a dynamic, not static process. Sites are dependent
on the nature of security available at each site, and the array
of devices and methods that will help promote security.
Keeping up with the security area of the computer industry and
their methods will assure a security manager of taking
advantage of the latest technology.
6.3.2.2 Repository of Books, Lists, Information Sources
Keep an on site collection of books, lists, information
sources, etc., as guides and references for securing the
system. Keep this collection up to date. Remember, as systems
change, so do security methods and problems.
6.3.2.3 Form a Subgroup
Form a subgroup of system administration personnel that will be
the core security staff. This will allow discussions of
security problems and multiple views of the site's security
issues. This subgroup can also act to develop the site
security policy and make suggested changes as necessary to
ensure site security.
6.4 Upgrading Policies and Procedures
6.4.1 Establish Mechanisms for Updating Policies, Procedures,
and Tools
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.
6.4.2 Problem Reporting Procedures
A problem reporting procedure should be implemented to describe,
in detail, the incident and the solutions to the incident. Each
incident should be reviewed by the site security subgroup to allow
understanding of the incident with possible suggestions to the
site policy and procedures.
7. References
[1] Quarterman, J., "The Matrix: Computer Networks and Conferencing
Systems Worldwide", Pg. 278, Digital Press, Bedford, MA, 1990.
[2] Brand, R., "Coping with the Threat of Computer Security
Incidents: A Primer from Prevention through Recovery", R. Brand,
available on-line from: cert.sei.cmu.edu:/pub/info/primer, 8 June
1990.
[3] Fites, M., Kratz, P. and A. Brebner, "Control and Security of
Computer Information Systems", Computer Science Press, 1989.
[4] Johnson, D., and J. Podesta, "Formulating a Company Policy on
Access to and Use and Disclosure of Electronic Mail on Company
Computer Systems", Available from: The Electronic Mail
Association (EMA) 1555 Wilson Blvd, Suite 555, Arlington VA
22209, (703) 522-7111, 22 October 1990.
[5] Curry, D., "Improving the Security of Your UNIX System", SRI
International Report ITSTD-721-FR-90-21, April 1990.
[6] Cheswick, B., "The Design of a Secure Internet Gateway",
Proceedings of the Summer Usenix Conference, Anaheim, CA, June
1990.
[7] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
I -- Message Encipherment and Authentication Procedures", RFC
1113, IAB Privacy Task Force, August 1989.
[8] Kent, S., and J. Linn, "Privacy Enhancement for Internet
Electronic Mail: Part II -- Certificate-Based Key Management",
RFC1114, IAB Privacy Task Force, August 1989.
[9] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
III -- Algorithms, Modes, and Identifiers", RFC1115, IAB Privacy
Task Force, August 1989.
[10] Merkle, R., "A Fast Software One Way Hash Function", Journal of
Cryptology, Vol. 3, No. 1.
[11] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
Specification", RFC791, DARPA, September 1981.
[12] Postel, J., "Transmission Control Protocol - DARPA Internet
Program Protocol Specification", RFC793, DARPA, September 1981.
[13] Postel, J., "User Datagram Protocol", RFC768, USC/Information
Sciences Institute, 28 August 1980.
[14] Mogul, J., "Simple and Flexible Datagram Access Controls for
UNIX-based Gateways", Digital Western Research Laboratory
Research Report 89/4, March 1989.
[15] Bellovin, S., and M. Merritt, "Limitations of the Kerberos
Authentication System", Computer Communications Review, October
1990.
[16] Pfleeger, C., "Security in Computing", Prentice-Hall, Englewood
Cliffs, N.J., 1989.
[17] Parker, D., Swope, S., and B. Baker, "Ethical Conflicts:
Information and Computer Science, Technology and Business", QED
Information Sciences, Inc., Wellesley, MA.
[18] Forester, T., and P. Morrison, "Computer Ethics: Tales and
Ethical Dilemmas in Computing", MIT Press, Cambridge, MA, 1990.
[19] Postel, J., and J. Reynolds, "Telnet Protocol Specification", RFC
854, USC/Information Sciences Institute, May 1983.
[20] Postel, J., and J. Reynolds, "File Transfer Protocol", RFC959,
USC/Information Sciences Institute, October 1985.
[21] Postel, J., Editor, "IAB Official Protocol Standards", RFC1200,
IAB, April 1991.
[22] Internet Activities Board, "Ethics and the Internet", RFC1087,
Internet Activities Board, January 1989.
[23] Pethia, R., Crocker, S., and B. Fraser, "Policy Guidelines for
the Secure Operation of the Internet", CERT, TIS, CERT, RFCin
preparation.
[24] Computer Emergency Response Team (CERT/CC), "Unauthorized
Password Change Requests", CERT Advisory CA-91:03, April 1991.
[25] Computer Emergency Response Team (CERT/CC), "TELNET Breakin
Warning", CERT Advisory CA-89:03, August 1989.
[26] CCITT, Recommendation X.509, "The Directory: Authentication
Framework", Annex C.
[27] Farmer, D., and E. Spafford, "The COPS Security Checker System",
Proceedings of the Summer 1990 USENIX Conference, Anaheim, CA,
Pgs. 165-170, June 1990.
8. Annotated Bibliography
The intent of this annotated bibliography is to offer a
representative collection of resources of information that will help
the user of this handbook. It is meant provide a starting point for
further research in the security area. Included are references to
other sources of information for those who wish to pursue issues of
the computer security environment.
8.1 Computer Law
[ABA89]
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.
[BENDER]
Bender, D., "Computer Law: Evidence and Procedure",
M. Bender, New York, NY, 1978-present.
Kept up to date with supplements.
Years covering 1978-1984 focuses on: Computer law,
evidence and procedures. The years 1984 to the current
focus on general computer law. Bibliographical
references and index included.
[BLOOMBECKER]
Bloombecker, B., "Spectacular Computer Crimes", Dow Jones-
Irwin, Homewood, IL. 1990.
[CCH]
Commerce Clearing House, "Guide to Computer Law", (Topical
Law Reports), Chicago, IL., 1989.
Court cases and decisions rendered by federal and state
courts throughout the United States on federal and state
computer law. Includes Case Table and Topical Index.
[CONLY]
Conly, C., "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.
[FENWICK]
Fenwick, W., 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.
[GEMIGNANI]
Gemignani, M., "Viruses and Criminal Law", Communications
of the ACM, Vol. 32, No. 6, Pgs. 669-671, June 1989.
[HUBAND]
Huband, F., 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.
[MCEWEN]
McEwen, J., "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.
[PARKER]
Parker, D., "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.
[SHAW]
Shaw, E., Jr., "Computer Fraud and Abuse Act of 1986,
Congressional Record (3 June 1986), Washington, D.C.,
3 June 1986.
[TRIBLE]
Trible, P., "The Computer Fraud and Abuse Act of 1986",
U.S. Senate Committee on the Judiciary, 1986.
8.2 Computer Security
[CAELLI]
Caelli, W., Editor, "Computer Security in the Age of
Information", Proceedings of the Fifth IFIP International
Conference on Computer Security, IFIP/Sec '88.
[CARROLL]
Carroll, J., "Computer Security", 2nd Edition, Butterworth
Publishers, Stoneham, MA, 1987.
[COOPER]
Cooper, J., "Computer and Communications Security:
Strategies for the 1990s", McGraw-Hill, 1989.
[BRAND]
Brand, R., "Coping with the Threat of Computer Security
Incidents: A Primer from Prevention through Recovery",
R. Brand, 8 June 1990.
As computer security becomes a more important issue in
modern society, it begins to warrant a systematic approach.
The vast majority of the computer security problems and the
costs associated with them can be prevented with simple
inexpensive measures. The most important and cost
effective of these measures are available in the prevention
and planning phases. These methods are presented in this
paper, followed by a simplified guide to incident
handling and recovery. Available on-line from:
cert.sei.cmu.edu:/pub/info/primer.
[CHESWICK]
Cheswick, B., "The Design of a Secure Internet Gateway",
Proceedings of the Summer Usenix Conference, Anaheim, CA,
June 1990.
Brief abstract (slight paraphrase from the original
abstract): AT&T maintains a large internal Internet that
needs to be protected from outside attacks, while
providing useful services between the two.
This paper describes AT&T's Internet gateway. This
gateway passes mail and many of the common Internet
services between AT&T internal machines and the Internet.
This is accomplished without IP connectivity using a pair
of machines: a trusted internal machine and an untrusted
external gateway. These are connected by a private link.
The internal machine provides a few carefully-guarded
services to the external gateway. This configuration
helps protect the internal internet even if the external
machine is fully compromised.
This is a very useful and interesting design. Most
firewall gateway systems rely on a system that, if
compromised, could allow access to the machines behind
the firewall. Also, most firewall systems require users
who want access to Internet services to have accounts on
the firewall machine. AT&T's design allows AT&T internal
internet users access to the standard services of TELNET and
FTP from their own workstations without accounts on
the firewall machine. A very useful paper that shows
how to maintain some of the benefits of Internet
connectivity while still maintaining strong
security.
[CURRY]
Curry, D., "Improving the Security of Your UNIX System",
SRI International Report ITSTD-721-FR-90-21, April 1990.
This paper describes measures that you, as a system
administrator can take to make your UNIX system(s) more
secure. Oriented primarily at SunOS 4.x, most of the
information covered applies equally well to any Berkeley
UNIX system with or without NFS and/or Yellow Pages (NIS).
Some of the information can also be applied to System V,
although this is not a primary focus of the paper. A very
useful reference, this is also available on the Internet in
various locations, including the directory
cert.sei.cmu.edu:/pub/info.
[FITES]
Fites, M., Kratz, P. and A. Brebner, "Control and
Security of Computer Information Systems", Computer Science
Press, 1989.
This book serves as a good guide to the issues encountered
in forming computer security policies and procedures. The
book is designed as a textbook for an introductory course
in information systems security.
The book is divided into five sections: Risk Management (I),
Safeguards: security and control measures, organizational
and administrative (II), Safeguards: Security and Control
Measures, Technical (III), Legal Environment and
Professionalism (IV), and CICA Computer Control Guidelines
(V).
The book is particularly notable for its straight-forward
approach to security, emphasizing that common sense is the
first consideration in designing a security program. The
authors note that there is a tendency to look to more
technical solutions to security problems while overlooking
organizational controls which are often cheaper and much
more effective. 298 pages, including references and index.
[GARFINKEL]
Garfinkel, S, and E. Spafford, "Practical Unix Security",
O'Reilly & Associates, ISBN 0-937175-72-2, May 1991.
Approx 450 pages, $29.95. Orders: 1-800-338-6887
(US & Canada), 1-707-829-0515 (Europe), email: nuts@ora.com
This is one of the most useful books available on Unix
security. The first part of the book covers standard Unix
and Unix security basics, with particular emphasis on
passwords. The second section covers enforcing security on
the system. Of particular interest to the Internet user are
the sections on network security, which address many
of the common security problems that afflict Internet Unix
users. Four chapters deal with handling security incidents,
and the book concludes with discussions of encryption,
physical security, and useful checklists and lists of
resources. The book lives up to its name; it is filled with
specific references to possible security holes, files to
check, and things to do to improve security. This
book is an excellent complement to this handbook.
[GREENIA90]
Greenia, M., "Computer Security Information Sourcebook",
Lexikon Services, Sacramento, CA, 1989.
A manager's guide to computer security. Contains a
sourcebook of key reference materials including
access control and computer crimes bibliographies.
[HOFFMAN]
Hoffman, L., "Rogue Programs: Viruses, Worms, and
Trojan Horses", Van Nostrand Reinhold, NY, 1990.
(384 pages, includes bibliographical references and index.)
[JOHNSON]
Johnson, D., and J. Podesta, "Formulating A Company Policy
on Access to and Use and Disclosure of Electronic Mail on
Company Computer Systems".
A white paper prepared for the EMA, written by two experts
in privacy law. Gives background on the issues, and presents
some policy options.
Available from: The Electronic Mail Association (EMA)
1555 Wilson Blvd, Suite 555, Arlington, VA, 22209.
(703) 522-7111.
[KENT]
Kent, Stephen, "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.
[LU]
Lu, W., and M. Sundareshan, "Secure Communication in
Internet Environments: A Hierachical Key Management Scheme
for End-to-End Encryption", IEEE Transactions on
Communications, Vol. 37, No. 10, Pg. 1014, 1 October 1989.
[LU1]
Lu, W., 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.
[NSA]
National Security Agency, "Information Systems Security
Products and Services Catalog", NSA, Quarterly Publication.
NSA's catalogue contains chapter on: Endorsed Cryptographic
Products List; NSA Endorsed Data Encryption Standard (DES)
Products List; Protected Services List; Evaluated Products
List; Preferred Products List; and Endorsed Tools List.
The catalogue is available from the Superintendent of