Incident response (IR) refers to an organization’s processes and systems for discovering and responding to cybersecurity threats and breaches. The goal of IR is the detection, investigation, and containment of attacks in an organization. Lessons learned from IR activities also inform downstream prevention and mitigation strategies to enhance an organization’s overall security posture.
Cybersecurity incidents are inevitable. Having a robust incident response program can be the difference between sinking and swimming. The frequency, sophistication, and severity of attack methods continue to increase, and it’s crucial for a security operations center (SOC) to have documented and tested responses prepared for the threats they will face.
The IR process helps answer crucial questions about an attack, such as how an attacker got in, what actions they took, and if sensitive information was compromised. Confidently answering these questions will not only improve an organization’s security posture but also help with assessing potential legal or regulatory liabilities.
Additionally, an effective IR strategy can reduce the economic impacts often associated with cybersecurity incidents or breaches. Attack methods like malware outbreaks (including ransomware and spyware), DDoS, and credential theft can be costly and disruptive if an organization is not adequately prepared to respond.
Figure 1: Types of Cybersecurity Incidents
A security incident or event happens when there is a digital or physical breach that compromises the confidentiality, integrity, or availability of an organization’s systems or sensitive data. Security incidents can be perpetrated by hackers or unauthorized users, or through unintentional violations of security policy by company users or business partners in a supply chain.
Common security incidents include:
Ransomware is a criminal business model that uses malicious software to hold valuable files, data, or information for ransom. Victims of a ransomware attack may have their operations severely degraded or shut down entirely. While holding something of value for ransom is not a new concept, ransomware has become a multimillion-dollar criminal business, targeting both individuals and corporations. Due to its low barrier to entry and effectiveness in generating revenue, it has quickly displaced other cybercrime business models and become the largest threat facing organizations today.
According to a survey of Unit 42® Incident Response cases, 89% of the organizations that fell victim to business email compromise (BEC) attacks had failed to turn on MFA or follow email security best practices. Additionally, in 50% of these incident response cases — the organization lacked MFA on key internet-facing systems such as corporate webmail, virtual private network (VPN) solutions, and other remote access solutions.
With so many businesses migrating their workloads to the public cloud, attackers are targeting improperly configured cloud environments, which allow them to gain initial access without needing to find and exploit a vulnerability or make use of sophisticated techniques. It’s no surprise that attackers commonly look for improperly configured cloud environments.
According to a volume of the Unit 42 Cloud Threat Report, identity and access management (IAM) misconfigurations alone contributed to 65% of the observed cloud security incidents.
Agile software development that help organizations speed up development cycles often rely on third-party code to achieve fast results. If an attacker compromises third-party developers or their code repositories, it potentially gives them access to infiltrate thousands of organizations.
It's hard for security teams to keep track of their assets which are constantly shifting, moving, and growing more numerous over time. This means that the unmanaged attack surface continues to grow as the number of unmanaged assets across those surfaces grow too. As a result, attackers are becoming increasingly adept at scanning the internet in search of vulnerable systems and exploiting gaps in security before they can be patched. Low-hanging fruit for attackers include basic security hygiene (e.g., strong passwords, MFA deployment) and zero-day, unpatched vulnerabilities (as seen with SolarWinds and Log4J).
Learn more about responding to incidents in the cloud environment by reading our article, Cloud Incident Response.
The incident response lifecycle is the suggested foundation for how a SOC can prepare and respond to an attack. There are five steps to this lifecycle as identified by Unit 42:
Figure 2: A graphic detailing the Unit 42 Incident Response Methodology
It is considered best practice for all members of the SOC to be familiar with the Incident Response Lifecycle, even though in the event of an attack, there’s a specific team that will be leading the SOC.
An incident response plan (IRP) is a crucial part of the SOC that defines what an incident is and outlines a clear, guided response. IRPs are managed and developed by incident response teams, who should continuously review, test, execute, and update the plan as needed. These plans continue working after an incident or breach has been contained, offering ongoing guidance for proper documentation and downstream activities associated with an incident.
An incident is not just a security problem; it’s a business problem. Losing data, harming employees and customers, or reputational damage are just a few ways that incidents can have detrimental impacts on a business. Having an IRP in place will guide the organization during a crisis and ensure that everyone understands their roles and responsibilities.
An incident response plan is very similar to a disaster recovery plan (DRP), but it focuses on a broad range of cybersecurity threats whereas a DRP focuses on restoring infrastructure, data, and functionality via backups or redundancies. Both aim to minimize the damage to an organization, but where an IRP deals with active threats and breaches, a DRP deals with situations where infrastructure or business processes have been severely impacted.
Even though these documents are similar, it’s still important to maintain them separately; however, it is not uncommon for each document to reference the other. Many organizations will use them in tandem as parts of a larger business continuity plan (BCP). Maintaining a robust IRP with the recommended cybersecurity frameworks will protect the organization in a different way from the DRP.
When creating an IRP, security leaders should understand the short- and long-term requirements of their business. But identifying needs, risks, and vulnerabilities is just the beginning.
It is important when creating a thorough IRP to establish a plan for who maintains it, how to recognize when it activates, organize a communication plan, and identify performance metrics and compliance needs.
There is no one-size-fits-all IRP. Creating one will require security teams to test and edit relentlessly. Here are some additional tips for creating and testing the plan:
If you’re looking for IRP templates or additional guidance, Unit 42 offers an IRP Development and Review service. When you partner with Unit 42, you will create and validate your incident response plan with the help of an expert.
While preparation is undoubtedly an important part of incident response, it is equally crucial that SOCs are able to perform accurately in times of crisis. For moments when they’re unsure of what’s happening, many companies will request incident response services to assist with real-time detection, containment, and eradication.
Dive deeper into incident response plans to discover why they are critical to the successful triage of an incident: What is an Incident Response Plan? Getting Started.
Oftentimes, digital forensics is combined with incident response efforts to create a broader digital forensics and incident response (DFIR) process. Digital forensics specifically collects and investigates data with the purpose of reconstructing an incident and providing a complete picture of the entire attack lifecycle, which often involves the recovery of deleted evidence.
Figure 3: The Unit 42 approach to digital forensics
Merged, DFIR determines the root cause of issues, identifies and locates all available evidence, and offers ongoing support to ensure that an organization’s security posture is bolstered for the future.
Click here to join Cortex’s DFIR community.
Incident response is a complex but crucial part of cybersecurity. The best advice to security teams building incident response programs is not to fret. Prepare and plan, but don’t panic! Like cybersecurity in general, incident response is not about being 100% ready for every cyberattack but continuously learning and enhancing processes to build resilience into security programs. As long as you know which steps to take, how to find the best help and which pitfalls to avoid, you’ll be able to lead your SOC through any security incident. Part of preparing for attacks is understanding the Incident Response Lifecycle.
If these attacks do occur, SOCs can implement DFIR to better understand their environment and how these attacks succeeded.
Discover why digital investigative services combined with incident response expertise is critical to manage the growing complexity of modern cybersecurity incidents: Digital Forensics and Incident Response
Incident response frameworks provide organizations with standards for creating an IRP. While it’s not required to implement them, these frameworks are excellent guidelines for SOCs as they create and adjust their plans. There are two especially well-known cyber agencies that have frameworks organizations may reference:
Figure 4: Building Incident Response Team
Many organizations have a specific team dedicated to incident response. This team goes by different names, like Computer Security Incident Response Team (CSIRT), Cyber Incident Response Team (CIRT), or Computer Emergency Response Team (CERT). A CSIRT can consist of an incident response manager, incident response analysts, digital forensics analyst, malware reverse engineers, and threat researchers. Many of these teams are led by chief information security officers (CISOs) or IT directors.
In some cases, organizations will choose to combine the efforts and capabilities of their internal teams with external incident response partners, such as Unit 42. Supplementing the team with additional experts is an excellent strategy to address the need for varying levels of subject matter expertise. Since cyberattacks can come in all shapes and sizes, it’s beneficial to have access to experienced external partners who can fill skill gaps when necessary.
In addition to having cyber-focused team members, it is also beneficial to have non-security stakeholders on the incident response team. This can include legal, risk managers, human resources, and other business functions.
For example, it is good to have a human resources representative on the team in case the security incident involves an employee, such as with insider threats or data leaks. Having general counsel on the team can be important to assess legal implications or if the incident involves third parties, like customers or vendors. Finally, a CSIRT should have a public relations specialist to present accurate information to relevant parties.
Having a well rounded and capable incident response team is a crucial part of the incident response process. Acting as experts in a time of crisis, the CSIRT should also spend time researching threats, encouraging best practices, and developing an incident response plan.
Apart from an incident response plan, security teams need tools to help them respond quickly and with scale to security alerts, from discovery to detection and response. The traditional tools used in SOCs include EDRs, SIEMs, and hundreds of other tools marketed at SOC teams. However, if you are thinking of automating key portions of your IR processes, it would be prudent to look at tools that are tightly integrated and allow for data sharing to provide comprehensive visibility and context into what is happening across your organization. This approach also minimizes operational efficiencies and a steep learning curve for your team in having to manage a myriad of tools.
Look for a holistic ecosystem with a view of the security posture for targeted threat detection, behavioral monitoring, intelligence, asset discovery, and risk assessment.
Extended detection and response solutions (XDR) such as Cortex XDR pull disparate telemetry together from multiple (and in some cases, complementary) sources, including EDR, network traffic analysis (NTA), user and entity behavior analytics (UEBA), and indicators of compromise (IoCs). It then performs ML-based behavioral analysis to group associated alerts, putting those alerts into a timeline, and reveal the root cause to speed triage and investigations for analysts of all skill levels.
The rise of the cloud and remote work means attack surfaces are constantly moving, changing, and becoming more complex. Additionally, advancements in scanning technologies allow attackers to scan the entire internet quickly and easily to locate attack vectors, revealing abandoned, rogue, or misconfigured assets that can become backdoors for compromise. Deploying an attack surface management solution like Cortex Xpanse can provide a continuous assessment of an organization’s external attack surface, with a continuously updated and complete inventory of all assets—including IP addresses, domains, certificates, cloud infrastructure, and physical systems—connected to an organization’s network and maps who in the organization is responsible for each asset.
Security orchestration, automation, and response (SOAR) technology like Cortex XSOAR helps coordinate, execute, and automate tasks between various people and tools all within a single platform. This allows organizations to not only quickly respond to cybersecurity attacks but also observe, understand, and prevent future incidents, thus improving their overall security posture.
A comprehensive SOAR product, as defined by Gartner, is designed to operate under three primary software capabilities: threat and vulnerability management, security incident response, and security operations automation.
Threat and vulnerability management is the management of threat feeds that provide threat intelligence and incident response teams additional context into the IoCs in their incidents or new threats in the wild, while security operations automation relates to the orchestration of security tools used in a SOC in automated incident response workflows that speed investigation and remediation of incidents.
Figure 5: End-to-end Workflow Automation of Security Operations
Many SOCs have limited or even nonexistent resources to effectively respond to an incident. That is why many companies choose to hire outside partners to assist with their incident response needs. Supplementing or even replacing internal teams, these partners deliver services to monitor, detect, and respond to security incidents that occur.
In the case of Unit 42’s IR services, our experts are on standby 24/7 to deploy resources to address your incident response needs. We can deploy best-in-class-tools like Cortex XDR to contain threats and gather evidence within minutes. This information will then be condensed into a post-mortem analysis that contributes to enhancing your IRP. Watch the video below to see how a Unit 42 expert will operate as an extension of your team.
Video: Unit 42 Threat-informed Incident Response Methodology
With a Unit 42 Retainer, your organization will receive prepaid credits for incident response. Your SOC can make our experts an extension of your team, having them on speed dial whenever you require assistance. You won’t engage in a frantic search for resources when there is a problem. Instead, a specialist who is already familiar with your environment will be there to help when you call.
If you don’t use all of your retainer credits on IR, you can repurpose them toward any other Unit 42 cyber risk management service to help you become more proactive, including IRP development, risk assessments, and so much more.
Incident response needs to evolve with the ever-changing threat landscape, and this starts with understanding the latest trends. To get an accurate representation of the present and future of incident response, check out the 2022 Unit 42 Incident Response Report.
The free Unit 42 e-book, Respond to Threats in Record Time, provides a guide to help your team quickly detect, respond, and contain security incidents.
SOCs need to evolve beyond SIEM. In short, the needs of the SOC have changed, but the design of the SIEM and SOC have not. Most other key pieces of the security architecture have been modernized. The endpoint moved from antivirus to EDR and to XDR; the network moved from a “hard shell” perimeter to Zero Trust and SASE; runtime moved from the data center to the cloud. In contrast, the SOC still operates on a SIEM model designed 20 years ago.
That model, whether delivered as on-premises software or forklifted to the cloud, was built around the human analyst. SOC analysts pored through hundreds of alerts per day, triaged manually by collecting contextual data, and spent the bulk of their time on false positives and manual effort. As alert volumes grew and data became harder to integrate from more systems, the human-led approach broke down. Instead, the modern way to scale an effective SOC is with automation as the foundation and with analysts working on a small set of high-risk incidents.
Better data modeling and integration combined with automated analytics and detection, ease the burden on security engineers, who no longer need to build custom correlation rules to integrate data and detect threats. Unlike legacy security operations, the modern SOC leads with data science applied to massive datasets rather than human judgment and rules designed to catch yesterday’s threats. The modern SOC must be built on a new architecture with:
