TABLE OF CONTENTS
b. Types of Incidents
b. Information Systems Security
c. Information Systems Security
d. Fleet Information Warfare Center
f. Naval Criminal Investigative
b. Stages of Responding to Incidents
e. User-Detected Technical Vulnerabilities
g. Reporting Procedures
h. Legal Procedures
VIRUS REPORT FORM
INTRUSION (HACKER) REPORT FORM
(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
NSWC Dahlgren is faced with a new and gigantic
challenge, that of Information Warfare. Our military, contractor, and
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 of our sensitive unclassified DoN systems connect to DREN,
(DISA's backbone that ties military networks together all over the
world) and 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 internet 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.
NSWC Dahlgren is faced with a new and gigantic challenge, that of Information Warfare. Our military, contractor, and research 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 of our sensitive unclassified DoN systems connect to DREN, (DISA's backbone that ties military networks together all over the world) and 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 internet 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.
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
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 purpose of this incident response guidebook includes:
a. Helping NSWCDL personnel quickly and efficiently recover from
security incidents. These guidelines reflect "lessons learned"
from experience in responding to virtually hundreds of DoN 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
NSWCDL 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.
This document applies to all NSWCDL activities processing GENSER classified or sensitive but unclassified information.
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.
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.
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
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
5. Organizational Roles.
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 here. Users whether government or contractor are responsible for reporting incidents.
In addition to their incident reporting responsibilities, users and
their IS security officers are responsible for handling minor
incidents. A virus infection that is detected by resident software is
one such type of incident. Virus
handling procedures can be found here.
b. Information Systems
Security Officers (AISSOs)
The AISSO 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 AISSO. The AISSO is the first level of interaction for users experiencing security incidents. It is the AISSO'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
The ISSM is responsible for coordinating computer security efforts within an organization. The ISSM will pass incoming incident information from the AISSOs 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 AISSOs and ISSMs
in handling security incidents. NAVCIRT's responsibilities furthermore
include guiding the AISSOs 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 AISSO/ISSM community concerning preservation
of evidence and downstream liability.
It is also NAVCIRT's mission to disseminate security tools to the user community.
The Naval Computer Incident Response Team at The Fleet Information
Warfare Center. The Fleet Information Warfare Center (FIWC) is
located in Building 1126 on Little Creek Naval
Amphibious Drive in Norfolk, Virginia.
NAVCIRT Line: (800) 628-8893
Coml: (804) 464-8832
Unclas Fax: (804) 363-4267
Clas Fax: (804) 464-8831
Message: FLTINFOWARCEN NORFOLK VA//
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.
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. Responding to Incidents
There are 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. Part of the preparation has been to 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.
NSWCDL maintains a suitable baseline of
protection for systems.
NSWCDL has prepared written incident response procedures and they are widely available. These written procedures define who to contact and what the first steps are. After appropriate notifications are made, users and their security officers with support from CD2S and the Command Decision Team as required shall complete the following.
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. describes notification
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.
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 information about the
vulnerability using the vulnerability
report form. Make sure the following is clear:
(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 internet nor should you share this information
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
e. Reporting Procedures
If a computer security incident is detected, it should immediately
be reported to the appropriate AISSO. Each user should know how
to contact the AISSO responsible for their information systems.
If the AISSO cannot be contacted, the incident should be reported to
the ISSM. If the ISSM cannot be
contacted, follow the procedures listed in NSWCDL's written
procedures. Again, all users need to know who their AISSO is and
how to contact them.
The AISSO has the responsibility to report incident information
upwards to the ISSM in a timely fashion. In addition, the AISSO
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.
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. Further, all information about an incident should be forwarded to the ISSM who will coordinate any release with the CO and PAO.
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 NSWCDL system should display this warning banner visible to all users who attempt to login to the system. 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.
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.
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.
Document authored by: Stephen Northcutt OCT 96 based on P5239-19