DEPARTMENT OF THE NAVY NAVSO P-5239-19

AUGUST 1996















COMPUTER INCIDENT RESPONSE

GUIDEBOOK



MODULE 19

INFORMATION SYSTEMS SECURITY

(INFOSEC)

PROGRAM GUIDELINES




Distribution: Submit requests for placement on distribution (including supporting justification), or amendment to the existing distribution, to:

Commanding Officer

Naval Command, Control and Ocean Surveillance Center

In-Service Engineering East Coast Division

Code 423

P.O. Box 190022

North Charleston, SC 29419-9022

Commercial 1-800-304-4636

E-Mail: subscribe@infosec.nosc.mil

Electronic versions of this document may be downloaded via anonymous

ftp from infosec.nosc.mil or /http://infosec.nosc.mil/info.html











Stocked: Additional copies of NAVSO P-5239-19 can be obtained from the Navy Aviation Supply Office (Code 1013), 5801 Tabor Avenue, Philadelphia PA 19120-5099, through normal supply channels in accordance with NAVSUP P600 (CD-ROM only), using AUTODIN, DAMES, or MILSTRIP message format to DAAS, Dayton, OH.

Cite stock number 0515-LP-208-8305.

Local reproduction is authorized.

DEPARTMENT OF THE NAVY




NAVSO P-5239-19

AUGUST 1996

FOREWORD

Naval INFOSEC Publication (NAVSO Pub) 5239, "Information Systems Security (INFOSEC) Program Guidelines" is issued by the Naval Command, Control and Ocean Surveillance Center In-Service Engineering East Coast Division. It consists of a series of modules providing procedural, technical, administrative and/or supplemental guidance for all information systems, whether business or tactical, used in the automatic acquisition, storage, manipulation, management, movement, control, display, switching, interchange, transmission or receipt of data. Each module will focus on a distinct program element and describes a standard methodology for planning, implementing and executing that element of the INFOSEC program within the Department of the Navy (DON).

This module, "Computer Incident Response Guidebook", provides the Information Systems Security Managers (ISSMs) and Information Systems Security Officers (ISSOs) with guidance and procedures to be used when responding to computer security incidents.






















THIS PAGE INTENTIONALLY BLANK

TABLE OF CONTENTS

1. Background..............................................1

2. Purpose.................................................2

3. Scope...................................................3

4. Definitions.............................................3

a. Definition of Incident..............................3

b. Types of Incidents..................................4

5. Organizational Roles....................................5

a. Users...............................................5

b. Information Systems Security Officer (ISSO).........5

c. Information Systems Security Manager (ISSM).........5

d. Fleet Information Warfare Center (FIWC).............6

e. Naval Computer Incident Response Team (NAVCIRT).....6

f. Naval Criminal Investigative Service (NCIS).........6

g. Public Affairs Office (PAO).........................6

6. Procedures for Responding to Incidents..................6

a. Rationale for Structured Procedures.................7

b. Stages of Responding to Incidents...................7

c. Types of Attacks...................................14

d. User-Detected Technical Vulnerabilities............18

e. Reporting Procedures...............................19

f. Legal Procedures...................................22

7. Conclusion.............................................22


APPENDIX A GLOSSARY....................................A-1

APPENDIX B NAVCIRT SERVICES............................B-1

APPENDIX C VULNERABILITY REPORT .......................C-1

APPENDIX D VIRUS REPORT................................D-1

APPENDIX E HACKER REPORT ..............................E-1


COMPUTER INCIDENT RESPONSE

GUIDEBOOK


Ref: (a) OPNAV Instruction 3430.26, Implementation Instruction for Information

Warfare/Command and Control Warfare (IW/C2W) dated 18 Jan 95

(b) NSTISSP No.5, National Policy for Incident Response and Vulnerability Reporting for National Security Systems dated 30 Aug 93

1. Background

The United States Government is faced with a new and gigantic challenge---that of Information Warfare. U.S. military computers in particular contain information of great value to adversaries of the U.S. and to "information brokers" who sell information they obtain to other governments and organizations. These same computers often support critical computing activities such as command and control, target tracking, logistics, and control of weapons systems (including systems on Naval vessels and aircraft). Many sensitive unclassified DoN systems connect to the MILNET, (a backbone that ties military networks together all over the world) or the Internet (a backbone that ties all types of networks together throughout the world). The likelihood of attempted, unauthorized access to these systems via the MILNET and other access avenues (e.g., modems) is high. Information warfare requires not only adopting reasonable precautions in securing these systems and networks but also responding quickly and efficiently if system and network security defenses are breached.

Unfortunately, responding to computer security incidents is generally not a simple matter. This activity requires technical knowledge, communication and coordination among personnel who respond to the incident. The incidents themselves are becoming increasingly more complex. For example, during Operation Desert Storm and Desert Shield, dozens of U.S. military systems were illegally accessed by perpetrators who were thousands of miles away (see references in the suggested readings at the end of this document). Sophisticated break-in techniques were employed to obtain data about U.S. troop movements, ordinance systems, and logistics.

At the same time, malicious code such as computer viruses continue to infect military computers in epidemic proportions. Security vulnerabilities that can expose systems and networks to unauthorized access and compromise of integrity are being continually discovered. The toll is often great; weeks and even months may be required to re-establish the integrity of a critical military system which has been compromised by a perpetrator of computer crime or malicious code.

Critical data may fall into the hands of our adversaries. Information system security (INFOSEC) is essential to U.S. military interests; and incident response is a major part of INFOSEC. The importance of incident response at the DoD and national level is realized in references (a) and (b).

2. Purpose.

The purpose of this incident response guidebook includes:

a. Helping DoN personnel quickly and efficiently recover from security incidents. These guidelines reflect "lessons learned" from experience in responding to virtually hundreds of incidents. Following the procedures in these guidelines will acquaint you with proven response measures.

b. Minimizing loss or theft of information (classified or unclassified) or disruption of critical computing services when incidents occur.

c. The need to respond systematically. Following the procedures in this document will increase the likelihood that personnel will carry out all necessary steps to correctly handle an incident.

d. Protecting systems. As desirable as it is to place extremely high levels of defenses (e.g., special access controls) on all DoN computing resources, doing so is impossible due to cost and other practical constraints. Being able to detect and recover from incidents quickly can in many respects, be considered a protection strategy to supplement system and network protection measures.

e. Protecting personnel. The safety of many DoN personnel depends on computing systems. Following sound incident response procedures minimizes the likelihood that these systems will function improperly or will become inoperable after a security incident occurs.

f. Using resources efficiently. Having both technical and managerial personnel respond to an incident requires a substantial amount of resources. These resources could be devoted to another mission if an incident were to be short lived. Ending the incident as quickly as possible is, therefore, a high priority so that resources can once again be expended on "normal" operations.

g. Dealing properly with legal issues. A plethora of legal issues surrounds the computer security arena. For example, the U.S. Department of Justice has declared certain kinds of monitoring techniques illegal. These procedures have been analyzed from a legal viewpoint and can be followed with the assurance that legal statutes are not being violated.


3. Scope.

This document applies to all DoN activities processing GENSER classified or sensitive but unclassified information. Activities operating information systems outside the DoN purview, such as the Naval Security Group will follow the incident reporting requirements established by their Commanding Officer.

The guidelines contained herein contain fundamental information about responding to incidents that is intended to be used independently of particular hardware platforms or operating systems. As such, this guidebook contains neither technically detailed information nor an exhaustive set of incident response procedures (although technical information sources are described in Appendix A to this document). This document is instead intended to provide a quick, practical source of guidance on incident response.

4. Definitions.

Although Appendix A of this guidebook provides a glossary of terms, several terms and concepts are particularly critical. These terms are discussed in this section.

a. Definition of Incident

The term "incident" refers to an adverse event in a information system and/or network or the threat of the occurrence of such an event. Examples of incidents include unauthorized use of another user's account, unauthorized use of system privileges, and execution of malicious code that destroys data. Other adverse events include floods, fires, electrical outages, and excessive heat that causes system crashes. Adverse events such as natural disasters and power-related disruptions are not, however, within the scope of this guidebook. For the purpose of this guidebook, therefore, the term "incident" refers to an adverse event that is related to INFOSEC.

An "event" is any observable occurrence in a system and/or network. Examples of events include the system boot sequence, a system crash, and packet flooding within a network. Events sometimes provide indication that an incident is occurring. In reality, events caused by human error (e.g., unintentionally deleting a critical directory and all files contained therein) are the most costly and disruptive. Computer security-related events, however, are attracting an increasing amount of attention within the DoN and the computing community in general because (among other reasons) the unparalleled growth of networking has so greatly exposed systems to the threat of unauthorized remote access and because of the abundance of malicious code available to perpetrators.

b. Types of Incidents

The term "incident" encompasses the following general categories of adverse events:

(1) Malicious code attacks. Malicious code attacks include attacks by programs such as viruses, Trojan horse programs, worms, and scripts used by crackers/hackers to gain privileges, capture passwords, and/or modify audit logs to exclude unauthorized activity. Malicious code is particularly troublesome in that it is typically written to masquerade its presence and, thus, is often difficult to detect. Self-replicating malicious code such as viruses and worms can furthermore replicate rapidly, thereby making containment an especially difficult problem.

(2) Unauthorized access. Unauthorized access encompasses a range of incidents from improperly logging into a user's account (e.g., when a hacker logs in to a legitimate user's account) to unauthorized access to files and directories stored on a system or storage media by obtaining superuser privileges. Unauthorized access could also entail access to network data by planting an unauthorized "sniffer" program or device to capture all packets traversing the network at a particular point.

(3) Unauthorized utilization of services. It is not absolutely necessary to access another user's account to perpetrate an attack on a system or network. An intruder can access information, plant Trojan horse programs, and so forth by misusing available services. Examples include using the network file system (NFS) to mount the file system of a remote server machine, the VMS file access listener to transfer files without authorization, or inter-domain access mechanisms in Windows NT to access files and directories in another organization's domain.

(4) Disruption of service. Users rely on services provided by network and computing services. Perpetrators and malicious code can disrupt these services in many ways, including erasing a critical program, "mail spamming" (flooding a user account with electronic mail), and altering system functionality by installing a Trojan horse program.

(5) Misuse. Misuse occurs when someone uses a computing system for other than official purposes such as when a legitimate user uses a government computer to store personal tax records.

(6) Espionage. Espionage is stealing information to subvert the interests of a corporation or government. Many of the cases of unauthorized access to U.S. military systems during Operation Desert Storm and Operation Desert Shield were the manifestation of espionage activity against the U.S. Government.

(7) Hoaxes. Hoaxes occur when false information about incidents or vulnerabilities is spread. In early 1995, for example, several users with Internet access distributed information about a virus called the Good Times Virus, even though the virus did not exist.

Note that these categories of incidents are not necessarily mutually exclusive. A saboteur from a remote country could for example obtain unauthorized access to a DoN system for the purpose of espionage.

5. Organizational Roles.

The purpose of this section is to describe the roles and responsibilities of different organizations and individuals within the DoN INFOSEC organizational hierarchy. Each individual, from data entry personnel using a PC to the CNO or CMC, have responsibilities related to the security of DoN computing systems. It is important, therefore, that all personnel understand their roles and responsibilities in relationship to this organization.

a. Users

Computer users are nearly always most effective in discovering intrusions that occur. Despite advances in automated intrusion detection systems, most computer incidents are detected by the end users, not by centralized technical measures. Users need to be vigilant for unusual system behavior which may indicate a security incident in progress. These indications are described further in Section 6.b.(2). Users are also responsible for reporting incidents according to the procedures contained in Section 6.e.

In addition to their incident reporting responsibilities, users may at some point be responsible for handling minor incidents. A virus infection that is detected by resident software is one such type of incident.

b. Information Systems Security Officer (ISSO)

The ISSO is the individual responsible for operational security within a subset of machines assigned to a particular site or facility. Each organization has at least one ISSO. The ISSO is the first level of interaction for users experiencing security incidents. It is the ISSO's responsibility to co-ordinate incoming information, advise users on handling low-level security incidents, pass information up through the ISSM, and disseminate information downwards as appropriate.

c. Information Systems Security Manager (ISSM)

The ISSM is responsible for coordinating computer security efforts within an organization. The ISSM will pass incoming incident information from the ISSOs to the Fleet Information Warfare Center (FIWC) in a timely fashion. It is also the ISSM's responsibility to advise the Commanding Officer in the event of a serious security incident, and co-ordinate the response with security personnel.

d. Fleet Information Warfare Center (FIWC)

FIWC is an operational command tasked to be the Fleet CINC's principal agent for development of IW/C2W tactics, procedures and training, under the operational control of Commander in Chief, U.S. Atlantic Fleet (CINCLANTFLT), additional duty to CINCPACFLT, CINCUSNAVEUR and CONUSNAVCENT. FIWC is responsible to provide the following protect services to fleet and shore establishments: Computer Incident Response, Vulnerability Analysis and Assistance, and Incident Measurement.

e. Naval Computer Incident Response Team (NAVCIRT)

NAVCIRT is a response team designed to assist ISSOs and ISSMs in handling security incidents. NAVCIRT's responsibilities furthermore include guiding the ISSOs and ISSMs in operating secure systems and networks and disseminating incident information.

NAVCIRT has no law enforcement capability or authority. Criminal investigation and prosecution is the Naval Criminal Investigative Service's (NCIS's) responsibility . It is, however, NAVCIRT's responsibility to advise the ISSO/ISSM community concerning preservation of evidence and downstream liability.

It is also NAVCIRT's mission to disseminate security tools to the user community.

f. Naval Criminal Investigative Service (NCIS)

The NCIS is responsible for investigating criminal activity involving DoN personnel or facilities. This includes computer trespass, theft, and espionage. The NCIS is primarily concerned with apprehending and prosecuting criminals. If criminal activity is suspected, NCIS should be notified immediately. This service may not, on the other hand, be able to assist in the response or provide more than a cursory investigation if the evidence has not been preserved or if the case does not prove worth the investment in prosecution (e.g., because the incident is extremely minor).

g. Public Affairs Office (PAO)

The PAO is responsible for answering questions from the public regarding military activities. When a security-related incident occurs, it is also PAO's responsibility to disseminate appropriate information to the public. Navy personnel may not disseminate incident-related information to the public (including the press), but should instead work through their chain of command to provide any needed information to the PAO.

6. Procedures for Responding to Incidents

Recommended procedures for responding to incidents are covered in this section.

a. Rationale for Structured Procedures

Following pre-defined, structured procedures is a critical component of responding to incidents. Reasons include:

(1) Organization. Someone who is responding to an incident will be more effective if that person's responses are organized. It is easy to forget a critical step or to repeat a step unnecessarily unless one follows organized procedures.

(2) Comprehension. Structured procedures can be read and understood more accurately and rapidly than can non-structured procedures.

(3) Retention. Structured procedures can be learned more easily than can non-structured procedures.

(4) Evolution. Structured procedures are more conducive to improvement and incorporation of "lessons learned."

b. Stages of Responding to Incidents

There are at least six identifiable stages of response to an INFOSEC incident. They include preparation, identification, containment, eradication, recovery and follow-up. Knowing about each stage facilitates responding more methodically (and thus efficiently), and also helps users understand the process of responding better so that they can deal with unexpected aspects of incidents they face. The six identifiable stages are detailed below. Refer to Figure 1 which outlines the procedures for responding to computer incidents.

(1) Preparation. One of the most critical facets of responding to incidents is being prepared to respond before an incident occurs. Without adequate preparation, it is extremely likely that response efforts to an incident will be disorganized and that there will be considerable confusion among personnel. Preparation accordingly limits the potential for damage by ensuring response actions are known and coordinated. Actions to be taken include:

(a) Install a baseline of protection on all systems and networks. All computing components should have at least a minimum level of defense; if not, incidents can spread very quickly from system-to-system. Every local area network (LAN) server should for example have access controls set so that nobody but the LAN administrator(s) can write to system executables. Contact FIWC for recommendations concerning a suitable baseline of protection for systems.

(b) Create written incident response procedures and make them widely available. Written procedures work best during incidents. They should be widely distributed because there are many unexpected events during incidents, including absences of key personnel.

Widely distributing the procedures helps ensure that a critical complement of personnel with necessary knowledges will be available if and when an incident occurs.

(c) Plan communications needs. The tendency for the unexpected to occur during incidents often adversely affects ability to communicate with others. Contact lists with duty and home phone numbers in addition to primary and secondary FAX numbers of personnel to be contacted during incidents should be prepared and widely distributed. Issuing pagers to key personnel is also a wise step in preparing for incidents. Having a sufficient number of telephones approved for classified use (e.g., STU-III's) is critical in case classified incidents occur.

(d) Establish firecall procedures. Firecall procedures are procedures to provide operational continuity when there is a significant risk of prolonged failure or disruption. Assigned system administrators may not be available during a critical incident involving one or more of the systems. Ensure, therefore, that the passwords used to obtain superuser access to every system and LAN within your organization are recorded on a sheet of paper, sealed in a signed envelope, and placed in a locked container in case superuser access is needed by someone other than the assigned system administrator. Storing encryption keys for critical information in this manner is also advisable. Firecall procedures must include provisions for verifying the identity of the person who needs a password or encryption key during an emergency.

(e) Establish and employ standard backup and recovery procedures. Regularly backing up systems and data helps ensure operational continuity. This practice also enables personnel to check the integrity of systems and data---to verify whether unauthorized changes have occurred by comparing files to their corresponding backups. Because recovery is often a complex process, establishing and following recovery procedures is also a critical part of the preparation process. Standardizing these procedures makes it easier for anyone to perform them; during an emergency someone not assigned to a particular system or network may be called on to perform recovery procedures.

(f) Provide training to personnel. A workshop on responding to incidents can be one of the most valuable ways to help personnel at an organization learn how to handle incidents. Personnel should also be required to participate in periodic mock incidents in which written incident response procedures are followed for simulated incidents (e.g., as if a network intruder has broken into a DoN network).

(g) Obtain potentially useful tools in advance. As will shortly be explained in more detail, technical tools are often essential in successfully responding to an incident. Examples include virus detection and eradication tools, tools to restore mainframes and workstations, and incident detection tools. Order tools that you project to be critical to incident handling efforts now because the procurement process can be time-consuming.

(h) Inform users whom they should contact. Have stickers made that display the telephone number of your organization's INFOSEC group that can assist in case of a malicious

code incident. Ensure that a sticker is displayed visibly on every computer. Users report incidents more often and with less delay when they know whom to call.

(2) Identification. Identification involves determining whether or not an incident has occurred, and if one has, what the nature of the incident is. Identification normally begins after someone has noticed an anomaly in a system or network. Determining whether or not that anomaly is symptomatic of an incident is often difficult because apparent evidences of security incidents often turn out to indicate something less---errors in system configuration or an application program, hardware failures, and, most commonly, user errors. Typical indications of security incidents include any or all of the following:

(a) A system alarm or similar indication from an intrusion detection tool

(b) Suspicious entries in system or network accounting (e.g., a UNIX user obtains root access without going through the normal sequence necessary to obtain this access)

(c) Accounting discrepancies (e.g., someone notices an 18-minute gap in the accounting log in which no entries whatsoever appear)

(d) Unsuccessful logon attempts

(e) Unexplained, new user accounts

(f) Unexplained, new files or unfamiliar file names

(g) Unexplained modifications to file lengths or/or dates, especially in system executable files

(h) Unexplained attempts to write to system files or changes in system files

(i) Unexplained modification or deletion of data

(j) Denial of service or inability of one or more users to login to an account

(k) System crashes

(l) Poor system performance

(m) Unauthorized operation of a program or sniffer device to capture network traffic

(n) "Door knob rattling" (e.g., use of attack scanners, remote requests for information about systems and/or users, or social engineering attempts)

(o) Unusual time of usage (remember, more security incidents occur during non-working hours than any other time)

(p) An indicated last time of usage of a user account that does not correspond to the actual last time of usage for that user

(q) Unusual usage patterns (e.g., programs are being compiled in the account of a user who does not know how to program)

Although no single one of these typical symptoms of security incidents is generally by itself conclusive, observing one or more of these symptoms should prompt you to investigate events more closely. You should in this vein work with other personnel at your organization who possess the appropriate technical and computer security knowledges to determine exactly what has occurred. Collective judgment is typically better than a single person's judgment when it comes to identifying incidents.

It is extremely important to obtain a full backup of the system in which suspicious events have been observed as soon as the possibility that a security-related incident has occurred is indicated. Perpetrators of computer crime are becoming increasingly proficient in quickly destroying evidence of their illegal activity. Unless this evidence is immediately captured by making a full backup, this evidence may be destroyed before you and others have a chance to look at it. The backup will, in addition provide a basis for comparison later in case you need to determine if any additional unauthorized activity has occurred. Be sure to safely store any backup tapes so that they will not be lost and/or stolen.

Ensure a log book is used to record the nature of suspicious events observed immediately after they've been observed. Include the name of the system, time and other details related to the observations (even though they may not seem to be very relevant at the time their recorded). Also record the names of those with whom the incident or possible incident was discussed. Careful recording of these details can assist efforts to identify the nature of an incident, develop effective solutions, and prosecute those who commit computer crime. Be sure additionally to safely store the log book.

Software packages can be helpful in identifying incidents. Virus detection packages are useful in detecting viruses. Intrusion detection tools can indicate whether someone has broken into a account on a system or has misused the system. System and network audit logs also generally provide sufficient information to facilitate deciding whether or not unauthorized activity has occurred.

As soon as someone identifies an incident, notification of cognizant authorities should occur. Section 6.e. describes detailed notification procedures.

(3) Containment. Containment, the third stage of responding to incidents, involves limiting the scope and magnitude of an incident. Because so many incidents observed currently involve using malicious code, incidents can spread rapidly, causing massive destruction and compromise of information. It is for example not uncommon to find that every workstation connected to a LAN is infected when there is a virus outbreak. The internet Worm of 1988 successfully attacked over 6,000 computers in the U.S. in only one day. As soon as it is recognized that an incident has occurred or is occurring, immediately begin working on containing the incident.

The first critical decision to be made during the containment stage is what to do with critical information and/or computing services. Work within your chain of command to

determine whether sensitive information (and in the case of classified systems, classified information) should be left on information systems or whether it should be copied to media and taken off-line. It may similarly be best to move critical computing services to another system on another network where there is considerably less chance of interruption.

The next decision concerns the operational status of the compromised system itself. Should this system be shut down entirely, disconnected from the network, or be allowed to continue to run in its normal operational status so that any activity on the system can be monitored? The answer depends on the type and magnitude of the incident. In the case of a simple virus incident, it is almost certainly best to quickly eradicate any viruses without shutting the infected system down. If the system is classified or sensitive, information or critical programs may be at risk, and it is generally best to shut the system down (or at least temporarily disconnect it from the network). If there is a reasonable chance that a perpetrator can be identified by letting a system continue to run as normal, risking some damage, disruption, or compromise of data may be advisable. Again, work within your chain of command to reach a decision. Continue to follow proper reporting procedures (see Section 6.e ahead) during this phase of activity by keeping others informed of the status of your efforts.

(4) Eradication. Eradicating an incident entails removing the cause of the incident. In the case of a virus incident, eradication simply requires removing the virus from all systems and media (e.g., floppy disks), usually by using virus eradication software. In the case of a network intrusion, eradication is more ambiguous. Network intrusions are best eradicated by bringing the perpetrators into legal custody and convicting them in a court of law. From a statistical viewpoint, however, the likelihood of obtaining a conviction is very small. The network intruder(s) may instead simply terminate efforts to gain unauthorized access or may temporarily terminate an attack, then attack the same system again several months later.

(5) Recovery. Recovery means restoring a system to its normal mission status. In the case of relatively simple incidents (such as attempted but unsuccessful intrusions into systems), recovery requires only assurance that the incident did not in any way affect system software or data stored on the system. In the case of complex incidents, such as malicious code planted by insiders, recovery may require a complete restore operation from backups. In this case it is essential to first determine the integrity of the backup itself. Once the restore has been performed, it is also essential to verify that the restore operation was successful and that the system is back to its normal condition.

(6) Follow-up. Some incidents require considerable time and effort. It is little wonder, then, that once the incident appears to be terminated there is little interest in devoting any more effort to the incident. Performing follow-up activity is, however, one of the most critical activities in responding to incidents. Following up afterwards helps organizations improve their incident handling procedures as well as continue to support any efforts to prosecute those who have broken the law. Follow-up activity includes the following:

(a) Analyzing what has transpired and what was done to intervene. Was there sufficient preparation for the incident? Did detection occur promptly or, if not, why not? Could additional tools have helped the detection and eradication process? Was the incident sufficiently contained? Was communication adequate, or could it have been better? What practical difficulties were encountered?

(b) Analyzing the cost of the incident. Work within your chain of command to determine personnel time required to deal with the incident (including time necessary to restore systems). How much is the associated monetary cost? How much did the incident disrupt ongoing operations? Were any data irrecoverably lost, and, if so, what was the value of the data? Was any hardware damaged? Deriving a financial cost associated with an incident will not only help those who may be prosecuting any suspected perpetrators, but will also help your organization justify its requested budget for the upcoming fiscal year and possibly even in obtaining mid-year funding for security efforts.

(c) Preparing a report. Depending on the type of incident, a report (i.e. vulnerability, virus or hacker report as outlined in Appendices C through E) should be completed. Answers to questions in (a) and (b) above and "lessons learned" should be included in this report. This report should be disseminated widely enough that others will learn about the incident response process even if they were not involved in responding to the particular incident in question.

(d) Revising policies and procedures. Developing effective policies and procedures is an iterative process in which feedback from follow-up activity is essential. "Lessons learned" contained in the report described in (c) above should be used as the basis for modifying your activity's incident response policies and procedures.

PROCEDURES FOR RESPONDING

TO COMPUTER INCIDENTS






Figure 1:

c. Types of Attacks

Malicious Code Attacks

FIWC recommends that when dealing with malicious code attacks, you follow the recommended six stages of incident response. There are, however, numerous special considerations for dealing with malicious code. The following procedures will facilitate efforts to deal with malicious code incidents:

(1) Virus incidents. A virus is self-replicating code that operates and spreads by modifying executable files. Provide your users with training concerning how viruses work and the procedures that limit the spread of viruses. Viruses are user-initiated and would pose virtually no threat if every user always followed sound procedures.

Obtain the anti-virus tools needed and start using them as soon as possible. You can obtain an effective virus detection and eradication tool by contacting NISE East . A simple (but not always effective) way to detect viruses is to look for unexplained increases in the length of executable files. Since viruses work by modifying applications and system executables, a growth in the length of these files typically indicates the presence of a virus. Remember, though, that saboteurs and malicious code can modify any program to which they have write access, so ensure the integrity of any anti-virus tool. A good technique is to keep at least one known good copy of anti-virus software on a write-protected floppy disk.

Immediately discontinue using any computer infected by a virus. Leave the infected computer on and call technical support. Leave a quarantine sign on the computer screen to warn others to not use the computer. Do not attempt to eradicate the virus and restore the system without the assistance of a qualified technical support specialist. Make a copy of any virus that has infected a computer before it is eradicated so that your technical support team and/or FIWC can analyze the virus. Be sure additionally that the virus is eradicated from all backup disks. Failure to clean backup disks is the major cause of re-infections.


(2) Macro Viruses. Macro viruses are a new type of virus that use an application's own macro programming language to distribute themselves. Unlike previous viruses, macro viruses do not infect programs; they infect documents. The three macro viruses currently known by the anti-virus community are the Word Prank Macro also known as the Concept virus, the DMV virus and the Nuclear virus.

(3) Worms are self-replicating code that is self-contained, i.e., capable of operating without modifying any software. Worms are best noticed by looking at system processes. If an unfamiliar process (usually with an unusual name) is running and is consuming a large proportion of a system's processing capacity, the system may have been attacked by a worm. Worms also sometimes write unusual messages to users' displays to indicate their presence. Messages from unknown users that ask you to copy an electronic mail message to a file may also propagate worms.

Worms generally propagate themselves over networks. As such they can spread very quickly, so if a worm is noticed the system administrator or technical support specialist should be informed immediately. Saving a copy of any worm code found on a system can considerably

accelerate efforts to analyze and deal with the worm. Prompt killing of any rogue processes created by the worm code minimizes the potential for damage. If the worm is a network-based worm, i.e., uses a network to spread itself, technical support should disconnect any workstations or client machines from the network unless the network is protected by very strong network defenses (e.g., firewalls). FIWC also needs to learn about any worm as soon as possible to minimize the impact of the worm across the many DoN organizations that exist.

(4) Trojan horse programs are hidden programs, often with a misadvertised purpose. Most malicious code is really a Trojan horse program in one way or another. A virus that disguises its presence, then executes later is technically a Trojan horse program to some degree, since the virus is hidden for part of its life cycle. Trojan horse programs are often designed to trick users into copying and executing them. Several years ago, for example, someone stood outside of the location of a technical trade fair and handed free diskettes to anyone who would take them. Although the program was supposed to determine the chances of contracting the AIDS virus, users who loaded and executed the program found that the program damaged the hard disk.

The best way to avoid Trojan horse programs is to be discriminating about using any new software that is obtained. Be especially suspicious of electronic bulletin board services, some of which may contain Trojan horse programs. If there is any doubt about the authenticity or functionality of a software program, take it to a technical support specialist who can analyze it and determine whether or not the program contains any Trojan horse code. If it is discovered that a Trojan horse program has damaged or otherwise infected a system, leave the system alone and contact the system administrator or technical support specialist. Again, leaving a quarantine sign on the system is a wise procedure. It is generally easy to eradicate a Trojan horse program---simply delete it. Ensure that a copy of the Trojan horse program is saved (on a specially marked diskette used only for this purpose) and given to FIWC and others before the program is deleted off of the system.

(5) Cracking utilities. Cracking utilities are programs planted in systems by attackers for a variety of purposes such as elevating privileges, obtaining passwords, disguising the attacker's presence, and so forth.

Cracker/Hacker Attacks

If your systems are connected to the MILNET or Internet, there is a fairly high chance that one or more cracker(s) will attack your systems sometime in the near future. Crackers (sometimes called "hackers") are unauthorized users who attempt to obtain unauthorized access to remote systems. Modem dial-in is another favorite way to crack systems. A few years ago more attacks were initiated by insiders, e.g., Navy employees or military personnel at a Navy sites, than anyone else. The nature of these attacks has, however, changed substantially over the last few years. Several years ago crackers sat at a terminal entering commands, waiting to see what would happen,then entered more commands. Today, however, most cracking attacks are automated and take only a few seconds. This makes identifying and responding to the intrusion more difficult. A recent study showed that less than one percent of system administrators whose system was penetrated by a special team both noticed the intrusions and called someone else to report the intrusions.

Protecting against a cracker/hacker attack is generally not an easy task. The best measures to adopt include always using a good (difficult-to-guess) password and setting file access permissions conservatively (e.g., so that the "world" cannot write to the home directory). System administrators should install tools such as password filters than prevent users from adopting easy-to-guess passwords and tools that check file integrity. A tool that is becoming increasingly necessary because there are so many sniffer attacks is a one-time password tool. This tool provides a list of passwords, each of which is to be used with a particular login. This prevents any password from being used successfully more than once; if a perpetrator captures a password over the network as someone remotely logs into a system, that password will not work when the perpetrator enters it.

Crackers now generally use "cracking utilities" when they obtain or attempt to obtain unauthorized remote access to systems. Cracking utilities usually are different from conventional malicious code attacks in that most cracking utilities do not disrupt systems or destroy code. Cracking utilities are typically "a means to an end"---obtaining superuser access, modifying audit logs, etc. Checksum or crypto-checksum tools are effective in spotting changes in files and are, therefore, effective in detecting cracking utilities. To use these tools you need to compute a checksum or crypto-checksum at one point in time, then compare the result to the currently obtained result. If there is a difference and if there is no readily available explanation, the integrity of the examined file may have been compromised. Remember, though, that saboteurs can modify a program to which they have access, so store the checksum/crypto-checksum programs off line and securely (e.g., on a write-locked disk stored in a safe) unless you are running them.

Indications that a system has been compromised by a hacker include most of the symptoms of incidents listed earlier in this guidebook. In particular you might notice changes to directories and files, a displayed last time of login that was not the actual time of last login,

finding that someone else is logged into an individual's account from another terminal, and inability to login to an account (often because someone has changed the password). In most UNIX systems you can type the commands shown in Figure 2 to obtain more information about suspicious events:


Command Displayed Information
who

last

who is logged in

logins/logout

acctcom user commands entered
ps current processes

Figure 2

Unix Commands to Access Logged Information

If these or other suspicious signs are noticed the system administrator should be notified immediately. Be sure to avoid using e-mail because many crackers can read other individual's e-mail routinely.

If a cracker is caught in the act of obtaining unauthorized access, the best course of action is to promptly determine how much danger the attack poses. If the attacker has obtained superuser access, is deleting or changing user files, or has access to a machine that supports critical Naval operations or contains sensitive data, the attack poses a serious threat. In this case it is best to lock the cracker out of this system (by killing the processes the cracker has created). If on the other hand the cracker does not obtain superuser access and does not appear to be damaging or disrupting a system, it is often best to let the cracker continue to have access while authorities obtain information necessary to catch and possibly prosecute the perpetrator.

A critical stage in cracker/hacker attacks is eradication. Because crackers so frequently use cracking utilities, it is important to ensure that no cracking scripts remain on the system once the cracker's attack has ceased. Leaving some or all of the cracking utilities can allow the attacker easy re-entry and possibly superuser access if the cracker attacks the compromised system again sometime later. Remember to make copies of any cracking utilities found in compromised systems and get them to FIWC. Be sure to also restore any file permissions and configuration settings that the cracker may have changed to their normal value.

Another critical component of responding to cracker/hacker attacks is handling evidence that is gathered. System log printouts, copies of malicious code discovered in systems, backup tapes, and entries recorded in log books may conceivably be used as evidence against perpetrators.

Resolving cracker/hacker attacks is generally not easy. Not only are these attacks difficult to detect, but they also tend to be very short-lived, making them difficult to monitor and trace. FIWC is the organization which can best determine what the crackers have been doing, where the attack originated, and who the attackers are.

FIWC obtains information about incidents from the many DoN sites throughout the world and also keeps in close contact with other incident response teams. Furnishing relevant information to FIWC is, therefore, especially critical.

d. User-Detected Technical Vulnerabilities

Most of the currently known technical vulnerabilities in applications and operating systems have been discovered by users. These vulnerabilities are often discovered as users attempt to run a program or change configurations. If a technical vulnerability is discovered that can be used to subvert system or network security, immediately document that vulnerability. Record the following:

(1) What the vulnerability is

(2) How the vulnerability can defeat security mechanisms

(3) How to exploit the vulnerability (including special conditions under which the vulnerability occurs)


After documenting the vulnerability, someone else in your organization should verify that the vulnerability exists. Then move the information up the reporting chain, as shown in the reporting chain diagram below. You should not post the vulnerability information you have discovered to the network nor should you share this information with other response teams and vendors. FIWC will coordinate with other response teams and vendors. Remember that if you find a vulnerability in a sensitive unclassified system, that vulnerability may also apply to classified systems. The vulnerability information, therefore, may be classified. Because of this possibility, following the procedures in this section may also enable you to avoid security violations.

e. Reporting Procedures

If a computer security incident is detected, it should immediately be reported to the appropriate ISSO. Each user should know how to contact the ISSO responsible for their information systems.

If the ISSO cannot be contacted, the incident should be reported to the ISSM. Again, all users need to who their ISSO is and how to contact them.

If users cannot contact either their ISSO or ISSM, they should call FIWC directly to report the incident. The timing of reporting incidents depends upon whether or not the user knows how to resolve the security incident, as shown in Figure 3.

The ISSO has the responsibility to report incident information upwards to the ISSM and FIWC in a timely fashion. Figure 4 shows a standard reporting chain. In addition, the ISSO should be prepared to advise the ISSM on immediate response decisions in the event of a serious breach of security, as in the case of an attacker gaining access via the Internet. If there is evidence of criminal activity, it is the ISSM's responsibility, in concert with the CO, to notify the Naval Criminal Investigative Service (NCIS) and co-operate with NCIS investigators. Note that if criminal activity is suspected or evident, FIWC will contact NCIS. It may be advisable for the ISSM or CO to contact NCIS directly after advising FIWC, rather than waiting for FIWC to contact NCIS.

Situation Timing of Response

User knows how to resolve incident

User tries, but is unable to contact ISSO after 3 days of

discovering incident

User tries, but is unable to contact ISSM or ISSO after 7 days of discovering incident


Report incident to ISSO

Report incident to ISSM without further delay

Report incident to FIWC without further delay

User does not know how to resolve incident

User tries, but is unable to contact ISSO after 2 hours of discovering incident

User is unable to contact either ISSO or ISSM within six hours of discovering incident


Promptly report incident to ISSO

Report incident to ISSM without further delay

Contact FIWC without further delay

Figure 3

Timing of Reporting Incidents



















(If appropriate)







Figure 4

The Standard Reporting Chain


CAUTION: Do not disseminate information about incidents to any person, agency, or organization that is not in the reporting chain shown in the figure above. Only FIWC and NCIS have been granted the authority to share information about DoN information system security incidents with others outside this reporting chain.

f. Legal Procedures

This guidebook is not intended to provide detailed legal guidance. Legal precedent dictates, however, that you should adhere to the following procedures to avoid compromising the ability to prosecute perpetrators of computer crime.

Every DoN system should display a warning banner visible to all users who attempt to login to the system. The warning banner should advise users that the system is a U.S. Government system and only official use is allowed. Any unauthorized use may result in criminal prosecution. Remove any login banners that welcome users to a system---perpetrators may argue that they were not warned about unauthorized usage, but were instead encouraged to use a system that welcomed them. You should also include a statement in the login banner to the effect that use of a system constitutes voluntary consent to have one's computing-related activity monitored.

Another similar legal issue concerns monitoring systems and networks. Reading audit logs is not considered an invasion of privacy. The U.S. Department of Justice advises, however, that capturing packets that are transmitted over networks, then reading those packets verbatim constitutes a possible violation of the Electronic Privacy Act. You should not, therefore, use sniffer devices and sniffer programs to monitor the content of messages transmitted over networks, nor should you use an intrusion detection tool that does the same. Using monitoring tools that determine what type of packet was sent, its source and destination, etc. is not, however, problematic from a legal standpoint.

Finally, anything related in any way to an incident or possible incident is potentially a piece of evidence. As such, handling the notes you take, audit logs and backups you obtain, copies of malicious code, and so forth is critical. Soon (e.g., daily) after new information is recorded in the log book, take it to someone within your activity who is responsible for handling such evidence. This person should copy each new page of the log book, store the copy in a locked container, and provide a signed and dated receipt. Audit logs and other physical entities should be handled in the same or similar manner. If these procedures are not followed , trial attorneys for the defense may be able to successfully argue that the evidence was fabricated.

7. Conclusion.

In covering a wide range of topics related to incident response, this guidebook stresses above all else two fundamental principles. The first is the importance of following well-defined and systematic procedures for responding to security-related incidents. By enumerating six stages (preparation, detection, containment, eradication, recovery, and follow-up) of essential incident response activity, this guidebook provides a sound set of considerations to use either verbatim or as a basis for developing custom procedures tailored to specific operational environments. The only effective way to respond to incidents is to use a structured methodology.

Finally, even if incident response efforts are conducted systematically, they are of little value if conducted in isolation. Coordinating efforts with others is also a critical facet of incident response. Sharing data about intrusions and malicious code can for instance enable others to prevent or more quickly recognize and eradicate incidents. Cooperation among an organization's personnel can drastically reduce the manpower needed to respond to incidents,

and is frequently necessary when a legal investigation is in progress. To this end FIWC plays a particularly important role within DoN. FIWC not only provides users with the information they need, but coordinates response efforts throughout DoN. Plan to more fully utilize FIWC's capabilities, therefore, as you develop and enhance your incident response strategies.

APPENDIX A

GLOSSARY

anomaly An unusual or atypical event (in a system or network)

attack scanner A tool used to remotely connect to systems and determine security

vulnerabilities in those systems that have not been fixed

cracker People who attempt to obtain unauthorized access to remote

systems

checksum Value computed, via some parity or hashing algorithm, on

information requiring protection against error or manipulation.

code System of communication in which arbitrary groups of letters,

numbers, or symbols represent units of plain text of varying length.

cracking utilities Programs planted in systems by attackers for a variety of purposes

such as elevating privileges, obtaining passwords, disguising the

attacker's presence, and so forth

cryptographic A checksum that is generated using a checksum cryptographic

means.

It is used to detect accidental or deliberate modification of data.

See message authentication code.

encryption Using cryptographic means to render information unintelligible in

a manner that allows the information to be decrypted into its

original form. The process of transforming plaintext into

ciphertext.

event Any noticeable occurrence in a computing system

exposure Any avenue that can lead to disruption of service or compromise

and/or destruction of data

firecall Procedures to provide operational procedures conntinuity when

there is a significant risk of prolonged failure or disruption

firewall Used to control access to or from a protected network. Enforces a

network access policy by forcing connections to pass through this

system, where they can be examined and evaluated. The system

can be a router, a personal computer, a host, or a collection of

hosts, set up specifically to shield a site or subnet from protocols

and services that can be abused from hosts outside the subnets. [O].

FIWC Fleet Information Warfare Center

hacker Same as cracker

hoax Spreading false information

incident An adverse event (that in the context of this guidebook is related

to computing systems)

Information Warfare Tactics and methods used to affect an adversary's

information infrastructure

integrity (1) A subgoal of computer security which pertains to ensuring

that data continues to be a proper representation of information,

and that information processing resources continue to perform

correct processing operations.

(2) A subgoal of computer security which pertains to ensuring

that information retains its original level of accuracy. Data

integrity is that attribute of data relating to the preservation of

(1) its meaning and completeness,

(2) the consistency of its representation(s), and

(3) its correspondence to what it represents. System integrity is

that attribute of a system relating to the successful and correct

operation of computing resources.

intrusion Unauthorized access to a system or network

ISSO Information Systems Security Officer

ISSM Information Systems Security Manager

NAVCIRT Naval Computer Incident Response Team

NCIS Naval Criminal Investigative Service

PAO Public Affairs Office

sniffer A device or program that captures packets transmitted over a

network

social engineering "Conning" unsuspecting people into sharing information about

computing systems (e.g., passwords) that should not be shared for

the sake of security

threat Capabilities, intentions, and attack methods of adversaries to

exploit, or any circumstance or event with the potential to cause

harm to, information or an information system.

Trojan horse Computer program containing an apparent or actual useful

function that contains additional (hidden) functions that allows

unauthorized collection, falsification or destruction of data

virus Self replicating, malicious program segment that attaches itself to

an application program or other executable system component and

leaves no external signs of its presence.

vulnerability Weakness in an information system, or cryptographic system, or

components (e.g., system security procedures, hardware design,

internal controls) that could be exploited to violate system

security policy.

worm Independent program that replicates from machine to machine

across network connections often clogging networks and

computer systems as it spreads.

APPENDIX B

NAVCIRT SERVICES

NAVCIRT contact information is as follows:

Phone: 1-800-628-8893

Pager: 1-800-759-7243, PIN# 5294117

Address:

Commanding Officer

Fleet Information Warfare Center

2555 Amphibious Drive

Norfolk, VA 23521-3225

ATTN: NAVCIRT

e-mail: navcirt@fiwc.nosc.mil

There are currently many bulletin board and ftp services that contain valuable information not only about incident response but also computer and information security as well. The most relevant source of information to DoN users is the NISE East bulletin board. You can access this service by using ftp (file transfer protocol) to reach the following address:

infosec.nosc.mil

Other useful information is available from the following:

risks-request@csl.sri.com

cert-advisory-request@cert.org

ciac@llnl.gov

first@org

alt.security

comp.security.announce

comp.security.misc

comp.security.unix

firewalls@greatcircle.com

academic-firewalls@net.tamu.edu

research.att.com

decwrl.dec.com

coast.cs.purdue.edu

Information specific to viruses can be found at these sources:

http://www.first.org/virus/virus1/ (world wide web access)

computer-virus_801929995@rtfm.mit.edu

A good source of information about handling incidents are the proceedings of the Forum of Incident Response and Security Teams (FIRST) Workshops on Incident Response (available through NAVCIRT). Additional information sources include:

(1) Brock, J. Testimony before U.S. Senate Government Information Dissemination Subcommittee, November 19, 1991.

(2) Schultz, E.E. "An Analysis of Intrusions into U.S. Military Computers during Operation Desert Storm/Desert Shield." Technical report prepared for National Institute of Standards and Technology, November, 1992.

(3) Schultz, E. E. Testimony before U.S. Senate Government Information Dissemination Subcommittee, November 19, 1991.

(4) Schultz, E.E., Brown, D.S., and Longstaff, T.A.. Responding to Computer Security Incidents: Guidelines for Incident Handling. University of California Technical Report UCRL-ID-104689, 1990.

(5) Stoll, C Tracking a Spy through a Maze of Computer Espionage: The Cuckoo's Egg. New York: Doubleday, 1989.

Many tools are available to help prevent and/or respond to incidents. NAVCIRT will, for example, provide you with a copy of an anti-virus package at no cost. NAVCIRT can in addition provide you with a copy of a crypto-checksum program.

There are now many public domain tools available to help prevent and/or detect incidents. Most of these tools deal with UNIX security problems in some way. Tools include:

COPS - checks systems for security vulnerabilities, improper configurations, inappropriate modes, and easy-to-guess passwords

Courtney - detects when SATAN (see below) has been run against a system within a network

CRACK - finds easy-to-guess passwords

ICE PICK - remotely scans systems to determine whether there are vulnerabilities

NFS Watch - monitors use of the Network File System

npasswd - keeps users from choosing easy-to-guess passwords

Password+- keeps users from choosing easy-to-guess passwords

PEM (Privacy Enhanced Mail) - protects the secrecy of electronic mail messages

Portwrapper - protects the portmapper (port 111) so that cracking utilities cannot steal file handles and obtain unauthorized mount access to NFS servers

SecureLib - provides a secure library of C routines

Socks - proxies gateway services securely

SWATCH - detects suspicious user activity

TCP Wrapper - protects individual host machines by accepting or denying remote service requests

Tripwire - detects changes in file integrity

Most of these tools are available through one or more of the ftp sites listed earlier in this appendix.

If you need technical assistance, the first place you should look is your own site. Your site probably has a technical support, system administration group or help desk function that can provide quick answers to your technical questions. If the assistance you need is not available at your site, your vendor representative can inform you how to reach someone who can answer your questions. Remember, too, that NISE East possesses a range of technical knowledges and abilities and is willing to assist any user within the Navy.

APPENDIX C

VULNERABILITY REPORT

Classification markings/Distribution statements

A. Required Information.

1. Report Date:

2. Contact:

a. Name:

b. Organiazation:

c. Mailing Address:

d. Phone Number:

e. Position:

3. Hardware/Software:

a. List hardware and system configuration:

b. Software Description:

(1) Operating system (include release number):

(2) Describe any unique attributes - i.e., locally modified special security properties:

B. Executive Summary of Vulnerability.

A description of the nature and effect of the vulnerability in as general terms as possible:

C. Description of Technical Vulnerability:

1. A scenario that describes specific conditions to demonstrate the weakness or design deficiency. The description should sufficiently describe the conditions so that the weakness or design deficiency can be repeated without further information. This scenario may include source or object code.

2. Describe the specific impact or effect of the weakness or design deficiency in terms of the following: (1) denial of service, (2) alteration of information, and/or (3) compromising of data. Cite specific examples as appropriate.

3. Indicate whether or not the affected vendor has been notified.

D. Suggested Fixes - Describe any code or procedures you may have discovered that when implemented may reduce the impact of the defined technical vulnerability.

E. Additional Information.

1. System Specifics:

a. Location:

b. Owner:

c. Network connections:

d. Security attributes:

2. System use and highest classification of data on system:

3. Additional clarifying information.

APPENDIX D

VIRUS REPORT



Provide the following information to FIWC via your ISSM.

1. Name of the infecting virus:

2. Source of the virus:

3. Other locations, within or outside of your command, possibly infected as a result of this virus:

4. Number and types of systems infected (i.e. hard disks and servers), along with the number of floppy diskettes infected:

5. Method of clean-up:

6. Number of man hours required in effort:

7. Damage or observations resulting from the virus triggering:

8. Your command name and location:

9. A point of contact at your command (i.e. ISSM) include commercial and DSN phone number:




APPENDIX E

HACKER REPORT

ORGANIZATION______________________________

PHONE______________________________________

1. Report Date:

2. Incident Date:

3. Type Of Incident:

4. Individuals Involved (name/office):

5. Cost of this Incident (downtime, cost, etc.):

6. Summary of Incident and Investigation Results (e.g., number of hosts attacked, how was access obtained, how was attack identified, was a Incident Response Organization contacted prior to submission of report, etc...)







7. Supervisors Recommendations/Comments:

8. Investigating Official :

9. Local Action to Prevent Reoccurrence:

10. Recommended Action by INFOSEC Official:

11. Attack Address:

12. Physical location of system:

13. Hardware Configuration:

14. Operating System:

15. Security Software installed:

16. Highest level of data residing on system:

17. Damage or observations resulting from attack:

18. Other affected hosts/sites:

19. Your command name and location:

20. A point of contact at your command (i.e. ISSM) include commercial and DSN phone numbers)


SecurityUnit.com accepts no responsibility, express or implied, for the accuracy of the information disclosed in this Web Site. SecurityUnit.com will not be held responsible for any loss suffered in respect of any action taken as a result of the information contained in this Web Site. All content is provided solely for informational purposes; usage implies consent that SecurityUnit.com is free from any liability regarding the use or misuse of site material.
Copyright 2000-03 SecurityUnit.com, All Rights Reserved.