What Is Incident Response?

Introduction

As cyber attacks increase in quantity and diversity and more and more security breaches disrupt the operations of organizations, incident response (IR) has become an indispensable component of cyber security programs. Organizations can implement preventive security controls as a result of cyber security risk assessment evaluations. However, such efforts can not eliminate all possible threats to IT systems and only help to reduce the number of security breaches and violations. Thus, it is necessary for organizations to plan for IR and act accordingly with established IR teams.

What Is an Incident?

Before defining and discussing what incident response (IR) is, some related and fundamental terms such as event, alert and incident should be explained first for a proper discussion of the topic.

Examples are access or connection requests, file or data updates or deletions, user/password creations or updates etc.

Examples include failed logon attempts, usage of resources (CPU, memory, network etc) above defined thresholds, denied access requests etc.

In this respect, what might be an incident for an organization might not be an event of interest for another depending on the security policies. General incident examples might include the following:

• Phishing attacks to trick users to reveal secrets or install malicious code via email attachments.
• Remote code execution attacks taking advantage of buffer-over-flow vulnerabilities on the operating systems or applications.
• Distributed denial of service (DDoS) attacks against critical network devices or servers.
• SQL-injection attacks to compromise sensitive data from a database.
• Malware such as a ransomware that has encrypted critical files on the infected systems.
• Lost or found removal media around the perimeters of the organization etc.

What Is Incident Response?

The goal of IR is to detect incidents as early as possible, minimize the damage incurred, restore the systems back to their original functionality and prevent future attacks of the same or similar type. In order to achieve these goals and hadle incidents efficiently and effectively, an IR capability should be prepared and tested in advance to guide incidents handlers at times of security incidents.

As described in NIST Computer Security Incident Handling Guide (SP 800-61 Rev 2), an IR capability should be comprised of the following:

• IR policy and plan.
• Procedures for incident handling and reporting.
• Establishment of an IR team and determining the roles, responsibilities and services expected of the team.
• Guideliness for communicating with internal and outside parties regarding incidents.

Incident Response Phases

As described in the definition, IR is a well-defined methodology for handling unwanted events, a.k.a. incidents. Currently, there exist two similar frameworks that describe the IR process in a structured way: the SANS and NIST frameworks. The only major difference between these two is that what NIST framework considers as a single phase (Containment, Eradication & Recovery) is defined as three separate steps in the SANS framework. Taking the SANS framework approach, we explain IR process in the following 6 phases.

1. Preparation

The first and probably the most important phase of an IR process is the preparation. This initial phase involves actions such as the establishment of an IR team structure, staffing & training the team and provisioning the required equipment & tools for handling the incidents properly. This team is usually called or known as Computer Security Incident Response Team (CSIRT). This stage also entails the refinement or preparation of the essential IR documents such as IR policy, IR plan and IR procedures.

2. Identification (Detection & Analysis)

This phase deals with the challenging task of detecting deviations from the normal operations and identifying true incidents. For this purpose, outlier events that violate any computer security policies, acceptable use policies or security standards are analyzed further to eliminate the false positives and determine the real incidents.

For detecting the incidents, a number of sources such as the following could be employed:

• Alerts: Alerts from Intrusion Detection and Prevention Systems (IDPSs), Security Information and Event Management Systems (SIEMs), antivirus software, file integrity checking software or other monitoring software.
• Logs: Operating system, service and application logs, network device logs, network flows etc.
• Threat and Vulnerability Reports: Information on new vulnerabilities and exploits or information on threat tactics and techniques.
• People: User reports such as unusual behavior on the systems or recent incident information shared by people from other organizations.

During this phase, it is also critical that the identified incidents be prioritized based on the relevant factors, such as the following:

• Functional impact of the incident: Negative impact of the incident on the business functionality is determined.
• Information impact of the incident: Effect on the confidentiality, integrity and availability of the organization’s information is calculated.
• Recoverability from the incident: The amount of time and resources required for recovering from the incident is estimated.

At this stage, CSIRT members should be notified and communication with the other parties should be established according the IR plan. Also, starting from this phase all the activities conducted should be recorded and documented to answer the Who, What, Where, Why and How questions in case the issue is brought to a court of law for prosecution.

You can’t defend. You can’t prevent. The only thing you can do is detect and respond.

Bruce Schneier

Read more educational and inspirational cyber quotes at our page 100+ Best Cyber Security & Hacker Quotes.

3. Containment

This phase aims to limit the damage as soon as possible and prevent any further damage to the systems. For this purpose, numerous actions can be taken based on the type of incident. Partial or total isolation of a host from the network, powering off a terminal or limiting the functionality of a device could be given as examples of general incident containment strategies. However, note that simply isolating a system from the network may not necessarily mean additional damage on the infected systems can be prevented. For instance, a malware that notice the containment may start encrypting or deleting the files on an infected host.

At this phase, also a forensic image of the affected system should be taken with tools such as Forensic Tool Kit (FTK), EnCase etc. to prevent damage to any evidence that could be used in legal proceedings.

4. Eradication

This phase deals with the elimination of the malicious activity and prevention of further attacks by improving the security of the affected systems. For this purpose, any malicious content should be removed from the infected systems and patches or updates must be installed to fix vulnerabilities that cause the exploitation. Disabling or uninstalling unused services and applying other hardening practices could also help reduce the number of incidents in the future. Installing clean disk images or restoring systems to previous backups and scanning infected systems with anti-malware could be some eradication strategies that could be taken during this stage.

5. Recovery

At this phase, affected systems are restored back to normal operation, i.e., taken into production environment after successfully remediating or mitigating the existing vulnerabilities. This phase also entails recovery of any data that could be damaged due to the malicious activity or as a result of the actions taken during the eradication phase.

6. Lessons Learned (Post-Incident Activity)

One of the most important but also the most overlooked phase of IR process is the lessons learned. The goal of this phase is to learn from the past incidents and improve the performance of the IR team and provide reference material in the event of similar incidents in the future. As a post-incident activity, all the relevant parties should meet together after major incidents to review the actions taken during the IR process to improve the IR process and prepare for the future incidents of similar type. Lessons learned meetings and records also serve the purpose of educating novice team members by showing them how more experienced or senior members respond to incidents.

As described in NIST SP 800-61 Rev 2, the following questions can be asked in the lessons learned activities.

• What happened and when?
• How well the incident was dealt with?
• What would the team would differently in case a similar activity occurs in the future?
• What precursors and indicators should be watched for detecting similar incidents the next time it happens?
• What additional tools or resources are needed to improve the IR process?
• What preventive control measures can be taken to prevent similar incidents in the future?

Common Attack Vectors

Though incidents could occur in many different ways, they could be categorized in a way so that similar handling procedures could be applied to each incident group. One such category advised in NIST SP 800-61 Rev 2 is as follows:

• External/Removable Media: Attacks launched from removable or peripheral devices. For instance, malware spreading from an infected USB flash drive.
• Attrition: Attacks that use brute force methods to compromise or degrade systems. For instance, compromising passwords from hashes by rainbow attacks or conducting DDoS attacks on a DNS server.
• Web: Attacks that are executed from websites or web-based applications. For instance, directory traversal, XSS or SQL injection attacks.
• Email: Attacks that originate from emails with malicious content. For instance, malware such as ransomware or trojans that spread via an email attachment.
• Impersonation: Attacks that involves spoofing and tampering the communication or data. For instance, man-in-the-middle attacks.
• Improper Usage: Incidents resulting from violation of acceptable use policies or standards fall in this category. For instance, a user installing a software not permitted by the organization or use of personal USB flash drives on the organization’s equipment.
• Loss or Theft of Equipment: Incidents arising from lost or theft of IT equipment. Any found computing equipment also falls in this category.

References

For more detailed information on incident response, you could refer to the following useful resources:

• SANS Institute Incident Handler’s Handbook
• NIST Computer Security Incident Handling Guide (SP 800-61 Rev 2)

You could also read our popular articles What is a Security Vulnerability? or What is Vulnerability Scanning?