Preparation

The Preparation phase is the foundation of every effective incident response capability. Before an organization can detect, contain, or recover from a security incident, it must have the right people, processes, and technology in place. Without preparation, even the most skilled analyst will struggle to respond effectively when an incident occurs.

In this room, we will walk through what preparation looks like in practice. We will cover the key components of an incident response capability, explore the frameworks that guide this work, and review the preparation state of Nexus Financial before a real incident unfolds.

Learning Objectives

• Understand the purpose and importance of the Preparation phase in incident response
• Identify the key components of an IR capability, including people, processes, and technology
• Recognize how NIST SP 800-61r2 and SANS PICERL structure the incident response process
• Understand the role of logging and detection in identifying security incidents
• Identify preparation gaps in a real organization scenario that could enable an attack

Prerequisites

Familiarity with basic security concepts and SIEM tools such as Splunk is recommended as the module progresses to hands-on investigation work in later rooms.

Module Chain

This module follows a single security incident at Nexus Financial from start to finish across four rooms:

Security incidents are inevitable. Organizations of every size face adversarial threats daily, and the question is never whether an incident will occur but whether the organization is ready to respond when it does. Incident response is the structured approach an organization takes to prepare for, detect, contain, and recover from security incidents while minimizing damage and reducing recovery time.

Events, Alerts, and Incidents

These three terms are often used interchangeably, but they mean very different things in an IR context.

This distinction matters because the IR process formally begins at the point of incident declaration. Everything before that point is alert triage. Everything after is incident response.

What Triggers an Incident Response

An IR process can be triggered by many sources, not just automated alerts from a SIEM. Common triggers include:

• A security alert escalated by a SOC analyst
• A user reporting suspicious email or unexpected account behavior
• An automated detection from an EDR or SIEM tool
• A third party, such as a threat intelligence provider or law enforcement, notifying the organization
• A threat intelligence feed flagging infrastructure associated with the organization

Understanding that incidents can originate from multiple sources is important. An organization that only monitors automated alerts will miss incidents that start with a user report or a third-party notification.

How Nexus Financial Handles This

Nexus Financial has a security team in place to effectively register incidents. SOC engineers ingest events and build detection rules, SOC analysts triage alerts and analyze threats, and a compliance team handles incident reports from partners and external parties. This ensures that Nexus Financial knows when something bad happens, and it is handled as a formal incident in an organized manner.

When a security incident occurs, the people responding to it are under pressure. Decisions need to be made quickly, evidence preserved, and multiple teams need to coordinate simultaneously. Without a defined structure, responses become reactive and inconsistent. Critical steps get missed, evidence gets lost, and recovery takes longer than it should.

This is why incident response frameworks exist. A framework provides the IR team with a proven, repeatable process to follow regardless of the incident type or severity. It removes the need to make structural decisions under pressure and ensures that nothing important is overlooked. Frameworks also provide a common language across teams, making it easier to coordinate internally and communicate with external parties such as legal counsel or law enforcement.

NIST SP 800-61

The National Institute of Standards and Technology published the Computer Security Incident Handling Guide (SP 800-61 revision 2) (opens in new tab). It is one of the most widely referenced incident response frameworks in the industry and defines a four-phase IR lifecycle. This module follows revision 2 of the guide. 

A key characteristic of the NIST framework is that it is designed as a cycle. The lessons learned from the Post-Incident Activity feed directly back into Preparation, making the organization better equipped for the next incident. The diagram above shows how this module maps to the NIST lifecycle.

Note: NIST SP 800-61 is not the only incident response framework available. Others, such as the SANS PICERL model and the NCSC Incident Management framework, follow similar principles with slight differences in how phases are named and grouped. This room focuses on NIST SP 800-61, the most widely referenced framework in the industry and the foundation for many organizations' IR processes.

Where Nexus Financial Stands

Nexus Financial has an incident response policy in place that references NIST SP 800-61 as its guiding framework. The policy defines the IR phases, assigns roles to CSIRT members, and outlines communication procedures. However, as you will discover when reviewing the preparation documents, having a framework on paper and being fully prepared to execute it are two different things. Several foundational controls identified by NIST as part of the Preparation phase are either missing or incomplete at Nexus Financial, and these gaps have direct consequences for the incident described in this module.

Effective incident response is built on three pillars: the right people with the right skills, well-defined processes that guide their work, and the technology that supports detection and investigation. A weakness in any one of these pillars reduces the effectiveness of the entire IR capability.

People

The group responsible for managing security incidents is commonly referred to as a Cyber Security Incident Response Team, or CSIRT. You may also encounter this team referred to as a Computer Emergency Response Team (CERT), a Security Incident Response Team (SIRT), or simply an Incident Response Team (IRT). The name varies between organizations, but the function is the same. In smaller organizations, there may not be a dedicated CSIRT. In these cases, SOC analysts temporarily take on the incident response role when an incident is declared. This is a common practice in organizations that do not have a high enough incident volume to justify a permanently staffed IR function.

CSIRT members require appropriate access to the systems and data needed to do their work. This access should follow the principle of least privilege, granting only what is necessary for each member's role, audited regularly, and formally approved rather than assigned permanently.

Training is equally important. IR responders must be proficient with forensic tools, log analysis, and investigative techniques. End users must know how to recognize suspicious activity and report it through the correct channels. Regular phishing simulations and awareness campaigns build this capability over time.

Processes

Processes define how the IR team operates. Key documents include:

Technology

The technology layer gives the IR team the capability to detect threats, investigate incidents, and respond effectively. No single tool covers everything, and most organizations use a combination of solutions depending on their environment and maturity. Some of the core technologies that support incident response include:

These are not the only tools an IR team may use. The specific technology stack varies between organizations depending on their size, industry, and security maturity. What matters is that the tools are properly configured, actively monitored, and that the team using them is trained to get the most out of them.

Where Nexus Financial Stands

Nexus Financial has a CSIRT in place, supported by an IR policy, a communication plan, and a SIEM platform for detection. Like many organizations of their size, the Security Analysts also take on IR responsibilities in addition to their day-to-day roles. How well their people, processes, and technology hold up in practice is something you will assess in the practical task at the end of this room.

The tools discussed in the previous task under the Technology section are only as valuable as the visibility they provide. An organization cannot respond to what it cannot see. Visibility is the ability to observe what is happening across the environment through log collection and monitoring. Detection is the ability to recognize when something observed is malicious. Both are required for effective incident response, and a gap in either one allows attackers to operate unnoticed. A SIEM that is not collecting the right logs, an EDR that is not deployed on every endpoint, or an IDPS that is not monitoring critical network segments all create blind spots in the environment. Visibility is what the technology enables, and without it, the IR team is working without evidence. 

Visibility Through Log Management

Every device, system, and application within an organization generates log data. Collecting these logs into a centralized platform, such as a SIEM, provides the IR team with a single source of truth for investigations. Logs must be enabled, collected, and protected from modification once recorded.

The value of logs in an IR context is significant. They provide a factual record of who accessed what, when, and from where. They enable the IR team to reconstruct the attack timeline, identify affected systems, and confirm the root cause of a breach.

Types of Log Entries

• Event log: Records observable occurrences within a system, such as login attempts, application activity, and network connections.
• Audit log: Records a sequential history of actions taken within a system. Captures who performed an action, what the action was, and how the system responded. Split into success and failure categories; essential for investigations involving account activity and data access.
• Error log: Records system failures such as a crashed service or an application error.
• Debug log: Records detailed diagnostic information used during testing and troubleshooting.

Types of Log Sources

• Network logs: Come from routers, switches, and firewalls and record traffic flows and connection attempts.
• Host perimeter logs: Come from proxies, VPN servers, and boundary firewalls and capture what traffic enters and leaves the environment.
• System logs: Come from the operating systems on servers and workstations and include login events, process execution, and configuration changes.
• Application logs: Come from business applications, cloud platforms, and databases. In cloud-based environments such as Microsoft 365, logs from Exchange Online, SharePoint, and Entra ID are among the most valuable sources for investigating identity-based attacks.

Detection Gaps

Having logs available is not the same as having detection. A detection gap exists when logs are collected, but no alerting rules or monitoring are in place to flag suspicious activity. An organization with a detection gap may have all the evidence needed to investigate an incident, but will not know the incident is happening until long after the damage is done.

In this module, the Nexus Financial incident serves as a case study of what happens when detection gaps exist. The attacker carried out a sequence of activities that were all recorded in the logs but went unnoticed because no detection rules were configured to alert on them. The full picture only emerged during the IR investigation itself.

Nexus Financial uses Microsoft 365 for email, file storage, and collaboration, and Entra ID as its identity and access management platform. All employee accounts are managed through Entra ID, and all email, SharePoint, and Teams activity runs through Microsoft 365.

Start the lab by clicking the Start Lab Machine button below. The machine will load in Split View within a few minutes. If it does not appear, click the blue Show Split View button at the top right of the page.

Once the VM has loaded, open the Nexus folder on the Desktop. This folder contains a selection of Nexus Financial's preparation documents. In reality, an organization would have significantly more documentation, tooling, and processes in place. What is provided here is the material directly relevant to the incident you will be investigating throughout this module. You are only required to review these documents and answer the questions based on their contents.

The documents in the folder are:

• Asset_Inventory
• IR_Policy
• Communication_Plan
• Pentest_Report_2025
• Historic_Incidents

Once you have reviewed the documents, check the local security policies on this workstation (Part of Nexus Financial's Asset Inventory). On the lab machine, open the run dialogue, type secpol.msc, and press Enter. This opens the Local Security Policy. Navigate to the Policies under Security Settings, then review them.

Use the documents and the local security settings to answer the questions below.

The Preparation phase happens before the incident. It rarely gets credit when things go well, and it is easy to deprioritize when there are more pressing operational demands. But the Nexus Financial documents you reviewed in this room tell a familiar story: an organization that had some foundations in place but left critical gaps unaddressed.

Missing MFA on standard user accounts. No email authentication controls on the domain. A previous phishing incident closed without fixing the root cause. These are not unusual findings. They appear in organizations of every size and industry. What makes them significant is the chain of consequences they create. One unaddressed finding in a pentest report becomes the initial access vector in the next incident. One previous incident closed without a root cause fix leaves the same door open for the next attacker.

In the next room, Detection and Analysis (coming soon!), the incident has already happened. An anomalous sign-in alert has been raised. Your job is to take that single alert and work outward, identifying the compromised account, tracing the attack back to its origin, and scoping how far the damage has spread. Everything you need to understand why this happened is in this room. Everything you need to find out what happened is in the next one.