IWS - The Information Warfare Site
News Watch Make a  donation to IWS - The Information Warfare Site Use it for navigation in case java scripts are disabled

1.0 Identification Data
1.1 BSP Number
1.2 BSP Title/Name
Incident Handling at BMDO
1.3 Version Number
1.4 Adoption Date
1.5 Approving Authority
Security Practices Subgroup
1.6 Responsible Organization
Ballistic Missile Defense Organization, US Department of Defense
1.7 Level of BSP
1.8 Security Processes or other Framework(s) Supported
Monitor System Activity (SPF and Monitor the Performance and Functional Effectiveness of Security Safeguards (SSE CMM BP.08.04)
1.9 Reserved
1.10 Points of Contact
Government BSP Owner:
Yes, post this contact information with the publicly accessible BSP.
  • Dennis Poindexter

Ballistic Missile Defense Organization
1725 Jefferson Davis Highway, Suite 1200
Arlington, VA 22209
Telephone No - 703-604-0098
Fax No. - 703-604-4229
E-mail - dennis.poindexter@bmdo.osd.mil

Vendor Partner:
Yes, post this contact information with the publicly accessible BSP.

  • Norm St. Laurent
  • Program Manager
    Computer Sciences Corporation
    1725 Jefferson Davis Highway, Suite 1200
    Arlington, VA 22202-4102
    Telephone: 703-604-0135
    Fax: 703-604-0689
    E-mail: norman.stlaurent-contractor@bmdo.osd.mil

2.0 What This BSP Does
2.1 BSP's Purpose
The purpose of this BSP is to address how to detect, handle, and recover from security incidents involving computer hosts or networks.

The need for Incident Handling

It has been shown that a skilled intruder can extract specific data from an archive, manipulate it to solve a problem, and commit the changes back in to the archive, all from the local or remote terminal undetected. It is this ability to manipulate data that makes proving a computer attack so difficult.

To combat computer attacks clear and effective incident handling techniques and methods must be employed. The must critical part of this methodology is documentation of all the circumstances surrounding the incident. With the details documented if the intrusion to see the light of day in a courtroom, it’s reasonable that the defense will do everything in its power to cast the shadow of uncertainty and unreliability over the prosecution. This shows why a clear and effective Incident Handling methodology must be in-place when law-enforcement is going the brought in.

2.2 Requirements for this BSP
Department of Defense (DoD) Chief Information Officer (CIO) Guidance and Policy Memorandum No. 6-8510 - – Department of Defense Information Assurance

E3.6.7. Incident Reporting and Response: In addition to protective measures designed into information systems and architectures, sites should have a structured ability to audit, detect, isolate, react and recover to intrusions, service disruptions, and incidents that threaten the security of DoD operations.

E3.6.7.1. Incident Reporting: All DoD organizations shall promptly report incidents via their appropriate chain of command. Types of incidents that will be reported include:

E3. Intrusion: Unauthorized access to an information system.

E3. Denial of Service Attacks: Actions which prevent any part of an automated information system from functioning in accordance with its intended purpose, to include any action which causes the unauthorized destruction, modification, or delay of service.

E3. Malicious Logic: Hardware, software, or firmware that is intentionally included in an information system for an unauthorized purpose, such as a virus or Trojan horse.

E3. Probe: In information operations, any attempt to gather information about an automated information system or its users online.

2.3 Success Stories
Having the proper incident handling procedures was instrumental in the stopping of an intruder into one of the government’s major testing facilities. Additionally, this methodology was used to successfully prosecute the intruder. This was due to proper documenting of the incident, the proper handling of the computer media, and the documentation.
3.0 What This BSP Is
3.1 Description of BSP
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.
3.1.1 Inputs
The resources needed to successful perform our incident handling function are as follows:
  • A incident handling team (2-4 persons)
  • System Administrator workstation to secure logs
  • Access to the network and host log files

One of the major issues that must be determined by an organization before an incident handling function can be activated is the definition of incident. For the purposes of this BSP the following definition of an incident and event is as follows:
The term "incident" refers to an adverse event in an 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 cause 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.
It must be clearly understood that this definition relies on the existence of a security policy that varies from organization to organization. Below are characterizations of the types of activities that are generally recognized as violating of a typical security policy. These activities include but are not limited to:

    1. A system alarm or similar indication from an intrusion detection tool
    2. 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)
    3. Accounting discrepancies (e.g., someone notices an 18-minute gap in the accounting log in which no entries whatsoever appear)
    4. Unsuccessful logon attempts
    5. Unexplained, new user accounts
    6. Unexplained, new files or unfamiliar file names
    7. Unexplained modifications to file lengths or/or dates, especially in system executable files
    8. Unexplained attempts to write to system files or changes in system files
    9. Unexplained modification or deletion of data
    10. Denial of service or inability of one or more users to login to an account
    11. System crashes
    12. Poor system performance
    13. Unauthorized operation of a program or sniffer device to capture network traffic
    14. "Door knob rattling" (e.g., use of attack scanners, remote requests for information about systems and/or users, or social engineering attempts)
    15. Unusual time of usage (remember, more security incidents occur during non-working hours than any other time)
    16. An indicated last time of usage of a user account that does not correspond to the actual last time of usage for that user
    17. 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 that possess the appropriate technical and computer security knowledge to determine exactly what has occurred. Collective judgment is typically better than a single person's judgment when it comes to identifying incidents.

Reporting Procedures

If a computer security incident is detected (excluding incidents involving classified information), it should immediately be reported to the appropriate NSO/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 Network Security Officer (NSO) at 604-4113. Again, all users need to know the identity of their ISSO and NSO are and how to contact them.

If users cannot contact either their ISSO or NSO, they should call C 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 CISSM and CIO 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 CISSM’s responsibility, in concert with the General Councel, to notify the Office Special Investigations. It may be advisable for the CISSM or Director DSC to contact OSI directly after advising DISA.

CAUTION: Do not disseminate information about incidents to any person, agency, or organization that is not in the above reporting chain.



The process of incident handling involves six stages:

    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. (See BMDO Incident Handling Procedures)
    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: (See BMDO Incident Handling Procedures)
      1. 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.
      2. 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.
      3. 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.
    3. 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.

Incident priorities

Due to limited resources and the growing number of incident reports, we may not be able to respond to every incident reported to us. We must prioritize our responses to have the greatest impact on the Internet community. The following type of reports receives the highest priority and are considered emergencies:

  • Possible life-threatening activity
  • Attacks on the Internet infrastructure, such as:
  • Root name servers
  • Domain name servers
  • Major archive sites
  • Network access points (NAPs)
  • Widespread automated attacks against Internet sites
  • Network sniffers
  • Router attacks
  • Root compromises


The outputs from the incident handling function are as follows:

  • Reports
  • Training scenarios
  • Document that can be passed to law-enforcement, as needed
3.2 Relationship to Other BSPs
This BSP is related to the Defense Information Systems Agency’s (DISA) Information Assurance Vulnerability Alert (IAVA) and as additional BSPs are developed, additional relationships will be added.
4.0 How To Use This BSP
4.1 Implementation Guidance
The implement an incident handling program the following is needed:
  • The SHADOW implementation material (hardware, software, and instructions)
  • Trained personnel to include a systems administrator
  • Management’s support
4.2 Implementation Resource Estimates
Personnel: Operating System Administrator or knowledge equivalent. Four people working full-time monitoring the intrusion detection system.
4.3 Performance Goals and Indicators (Metrics)
General Goal: The goal of information assurance program is to prevent or reduce the likelihood of computer system intrusions. But because no prevention measures are perfect, there also needs to be a strategy for handling incidents that includes preparation, detection, and response.
4.4 Tools
SHADOW intrusion detection system. Hardware and software needed for SHADOW installation is as follows:
  • Pentium II 350 MHZ RedHat Linux 5.1
  • 128MB RAM RedHat Linux Patches
  • 9GB SCSI Hard Drive CID Code
  • STB Velocity 128bit 8MB Video Card Libpcap
  • Generic Multi-Sync Monitor Tcpdump
  • Tcpslice
  • Secure Shell
4.5 Training Materials
Training materials include the following:
A Executive Overview and Briefing
[Provide materials, briefings, etc. used to gain management buy-in.]
B Reference List
[List books, articles, or URLs to enhance understanding this BSP.]
C Procurement Information
[Identify contract vehicles and SOWs if services or materials were procured.]
D Evaluation Information
E Recommended Changes
F Glossary
[Define terms helpful to understanding this BSP.]