See Cynet’s Autonomous
Breach Protection in Action

Prefer a one-on-one demo? Click here

Incident Response

The Cynet 360 platform is the world’s fastest IR tool and includes automated attack detection and remediation

Learn More

What Is Incident Response?

Incident response (IR) is a set of policies and procedures that you can use to identify, contain, and eliminate cyberattacks. The goal of incident response is to enable an organization to quickly detect and halt attacks, minimizing damage and preventing future attacks of the same type.

In this page you will get an in-depth understanding of incident response processes, people and tools:

Incident Response Steps: 6 Phases of the Incident Response Lifecycle

There are six steps to incident response. These six steps occur in a cycle each time an incident occurs. The steps are:

  1. Preparation of systems and procedures 
  2. Identification of incidents
  3. Containment of attackers and incident activity
  4. Eradication of attackers and re-entry options
  5. Recovery from incidents, including restoration of systems
  6. Lessons learned and application of feedback to the next round of preparation

Preparation

During your first preparation phase, you review existing security measures and policies to determine effectiveness. This involves performing a risk assessment to determine what vulnerabilities currently exist and the priority of your assets. Information is then applied to prioritizing responses for incident types. It is also used, if possible, to reconfigure systems to cover vulnerabilities and focus protection on high-priority assets.

This phase is where you refine existing policies and procedures or write new ones if you are lacking. These procedures include a communication plan and assignment of roles and responsibilities during an incident.

Identification of threats 

Using the tools and procedures determined in the preparation phase, teams work to detect and identify any suspicious activity. When an incident is detected, team members need to work to identify the nature of the attack, its source, and the goals of the attacker.

During identification, any evidence collected needs to be protected and retained for later in-depth analysis. Responders should document all steps taken and evidence found, including all details. This can help you more effectively prosecute if an attacker is identified.

During this phase, after an incident is confirmed, communication plans are also typically initiated. These plans inform security members, stakeholders, authorities, legal counsel, and eventually users of the incident and what steps need to be taken.

Containment of threats

After an incident is identified, containment methods are determined and enacted. The goal is to advance to this stage as quickly as possible to minimize the amount of damage caused.

Containment is often accomplished in sub-phases:

  • Short term containment—immediate threats are isolated in place. For example, the area of your network that an attacker is currently in may be segmented off. Or, a server that is infected may be taken offline and traffic redirected to a failover.
  • Long term containment—additional access controls are applied to unaffected systems. Meanwhile, clean, patched versions of systems and resources are created and prepared for the recovery phase.

Elimination of threats

During and after containment, the full extent of an attack is made visible. Once teams are aware of all affected systems and resources, they can begin ejecting attackers and eliminating malware from systems. This phase continues until all traces of the attack are removed. In some cases, this may require taking systems off-line so assets can be replaced with clean versions in recovery.

Recovery and restoration

In this phase, teams bring updated replacement systems online. Ideally, systems can be restored without loss of data but this isn’t always possible.

In the latter case, teams must determine when the last clean copy of data was created and restore from it. The recovery phase typically extends for a while as it also includes monitoring systems for a while after an incident to ensure that attackers don’t return.

Feedback and refinement

The lessons learned phase is one in which your team reviews what steps were taken during a response. Members should address what went well, what didn’t, and make suggestions for future improvements. Any incomplete documentation should also be wrapped up in this phase.

What Is an Incident Response Plan (IRP)?

An IRP is a set of documented procedures detailing the steps that should be taken in each phase of incident response. It should include guidelines for roles and responsibilities, communication plans, and standardized response protocols.

Within your IRP it is important to use clear language and define any ambiguous terms. One set of terms that are frequently confused is event, alert, and incident. When using these terms in your plan, it can help to restrict use as follows:

  • Event—a change in system settings, status, or communication. Examples include server requests, permissions update, or the deletion of data.
  • Alert—a notification triggered by an event. Alerts can warn of suspicious events or of normal events that need your attention. For example,the use of an unused port vs storage resources running low.
  • Incident—an event that puts your system at risk. For example, theft of credentials or installation of malware.

Learn more in our in-depth guide about incident response planning.

Incident Response Plan Templates

Instead of building your IRP from scratch, you can save time by starting from an IRP template. The following templates are free and are good options to consider.

Provider# of PagesKey ContentDownload Link
TechTarget / Paul Kirvan14
  • Plan guidelines and planning scenarios
  • Suggested actions and activities
  • Notification, escalation and communication processes
  • IR checklists
  • IR documentation forms
.DOC file
International Legal Technology Association (IltaNet)5
  • IR team guide with employee responsibilities
  • IR notifications
  • Classification procedures for incidents
  • Response and recovery procedures
  • Plans for periodic testing and remediation
.ASHX file
Thycotic19
  • Team roles and responsibilities
  • Incident classification guidelines
  • Legal and compliance and guidelines
  • Phases and steps to be taken
.DOC file

(requires registration)

Sysnet11
  • Detection guidelines
  • Roles and responsibilities
  • External contact information
  • IR steps
  • Specific IR types
  • Auditing and improvement guidelines
.DOC file

(requires registration)

California Government Department of Technology4
  • 17-step IR procedure
  • Type-specific guidelines
.DOC file
I-Sight6
  • Plan purpose and scope
  • Incident definitions and examples
  • Team responsibilities and roles
  • IR stages and procedures
.DOC file

(requires registration)

Learn more in our in-depth guide about incident response templates.

Incident Response Frameworks

Incident response frameworks are developed to help organizations create standardized response plans. These frameworks are typically developed by large organizations with a significant amount of security expertise and experience. Two of the best known of these frameworks are those developed by NIST and SANS.

The NIST Incident Response Framework

The National Institute of Standards and Technology (NIST) is a U.S. government agency dedicated to advancements in technology. As part of their cybersecurity efforts, they developed the NIST incident response framework. This framework is comprehensive, including details of how to create an IRP, an incident response team, a communication plan, and training scenarios.

This framework has four official steps which condense the 6 phases of incident response into the following:

  1. Preparation
  2. Detection and Analysis
  3. Containment, Eradication, and Recovery
  4. Post-Incident Activity

The reason for this condensation is that NIST believes that containment, eradication, and recovery are all overlapping phases. For example, as you contain threats within your systems, you should not wait to eradicate issues until all threats are found. Rather, you should contain and eliminate threats as soon as possible, even if other threats remain.

Likewise, recovery is not a strict step, rather a process that depends on the priority and content of the assets being recovered. For example, you may choose to hold off on recovering high priority assets until an attack is fully eliminated to keep your data more secure.

Learn more in our in-depth guide about NIST Incident Response.

The SANS Incident Response Framework

SysAdmin, Audit, Network, and Security (SANS) is a private organization that works to cooperatively research and educate the public on security issues. One of their major contributions to cybersecurity is the SANS incident response framework.

The SANS framework includes the six phases individually, calling the phases:

  1. Preparation
  2. Identification
  3. Containment
  4. Eradication
  5. Recovery
  6. Lessons Learned

Inside the SANS framework, are basic descriptions of the phases. SANS also includes an IR checklist for each phase and two templates with useful system commands for the preparation and identification phases. These templates are available for Windows and UNIX systems.

Learn more in our in-depth guide about Incident Response SANS.

What is an Incident Response Team?

An incident response team is a team responsible for enacting your IRP. This team is sometimes also referred to as a computer security incident response team (CSIRT), cyber incident response team (CIRT), or a computer emergency response team (CERT).

The key duties of your CSIRT are to prevent, manage, and respond to security incidents. This can involve researching threats, developing policies and procedures, and training end users in cybersecurity best practices.

Building a CSIRT in Your Organization

How well you build your CSIRT plays a major role in how effective your incident response efforts are. If you are unable to fill all of the necessary roles and responsibilities, your response will have gaps that can lead to more damage and longer attacks. To avoid this, you should consider developing your team with the help of the NIST guidelines.

Incident Response Team Models

According to the NIST framework, there are three different models of CSIRT you can apply:

  • Central—the team consists of a centralized body that manages IR for the whole organization.
  • Distributed—multiple teams exist and coordinate efforts as needed. Typically, each team is responsible for a specific part of the IT infrastructure, physical location, or department.
  • Coordinated—a central team serves as a command center or knowledge base for distributed teams. Central teams often take care of system monitoring and can alert and assist distributed teams as needed. 

Selecting a Team Model

Knowing which model is best for your organization can be a challenge. To help you decide, you can again refer to the NIST guidelines which provide some considerations to help:

  • What availability do you need?—you need to decide whether you want to have 24/7 response availability and what level of availability. For example, is it enough that teams can respond remotely or do they need to be on-site. Preferably your team is available in real-time and in-person.
  • What level of staffing do you want?—you should decide whether you want full-time staff dedicated to your team or whether shifts of part-time staff are sufficient. Part-time staff are best for boosting team response during an incident. Full-time staff are best for ensuring that your response is organized, consistent, and immediate.
  • How much expertise is needed?—the more expertise you have on your team, the more effective it can be. However, many organizations do not have a high level of security expertise in-house. If this is the case, you may want to have external experts available to assist your in-house team during response activities.
  • What is your budget?—your IR budget plays a large role in limiting the above aspects. When putting your team together, you need to be realistic about the budget that is needed and how money is best allocated.

What are Incident Response Services?

Incident response (IR) services are managed services that can replace or supplement in-house teams. These services usually work on retainer with a monthly cost and a set range of services. The benefit of these services is that they typically offer a higher level of expertise than is available in-house and can provide 24/7 monitoring and response. This service usually includes a service level agreement (SLA) ensuring confidentiality and response.

Additional benefits of managed services include:

  • Incident response preparation and planning—services can help you review IT systems and develop IRPs suited to your specific needs.
  • Incident triage and classification—services can monitor for security events, identify incidents, and classify threats.
  • Initial response—services can perform initial response steps or even come on-site to assist in-house responders.
  • Post-breach assessment—services can help teams perform root-cause analyses and provide evaluations of response efforts and effectiveness.

Learn more in our in-depth guide about incident response services.

Need an incident response provider?

Cynet is a trusted partner that analyses network and endpoint data, raises alerts, and protects against a wide range of known and zero-day threats. Cynet provides CyOps, an outsourced incident response team on call 24/7/365 to respond to critical incidents quickly and effectively. Cynet can deploy its powerful endpoint detection and response (EDR) system across thousands of endpoints in up to two hours to effectively mitigate threats across an enterprise.

Incident Response Automation

Effective incident response is time-sensitive and relies on teams quickly identifying threats and initiating IRPs. Unfortunately, most teams are not capable of investing all alerts in real-time to determine if something is an incident. This can lead to incidents being missed entirely or only being caught after significant damage has occurred.

Automating parts of your incident response can help avoid this oversight or delay. It can be used to:

  • Quickly triage alerts and identify incidents
  • Compile and centralize relevant data for incident investigations
  • Perform incident response tasks and processes, such as isolating affected areas or blocking IP addresses

Incident Response Playbooks

When automating IR, a common method you can use is to create playbooks. Playbooks are essentially scripts that team members or security solutions can follow or initiate. These scripts define response steps to be taken and instruct responders, systems, or solutions to perform the defined actions.

Playbooks can be used for:

  • Manual incident response processes—playbooks define steps to be taken, including which tools should be used, which processes performed, and who is responsible for performing those actions. These playbooks can be printed or electronic and are generally specific to incident type.
  • Automated incident response processes—playbooks are programmatic scripts that integrate with relevant systems and tools. When alerts are triggered or incidents are identified, the system or tool can initiate the script, automatically performing the predefined actions.

If you have manual playbooks, you can often easily transform the contained steps into automated processes. Depending on the programming knowledge of your responders, you can also use automation playbooks as backup manual playbooks as needed.

How to create an incident response playbook

When creating an incident response playbook, it should contain the following components:

  • Initiating condition—the event that triggers the playbook to run. This can be an alert, an incident identification threshold, or some other event.
  • Mandatory steps—the actual steps and processes to be taken. These typically include triage, analysis, containment, and removal actions.
  • End state—the terminating event for the playbook. This is defined by your playbook goal. For example, resetting passwords and permissions.

Learn more in our in-depth guide about incident response playbooks.

Incident Response Platforms

In addition to playbooks, you can also employ IR platforms. These platforms are software that you can use to guide, assist, and automate your response efforts. Platforms are often comprehensive and can integrate with your existing systems.

Common features of IR platforms include:

Analyst supportIntelligence and analyticsSecurity automation
  • Knowledgebase of regulations, response plans, and contacts
  • Automatic escalation and assignment of alerts
  • SLA tracking
  • Compliance and breach reporting
  • Integration with SIEMs and other monitoring tools
  • Analysis and correlation of event timelines
  • Real-time analysis of attack behaviors
  • Forensic data retention and querying
  • Pre-configured IR playbooks
  • Support for customizable playbooks
  • Automatic isolation compromised systems or user accounts
  • Automatic remediation

Learn more in our in-depth guide about incident response platforms.

Automated Incident Response With Cynet 360

Cynet provides a holistic solution for cybersecurity, including the Cynet Response Orchestration which can automate your incident response policy. Users can define automated playbooks, with pre-set or custom remediation actions for multiple attack scenarios. Cynet automated playbooks also help detect threats to ensure that you only implement a manual response when it is necessary.

Cynet Response Orchestration can address any threat that involves infected endpoints, malicious processes or files, attacker-controlled network traffic, or compromised user accounts.

Learn more about Cynet Response Orchestration.

Learn More About Incident Response

There’s a lot more to learn about incident response. To continue your research, take a look at the rest of our blogs on this topic:

Incident Response Process: How to Build a Response Cycle the SANS Way

The incident response process is a set of steps performed by incident response teams to prevent, detect, and mitigate security incidents. It is a recurring process that is improved with each cycle by feedback and a review of any actions taken. There may be a differing number of steps, depending on the specific process you’re using, but all processes manage the same tasks and responsibilities.

Read more: Incident Response Process: How to Build a Response Cycle the SANS Way

Incident Response Team: A Blueprint for Success

An incident response team is responsible for planning and responding to security incidents such as cyber-attacks, data breaches, and systems failures. These teams are also responsible for creating incident response plans, enforcing security policies, searching for and resolving system vulnerabilities, and evaluating security best practices. This article explains how to create effective incident response teams, and reviews the main incident response roles, and what is the difference between CERT, CSIRT, and SOC units.

Read more: Incident Response Team: A Blueprint for Success

Incident Response Template: Presenting Incident Response Activity to Management

Incident response teams need a way to easily communicate the details of a security incident to management, taking into consideration that they are not security professionals. This article provides a useful template with tables you can copy and paste into your incident response reports or presentations to management. This template will help them understand what happened in an incident, how your team responded, what remains to be done, and lessons learned.

Read more: Incident Response Template: Presenting Incident Response Activity to Management

Incident Response SANS: The 6 Steps in Depth

The SANS Institute is a private organization established in 1989, which offers research and education on information security. The SANS Institute published a 20-page handbook that outlines a structured 6-step plan for incident response. This article reviews the steps in the SANS incident response process, including preparation, identification, containment, and eradication.

Read more: Incident Response SANS: The 6 Steps in Depth

Upgrading Cybersecurity with Incident Response Playbooks

An incident response plan is a documented, systematic process that defines how your organization should deal with a cybersecurity incident. To keep your incident response plan simple, you need to ensure that your team can understand it and take the required actions under the pressure of an actual cyberattack. Therefore, many teams add incident response playbooks for specific incident scenarios.

Read more: Upgrading Cybersecurity with Incident Response Playbooks

6 Incident Response Plan Templates and Why You Should Automate Your Incident Response

It is much easier to start building your incident response plan with a template. You can remove parts that are less relevant for your organization, and fill in your details and processes. This article provides summaries and direct links to six comprehensive plan templates. You can download for free some of these templates, which can give you a head start.

Read more: 6 Incident Response Plan Templates and Why You Should Automate Your Incident Response

NIST Incident Response

The National Institute of Standards and Technology (NIST) is an agency operated by the USA Department of Commerce, that provides standards and recommendations for many technology sectors. The Information Technology Laboratory (ITL) department within NIST,  is responsible for developing standards and measurement methods for IT information security.

The NIST incident response guide provides in-depth guidelines on how to build an incident response capability within an organization. The guide covers several models for incident response teams, how to select the best method, and best practices for operating the team.

Read more: NIST Incident Response

Incident Response Plan

A solid incident response process can significantly reduce the damage caused to an organization in case of an incident. An incident response plan helps distribute the incident response plan across the organization. The distribution of the plan enables all relevant stakeholders to understand and agree to the plan. They will be ready to coordinate efforts around that plan when an attack occurs. These stakeholders usually include security teams, operations, legal, and executive management, but may include others such as development teams, PR, partners and customers.

Read more: Incident Response Plan

See Our Additional Guides on Key Security Topics

We have authored in-depth guides on several other security topics that can also be useful as you explore the world of incident response.

EDR Guide

EDR is a set of tools and practices that you can use to detect and respond to security attacks on your network. EDR defends endpoint devices, including workstations, smart devices, routers, and open ports.

See top articles in our endpoint security guide:

Endpoint Security Guide

Endpoint security is a strategy designed to protect your network perimeter and the endpoints located on that perimeter.

See top articles in our endpoint security guide:

Advanced Threat Protection Guide

Advanced threat protection (ATP) is a set of solutions and practices you can use to detect and prevent advanced attacks or malware. Typically, ATP solutions include a combination of malware protection systems, network devices, endpoint agents, email gateways, and a centralized management dashboard.

See top articles in our advanced threat protection guide:

Network Attacks Guide

A network attack is an attempt to gain unauthorized access to an organization’s network, with the objective of stealing data or perform other malicious activity. Once inside, hackers will combine other types of attacks, for instance compromising an endpoint, spreading malware or exploiting a vulnerability in a system within the network.

See top articles in our network attacks guide:

Incident Response Services Guide

Incident response services can help you detect and respond to cyber-attacks. These services generally operate based on an incident response retainer that specifies a fixed monthly cost and a certain scope of security services.

See top articles in our incident response services guide:

Dive In

Ebook Free Download

Securing Your Organization’s Network on a Shoestring

How to protect your resource-constrained organization’s endpoints, networks, files and users without going bankrupt or losing sleep.

DOWNLOAD NOW
Ebook Free Download

Securing Your Organization’s Network on a Shoestring

How to protect your resource-constrained organization’s endpoints, networks, files and users without going bankrupt or losing sleep.

DOWNLOAD NOW
SOLUTION BRIEF

Automated Threat Discovery & Mitigation

Secure your all organizational assets with a single platform. Cynet 360 protects across all threat vectors, across all attack stages.

DOWNLOAD NOW
SOLUTION BRIEF

Automated Threat Discovery & Mitigation

Secure your all organizational assets with a single platform. Cynet 360 protects across all threat vectors, across all attack stages.

DOWNLOAD NOW
FREE TRIAL

Deploy Cynet in Minutes and Try it for 14 Days

Try Cynet’s easy-to-launch prevention, detection and response platform across your entire organization - free for 14 days!

START YOUR TRIAL