• 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

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.

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.6.7.1.1. Intrusion: Unauthorized access to an information system.

E3.6.7.1.2. 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.6.7.1.3 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.6.7.1.4 Probe: In information operations, any attempt to gather information about an automated information system or its users online.

• 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.

Process

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

Outputs

The outputs from the incident handling function are as follows:

• Reports
• Training scenarios
• Document that can be passed to law-enforcement, as needed

• The SHADOW implementation material (hardware, software, and instructions)
• Trained personnel to include a systems administrator
• Management’s support

• 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

• The SHADOW installation guide
• Incident handling training and information located at: http://www.cert.org
• Training and instructional material from: http://www.sans.org