Skip to main content

Prepare for Incident Response

Learning Objectives

After completing this unit, you’ll be able to:

  • Explain how to create an incident response strategy.
  • List the cyber incident categories.
  • Identify the members of an incident response team.

Create an Incident Response Strategy

Cyberattacks are increasing in frequency, scale, and sophistication, and incident response plans play an important role in an organization’s information security defense. As an incident responder, your first task is to be prepared so that you can recover more quickly while minimizing the impact of an attack. Ultimately, establishing a strong incident response can instill confidence in your customers and limit reputational harm in the event of a cyberattack.

Conduct a Risk Assessment

To create an incident response strategy, you first work with your cyber risk management team to conduct a risk assessment of your organization. You inventory your assets, especially critical ones such as important business networks, key systems, and confidential data. You determine the business impact, and focus on the type of harm that would come about should these assets become compromised in any way (confidentiality, integrity, or availability). This harm could include financial loss, reputational harm, and compliance scores.

Note

Confidentiality, integrity, and availability, also known as the CIA triad, is a model designed to guide policies for information security within an organization. In this context, confidentiality is a set of rules that limits access to information, integrity is the assurance that the information is trustworthy and accurate, and availability is a guarantee of reliable access to the information by authorized people. 

Analyze Threats

As an incident responder, you have a key role to play in creating an incident response plan by understanding and analyzing threats against your assets and networks. By defining incident and event types you can determine the threats associated with them—for example, malware and phishing.

To contextualize the threats, you must understand your organization’s business and risk appetite as well as any dependencies for business execution. You determine which networks or systems are most likely to be targeted, by whom, and the dependent computing systems that support them. Once you determine the relevant threats, you implement a level of protection via security controls. 

Define the Incident Response Strategy

Once you’ve conducted a risk assessment and analyzed relevant threats, next up is establishing an event detection and reporting process. You start by defining an event for your organization—for example, any observable occurrence in a network or system. For each type of event, you identify methods of detection and notification within your organization. 

One method of detection is internal monitoring of your infrastructure (network architecture and network traffic) via tools such as firewalls, intrusion detection or prevention systems (IDS/IPS), and packet inspection services. You also monitor users who access your systems and data, as well as environmental services such as weather to ensure your data centers are secure from geographical events. You may create a detection rule to alert a responder when a single event occurs, like when a user attempts to authenticate from a country in which your business doesn’t operate; or by correlating multiple events, like when both cases are true. For example, there are five failed login attempts for a given user in under three minutes and the user is on a VIP user list.

It’s also a good idea to subscribe to external notifications from law enforcement, third-party threat intelligence providers, and emergency response teams such as the United States Computer Emergency Readiness Team (US-CERT). As part of your incident response preparation, you document how to report issues to the service desk (for example, through a ticketing system, email, or supervisor). You can also catalog the tools and resources available for incident response, and put in place an incident communication strategy. 

Incident Response Communication

The incident communication strategy should document how you will communicate with the incident response team (IRT) members and other outside parties. It includes name and contact information such as phone numbers and emails. It also describes how to—and who to—escalate up to (with contact details) should the need arise. These escalation notifications should be required in a certain amount of time. 

Parties listed in the escalation procedure can include the IRT team lead, business and system owners, managed service providers, and others. The communication strategy should also list tools used to report suspected incidents such as online forms or secure messaging. It should provide for on-call phones for the IRT, including information on who the service provider is and any service level agreements (SLAs) with the provider. 

Incident Response Collaboration

The incident response strategy should also provide for a location for centralized communication and collaboration (often called a war room). It should describe how and where sensitive data will be stored as well as access requirements. It should also provide forensic workstations and backup devices, IRT laptops, and spare resources for restoring backups and sandboxing malware, and so on. 

It should detail any necessary incident response software such as packet sniffers, forensic software, and protocol analyzers. It should also include provisions for evidence-gathering accessories such as cameras, notebooks, chain of custody forms, and removable media. A jump kit often contains most of the above items.

Incident Response Documentation

Finally, the strategy should also include documentation of the systems, services, and networks, such as architecture diagrams and current operating system baselines. It should detail planned mitigation strategies, and steps on how to access clean copies (images) of operating systems and networks for restoration and recovery of operations. 

A briefcase with gears housing a laptop, cell phone, camera, document with a checklist, notebook with an architecture diagram, and a thumb drive.

Cybersecurity Incident Categories

Your cybersecurity incident response plan should include details about how to best respond to different categories of incidents. There are several types of incidents outside of cyber incidents that occur regularly. For the purpose of this trail, we focus solely on cyber incidents, which may also be called security breaches, security incidents, or security events. Here are some examples of security incidents that can result in an intrusion on the organization’s networks or systems.

Category

Definition

Unauthorized attempts to access data or a system

An attacker tries to gain unauthorized access to a specific system or organizational data.

Insider Threat

Employees, former employees, contractors, or temporary workers are responsible for a malicious threat to the organizational data, system, or network.

Phishing Attacks

Malicious actors masquerade as a reputable entity in an email or other communication channel.

Man-in-the-Middle (MitM) Attacks

An attacker tries to secretly intercept and alter the messages between two parties who are under the assumption that they’re directly communicating with each other. The attacker manipulates both parties to get access to the data.

Ransomware

An attacker tries to infect systems and encrypt files so that data is inaccessible until a ransom is paid in exchange for a decryption key.

Other types of attacks include spoofing, theft, and improper usage of information technology resources, to name a few.

Members of the IRT

IRTs investigate incidents by analyzing information. They also suggest the best response mitigation and report to and communicate with stakeholders. And they help recommend long-term improvements to prevent incidents from reoccurrence. Their goal is to coordinate and align resources and team members during an incident to minimize impact and restore operations as soon as possible. 

An IRT typically consists of incident managers and incident responders. These roles are dedicated to incident response and are focused daily on incident investigation, analysis, and response. They are often responding to several, perhaps many, ongoing incidents and investigations simultaneously. 

For a particular incident, the core IRT will engage with many stakeholders that are in some way related to the given incident. These may be system owners for impacted assets, product owners, or legal representatives. Other common stakeholders invited to participate in the response process include but may not be limited to:

  • Senior/executive management to make critical decisions
  • Incident manager to track IRT actions and to document, communicate, and escalate the incident
  • Customer service representatives to write and sending internal and external communications about the incident
  • Human resources (HR) and legal representatives to provide advice as to how best to handle situations involving employees or legal repercussions
  • Public relations/affairs representatives to update external parties on the status of the incident response
  • IT analysts, investigators, responders, and infrastructure representatives to explore, contain, and remediate the incident

An IRT should be available to respond to anyone who discovers or suspects that an incident involving the organization has occurred. These roles can be internal, external, or hybrid. The team members should have diverse skills and be available to support 24/7 during the incident response if the incident severity warrants such a response.

There are several models for an IRT that you can implement: 

  • Centralized: A single team handles all of an organization’s incidents. This model is best for small organizations or those limited to a single geographic area.
  • Distributed: Multiple IRTs each cover a specific environment or physical location. This is effective for large organizations or those with geographically dispersed locations.
  • Coordinated: An IRT provides advice to other teams without having authority over those teams. For example, a government department-wide team may assist individual agencies’ teams.

IRTs can be staffed by employees, partially outsourced, or fully outsourced. In a partially outsourced team, the organization outsources portions of the incident work. For example, the internal organization has coverage during working hours while the outsourced entity covers after-hours. In a fully outsourced team, the organization completely outsources all incident response work to a managed service provider. When choosing which model is best, an organization should factor in the need for availability, the decision of whether the IRT should be full-time, part-time or as needed, cost, and staffing expertise.

Now that you understand more about how to prepare for incident response, let’s turn next to how you identify and contain an incident when it occurs. 

Resources

Comparta sus comentarios de Trailhead en la Ayuda de Salesforce.

Nos encantaría saber más sobre su experiencia con Trailhead. Ahora puede acceder al nuevo formulario de comentarios en cualquier momento en el sitio de Ayuda de Salesforce.

Más información Continuar a Compartir comentarios