U.S. DEPARTMENT OF TRANSPORTATION
OFFICE OF THE SECRETARY
DOT H 1350.255

DEPARTMENTAL GUIDE TO
INCIDENT HANDLING
PLANNING

TABLE OF CONTENTS

    1. PURPOSE

    2. SCOPE

    3. GOALS

    4. REFERENCES

    5. OVERVIEW OF INCIDENT HANDLING

    6. INFORMATION SYSTEM SECURITY INCIDENTS

    A. Intrusion

    B. Malicious Code

    C. Fraud and Theft

    D. Errors and Omissions

    F. Loss, Theft, or Damage

    G. Denial of Service

    7. INCIDENT HANDLING PLANNING

    A. Incident Prevention

    B. Incident Detection

    (1) System and Network Logging Functions

    (2) Detection Tools

    (3) Detection Techniques

    C. Incident Reporting and Communication

    (1) Incident Reporting

    (2) Communication

    D. Incident Response

    (1) Collect/Protect Information

    (2) Contain The Incident

    (3) Correct The Root Problem

    (4) Return To Normal Operation

    E. Lessons Learned

    (1) Post Mortem Analysis

    (2) Lessons Learned Implementation

    (3) Risk Assessment

    8. COMPUTER SECURITY INCIDENT RESPONSE TEAM

    ATTACHMENT A

    SECURITY INCIDENT HANDLING PLAN TEMPLATE

     

    DEPARTMENTAL GUIDE TO
    INCIDENT HANDLING PLANNING

     

    PURPOSE

      The purpose of this Guide is to provide Department of Transportation (DOT) and their Operating Administration managers, ISSO’s and network administrators with a step-by-step approach for developing an Incident Handling capability within their organizations, and Incident Response Teams capable of responding effectively and efficiently to information system security "incidents".

    SCOPE

      The provisions of this Guide apply to the Department of Transportation (DOT), its Secretarial Offices and Operating Administrations.

    GOALS

      The Goal of incident handling planning is to provide reasonable methods for limiting the possibility of an adverse effect on a DOT Information System due to the occurrence of an information system security incident, and for facilitating the rapid and successful investigation of an incident, should one occur.

    REFERENCES

      The DOT Departmental Information Resources Management Manual (DIRMM) DOT H 1350.2 implements statutory and regulatory Information Resources Management (IRM) and security requirements for the Department. It also calls for ensuring the confidentiality, integrity, and availability of information contained, processed, or transmitted in/on sensitive systems. Refer to DOT H 1350.2.1 REGULATORY AND GUIDANCE DOCUMENTS for specific references.

    OVERVIEW OF INCIDENT HANDLING

      An information system security incident is an event that has actual—or the potential for—adverse effects on computer or network operations. Such incidents can result in fraud, waste, or abuse; can compromise information; or can cause loss or damage to property or information. An incident can result from a computer virus, other malicious code, employee malfeasance, or a system intruder, either an insider or an outsider. Although it is known that hackers and malicious code can pose serious threats to systems and networks, actual incidents of such damage cannot be predicted. Security incidents, such as break-ins and service disruptions, on larger networks (e.g., the Internet), have harmed the computing capabilities or various organizations.

      Incident handling is closely related to Continuity Of Operations planning, as described in DOT H 1350.254 Developmental Guide To Continuity Of Operations Planning. In fact, an incident handling capability may be viewed as a component of Continuity Of Operations planning, because it provides the ability to react quickly and efficiently to disruptions in normal processing. Broadly speaking, Continuity Of Operations planning addresses events with the potential to interrupt system operations. Incident handling can be considered that portion of contingency planning that responds to malicious technical threats.

      When left unchecked, malicious software can significantly harm an organization's computing, depending on the technology and its connectivity. An incident handling capability provides a way for users to report incidents, and the appropriate response and assistance to be provided to aid in recovery. Technical capabilities (e.g., trained personnel, intrusion detection, and virus identification software) are prepositioned, ready to be used as necessary. Moreover, the organization will have already made important contacts with other supportive sources (e.g., legal, technical, and managerial) to aid in containment, identification and recovery efforts.

      Like most Federal Agencies, DOT uses large LANs internally and also connects to public networks, such as the Internet. By doing so, DOT increases its exposure to threats from intruder activity. An incident handling capability can provide enormous benefits by allowing a rapid response to suspicious activity and coordinating incident handling with responsible agencies, offices and individuals, as necessary. Intruder activity, whether hackers or malicious code, can often affect many systems located at many different network sites; thus, handling the incidents can be logistically complex and can require information from outside the organization. By planning ahead, such contacts can be pre-established, and the speed of response improved, thereby containing and minimizing damage.

      An incident handling capability also assists DOT in preventing (or at least minimizing) damage from future incidents. Incidents can be studied internally to gain a better understanding of current threats and vulnerabilities, so that more effective safeguards can be implemented. Additionally, through outside contacts (established by the incident handling capability) early warnings of threats and vulnerabilities can be provided. Mechanisms will already be in place to warn users of these risks.

      Finally, having an incident handling capability allows DOT organizations to learn from the incidents that they have experienced. Data about past incidents (and the corrective measures taken) can be collected and analyzed for patterns. Vulnerabilities can also be identified via this process. Knowledge about the types of threats that are occurring and the presence of vulnerabilities can aid in identifying security solutions. This information will also prove useful in creating a more effective training and awareness program, and thus help reduce the potential for losses.

    INFORMATION SYSTEM SECURITY INCIDENTS

    A. Intrusion

    This is the deliberate attempt by an individual (insider / outsider) to gain unauthorized access into a system. 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.

    B. Malicious Code

    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.

     

    C. Fraud and Theft

    Information systems can be exploited for fraud and theft both by automating traditional methods of fraud and by using new methods. Systems that control access to any resource are targets (e.g., time and attendance systems, financial systems, inventory systems, and long-distance telephone systems). Information system fraud and theft can be committed by insiders or outsiders. Insiders are responsible for most incidents of fraud.

     

    D. Errors and Omissions

    Errors and omissions can be caused during the creation or modification of data.

    E.    Employee Sabotage and Abuse

    Employees are most familiar with their employer’s information systems and know which actions might cause the most damage, mischief, or sabotage. Common examples of information system-related sabotage include:

    (1) Destroying hardware or facilities.

    (2) Planting logic bombs that destroy programs or data.

    (3) Intentionally entering data incorrectly.

    (4) Crashing systems.

    (5) Intentionally deleting data.

    (6) Intentionally changing data.

    F. Loss, Theft, or Damage

    Computer equipment, software, and data may be misplaced, stolen, or physically damaged.

    G. Denial of Service

    The information system is not available for use to authorized personnel due to deliberate or accidental interference with system operations. Perpetrators and malicious code can disrupt system 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.


    INCIDENT HANDLING PLANNING

    Incident handling planning may be accomplished as a five-step process, consisting of:

    Step 1 – Identifying measures that help to prevent incidents from occurring, such as the use of anti-virus software, firewalls, and other tools and practices.

    Step 2 – Defining measures that can detect the occurrence of an incident, such as intrusion detection monitoring systems, firewalls, router tables and anti-virus software.

    Step 3 – Establishing procedures for reporting and communicating an incident. This reporting procedure should notify all affected parties should an incident be detected, including parties both within and external to the affected organization.

    Step 4 – Defining processes and measures for responding to a detected incident, in order to minimize damage, isolate the problem, resolve it, and restore the affected system(s) to normal operation. This also includes the creation of a Computer Security Incident Response Team (CSIRT) trained and responsible for incident response.

    Step 5 – Developing a procedure for identifying and implementing lessons learned regarding the incident.

    A Template for a Security Incident Handling Plan is contained in Attachment A of this Guide.

If an organization is not adequately prepared to detect the signs that an incident has occurred, is occurring, or is about to occur, it may be difficult or impossible to later determine if the organization’s information system(s) have been compromised. Failure to identify the occurrence of an incident can leave the organization vulnerable in a number of ways:

  • Damage affecting multiple systems both inside and outside of the organization due to an inability to react in time to prevent the spread of the incident.
  • Negative exposure that can damage the organization’s reputation and stature.
  • Possible legal liability for failing to exercise an adequate standard of due care when the organization’s information system(s) is used to inadvertently or intentionally "attack" other organizations.
  • Damage to data, systems and networks due to not taking timely action to contain and control an incident, resulting in loss of productivity, increased costs, etc.

1. System and Network Logging Functions

Collecting data generated by system, network, application and user activities is essential for analyzing the security of these assets, and for incident detection. Log files contain information about what activities have occurred over time on the system. These files are often the only record of suspicious behavior, and may be used not only to detect an incident, but also to help with system recovery, aid in investigation, serve as evidence, and back up insurance claims. Incident detection planning should include identifying the types of logs and logging mechanisms available for each system asset, and the data recorded within each log. If vendor-provided logging mechanisms are insufficient to capture the data required, they should be supplemented with tools that capture the additional information. Logging functions should always be enabled.

2. Detection Tools

It is important to supplement system and network logs with additional tools that watch for signs that an incident has occurred, or has been attempted. These include tools that monitor and inspect system resource use, network traffic and connections, and user account and file access; tools that scan for viruses; tools that verify file and data integrity; tools to probe for system and network vulnerabilities; and tools to reduce, scan, monitor and inspect log files. Examples of detection tools include:

3. Detection Techniques

The general approach for incident detection is based on three simple steps, --- observe/monitor information systems for signs of unusual activity, investigate anything thought to be unusual, and if something is found that cannot be explained by authorized activity, immediately initiate predetermined incident response procedures.

Recommended practices include:

Designated organization personnel, as well as personnel outside of the organization cannot execute their responsibilities if they are not notified in a timely manner that an incident is occurring or has occurred, and if they are not kept informed as the incident progresses. In addition, there are types of incidents wherein the public communications aspects, if mishandled, could result in serious negative publicity or loss of reputation. Hence it is important that incident reporting and information dissemination procedures be established and periodically reinforced, so that all personnel are aware of how they are to participate when an incident occurs.

1. Incident Reporting

Incident handling planning should specify who should be notified in the event of an intrusion, who does the notifying of whom, and in what order. The order of notification may depend on the type of incident, or on other circumstance. Parties to be notified include: (NOTE: These are not identified in any specific order)

Planning for incident response should include the collection and protection of all relevant information, containing the incident, correcting the root problem leading to the incident, and, finally, returning the system to normal operation.

It is important to learn from the successful and unsuccessful actions taken in response to security incidents. Capturing and disseminating what worked well and what did not will help to reduce the possibility for similar incidents, and thus improve the overall information system security posture of DOT. Otherwise, DOT systems and applications will continue to operate at risk, and will likely fall victim to the same or similar type of incident again. Establishing a lessons learned capability includes the following steps: