Link to the home page.
Print from PDF version
Wireless Security Practices PDF Document
 

Security Disciplines for Objective 3: Detection and Recovery

3-2. Critical Incident Response

Description

Critical incident response should be a part of a comprehensive information security program. The components of a critical incident response program include a warning network that communicates actual or potential risks in time for intrusions to be prevented, IDSs, and other technical tools and processes for uncovering breaches in security and reporting them to a central response team (CRT). The CRT will ideally be able to modify security parameters in the target information systems in time to prevent costly attacks to resources.

The cornerstone of incident response capability is an incident response plan that documents the parameters of response to an incident affecting information infrastructure. An information infrastructure incident is a real, perceived, or threatened event that involves data, agency applications, computers, networks, or communications with the potential to have a major negative impact on business operation. The plan uses a risk-management approach to characterize appropriate responses to incidents ranging in seriousness from no direct impact to customers to major disruption of agency operations or significant impact to the agency reputation.

Purpose

In conjunction with a notification network and CRT, a well-defined, documented, active incident response plan allows effective, efficient, and coordinated response to adverse circumstances, such as cyberterrorism and cybercrime. Incident response plans define the process of characterizing and responding to information infrastructure incidents that significantly impact critical business functions. Incident response plans document procedures for responding to situations that affect the ability to provide services to customers or meet legal or regulatory requirements. The communications network used to collect and disseminate security-related information provides internetworked criminal justice agencies with technical information, tools, methods, assistance, and guidance. The existence of a dedicated, central team allows proactive response to threats and provides liaison activities and analytical support. The team provides a focal point for collaborative relationships with federal civil agencies, the U.S._Department of Defense, academia, and private industry.

Principles

  • Incident response plans detail the responsibilities and actions to be taken to identify, notify, contain, eradicate, recover from, record, and report incidents. Creation of the plan should lead to:
    • Facilitating timely assessment of potential problems.
    • Ensuring a coordinated and comprehensive response to incidents that cross agencies.
    • Minimizing the impact of information infrastructure incidents on the ability to provide service.
    • Maintaining a positive public image and credibility.
    • Facilitating prosecution of offenders, as appropriate.
  • Procedures for responding to attacks (e.g., unauthorized access, denial of service, and virus infections) must be defined, documented, and tested. They should be linked with administrator/user communication and training. Automated systems management tools can notify administrators of attack, but procedures ensure the desired response. Specific procedures in the incident response plan must detail the following:
    • How a decision to activate the plan is made and by whom.
    • Rapid notification, deployment, and coordination of community resources to assess and respond to the incident.
  • The plan describes a central organization to implement the response and includes definition of the roles of the team leaders and members.
  • The plan defines a central organization responsible for providing the communication vehicle(s) and establishing service(s) in support of agency incident handling and reporting. Agencies request assistance from that central organization, as needed, to troubleshoot unusual or difficult-to-isolate threats.
  • The plan establishes out-of-band communication alternatives wherein the “compromised” device, platform, or media is not used to notify users or to report the incident.

Policies

Incident response priorities and procedures should be defined consistently with the security policy for the target information systems. The security policy should define the organizational responsibility and the priorities associated with incidents related to specific resources.

Best Practices

The incident response plan provides a collection point for the practices and “minimum” requirements related to critical incident response, as agreed to by the community. The following items, as best practices, need to be clearly defined within the incident response plan document.

Central Response Team (CRT)—The CRT registers security coordinators for contact at community member organizations. It collects “requests for response,” proactively monitors the environment within its sphere of control, and remains connected to higher-level communications networks. As the CRT creates or receives computer security alerts, it forwards them to all community chief information officers (CIO) and/or security coordinators. Each alert states, as a minimum, the identity of the risk, level of risk, and any available patches or inoculants to mitigate the risk. The CRT frequently informs the help desk(s) of the status and progress of any incident.

Organizational Responsibilities—A central security organization will use risk analysis instruments to determine what security threats are present to assets under the community’s control or custodianship. As threats are identified, ways to eliminate them or reduce them to acceptable levels will be put in place, with the full support of organization management. Internetworked partners must establish a mechanism that defines responsibilities for responding and reporting incidents and for sharing information about potential threats and intrusions in two directions.

Agency responsibilities include monitoring their own networked resources using an IDS. Upon receiving a security alert, agency CIOs and/or security coordinators notify agency personnel about the alert to raise awareness and reduce the number of help desk calls. When possible, alert notifications are sent by e-mail, and based on the content, determination should be made whether to distribute to “Agency All,” specific divisions within the agency, or only to specific individuals. Security coordinators report any local incidents to the CRT and work with team members to contain and recover from incidents.

Help Desk Responsibilities—As problems are reported by users, data is collected and communicated to the CRT for determination of incident level and response required. Incident status/response progress must be tracked for communication to any affected customers who call. The help desk can also act as a valuable out-of-band communication source for the CRT, depending on the particulars of the incident.

Phases of Response

  • Alert Phase—The alert phase is the process of learning about a (potential) security incident and reporting it to the CRT. Alerts may arrive from a variety of sources, including firewalls, intrusion detection systems, antivirus software, threats received via electronic mail, and media reports about a new threat. Many of these alerts will be processed by the CRT Incident Analysts and will be presented as requests for response, requiring triage.

    When incident notification is phoned in by an agency to a central help desk, on-duty help desk personnel complete the request for response and notify the Incident Manager. The Incident Manager then responds directly to the contact at the compromised agency.
  • Triage Phase—The request for response, with all available information about the incident, gets processed by the Incident Manager to determine whether a real incident exists. A severity level is assigned.

    If the incident’s severity warrants Level 4 or 5, (see Levels of Incidents, in this section), the CRT will also notify all other concerned parties in the agency/community. The CRT Manager, while collaborating with all concerned parties, must accomplish two important tasks in this phase:
    • Decide whether to “pursue” or “protect.” In other words, decide whether the community will attempt to catch the perpetrator(s) of the attack for later criminal or civil action or whether it simply wants to stop the incident and restore normal operations. This decision must be made before the response begins, because it influences how the response will be undertaken.
    • Allocate resources and authority (personnel and financial) to the response and recovery teams at a level commensurate with the severity of the incident.
  • Response Phase—CRT response engineers then gather evidence (audit trails, log files, and contents of files). If the “pursue” option was chosen in the triage phase, this process will be performed in a forensically sound manner so that the evidence will be admissible in court. The team may need specialized technical assistance and advice from a third party.

    Once evidence has been gathered, it is analyzed to determine the cause of the incident and the vulnerability or vulnerabilities being exploited. An assessment is also made of how far the incident has spread (i.e., which systems are involved and how badly they have been compromised). The CRT then determines the most effective methods to stop the incident and/or eliminate the vulnerabilities.
  • Recovery Phase—The recovery phase can overlap with the response phase as the CRT response engineers begin to actually restore the systems affected by the incident to normal operation, working with agency security personnel. This may require reloading data from backup tapes, reinstalling systems from their original distribution media, or commencing alternate-site operations. Once the affected systems have been restored, they are tested to make sure they are no longer vulnerable to the attack(s) that caused the incident. They are also tested to make sure they will function correctly when placed back into production.
  • Maintenance Phase—To develop “lessons learned,” the CRT reviews the incident, as well as the response, to determine which parts of the incident response plan worked correctly and which parts need improvement. The areas needing improvement are then corrected, and the plan is updated and communicated accordingly. Other areas that need to be changed (policies, system configurations, etc.) may also be identified during this phase.

Levels of Incidents—Table 2-6 describes sample criteria that could be used to classify a security incident level and suggests accompanying responses in the incident response plan. (Actual definitions and levels of response have to be negotiated among community members.)

Table 2-6: Security Incident Levels and Responses
Incident Level Response
   1    Small numbers of system probes or scans detected on internal systems; isolated instances of known computer viruses. Easily handled by installed antivirus software.
2 Small numbers of system probes or scans detected on external systems; intelligence received concerning threats to which systems may be vulnerable. Communicate potential risk to security coordinators, CIOs, and help desk contacts and remind about installing latest patches and virus signatures.
3 Significant numbers of system probes or scans detected; penetration or denial-of-service attacks attempted with no impact on operations; widespread instances of known computer viruses easily handled by antivirus software; isolated instances of a new computer virus not handled by antivirus software. CRT must allocate available resources to monitoring and communicating to prevent damage.
4 Penetration or denial-of-service attacks attempted with limited impact on operations; widespread instances of a new computer virus not handled by antivirus software; some risk of negative financial or public relations impact. CRT takes action, in coordination with system administrator(s) affected, to prevent more widespread damage.
5 Successful penetration or denial-of-service attacks detected with significant impact on operations; significant risk of negative financial or public relations impact. CRT notifies business leadership, authorized action initiated, all available resources allocated at CRT and affected agency(ies).

Central Response Team (CRT) Roles and Responsibilities—The CRT consists of the Manager, Incident Manager(s) (depending on size of community), Incident Analysts, and Response Engineers. Their suggested roles and responsibilities are as follows:

  • CRT Manager—The CRT Manager oversees the operation of the CRT and provides communication and coordination functions at the highest level, including notification of incidents, their severity, and the status to various officials, agency leaders, organizations, and committees. Immediately upon discovery of a Level 4 or 5 incident, the CRT Manager receives a full briefing from the Incident Manager. Only the CRT Manager has the authority to approve disconnection or quarantine of a community member agency in response to an incident. The CRT Manager assists with decisions to pursue legal action by coordinating with the appropriate legal authorities when necessary.
  • Incident Manager—The Incident Manager manages the overall response and recovery activities for all security incidents, deciding the severity level of each incident and assigning staff members to perform response and recovery tasks accordingly. Additionally, the Incident Manager consults with the victim agency regarding the decision to pursue legal action and gather evidence or quickly react to protect the affected systems and return operations to normal as quickly as possible. When disconnection authority has been granted by the CRT Manager, the Incident Manager informs the victim agency of the recommendation to shut down or disconnect all affected systems from the network.
  • Incident Analysts—Incident Analysts are responsible for the 24-hour-a-day/7-day-a-week monitoring of Intrusion Detection System data. They process requests for response from monitored data and directly from the central help desk and member agencies. A request for response may be submitted by the on-duty Incident Analysts before the victim agency is even aware of the incident. When a request for response is processed and completed, the Incident Analyst sends it to the Incident Manager for a severity-level designation and Response Engineer assignment. Incident Analysts may also perform trend analysis and other proactive duties as assigned by the Incident Manager.
  • Response Engineers—The Response Engineer functions represent the core of the central response and recovery efforts. Being highly skilled in the technical details of IT security, Response Engineers perform the initial incident response; collect and gather evidence for forensics; assist with incident policy development and incident response education; and perform postincident compliance, restoration, and vulnerability testing. Based on skill levels, Response Engineers are assigned specific incident response tasks by the Incident Manager and may be assigned other proactive duties as seen necessary by the Incident Manager.

Reference

One sample standard can be found on Arizona’s State Web page. Arizona’s standards document, P800-S855, Incident Response and Reporting Standard, provides a sample for a working, multiagency program, including a CRT membership application. It is available at http://azgita.gov/policies_standards/
html/ p800_s855_incident_resp.htm.