SecOps Process BluePrint

Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.

In my previous posts, I talked about AI Agents for cybersecurity, Autonomous Investigations (AI SOC), and even compared Copilot with Autonomous Investigations.

In this post, I’m taking a closer look at the entire incident response process, focusing on a new, redesigned structure. We will briefly touch on the Preparation, where detection engineering, playbooks, and automation set the stage. Then go into details around Identification & Enrichment collecting context from internal and external sources to determine if an alert is a true positive or a false positive. For true positives, we dive deeper into Investigation, answering key questions about what is happening and why. Following that, we cover the Containment, Eradication, and Recovery stages, and finally wrap up with Lessons Learned.

By mapping out the process this way, I hope to provide you with a clear, practical blueprint for SecOps that you can adapt to your own environment, whether you’re handling things manually, using SOAR-driven processes, or operating a fully Autonomous SOC.

This edition is sponsored by Intezer

Identification (Enrichment and Initial Analysis)

Before we dive into a deeper investigation, it’s important to remember that incident response is a shared responsibility. It ties closely to the Preparation phase, where we do Detection Engineering, having good detections in place is key to identifying a threat. I won’t go deep into that process here (that’s a story for another time). Instead, let’s jump into the Identification phase, where we determine if an alert is a true positive or a false positive.

I redesigned these IR stages for a better mapping of the process,and big shoutout to Itai Tevet for the feedback that helped shape this approach.

As you may know, this is one of the steps where we can often conclude whether an alert is a true positive or a false positive. So what does this first step involve? If we look at the IR process, the Identification phase is constructed from a few elements. On one side, we have the security solution doing some sort of detection (EDR, Email Protection, SIEM, DLP, CSPM, ITDR, etc.), all generating alerts. 

Who is involved?

Is the activity coming from an admin account, a service account, or an employee? Checking if the behaviour aligns with what’s expected can quickly signal if something’s off.

Where is the activity originating from?

Identify the source and target of the action. Is it taking place on a server, an endpoint, in the cloud, or within an Infrastructure as Code environment? For example, for a server, review related change requests and vulnerability data; for an endpoint, examine its posture and trust level.

When did it occur?

Examine the timing of the event. Is this the first occurrence, or part of a recurring pattern? Comparing the alert against historical data can help spot anomalies.

What was executed?

Ask what commands or code were executed, what communications were initiated, and what happened to the suspect machine or user. This question is critical even during triage as it helps correlate events quickly and build a comprehensive context.

At this stage, we perform alert enrichment, gathering as much context as possible from both internal and external sources.

Internal Enrichment involves pulling in data from your own systems. You check details such as historical provisioning patterns, resource types, and identity data. For instance, determine who performed the activity, whether they’re an employee or a service account, and if their actions match what’s expected. You also contextualize where the activity is happening by reviewing asset details—like related change requests or vulnerability data—and look at when this activity has occurred in the past compared to the current event.

External Enrichment relies on threat intelligence. This means checking if the IP, account, or activity matches known bad actors or tactics. For example, verify IP and domain reputations, check file hashes or detonate malware in a sandbox, and extract intel on threat actors using specific tactics (such as those in the MITRE ATT&CK framework). Instead of relying solely on atomic indicators, building detections based on behavior is crucial to determine if activity is malicious or benign.

Once you’ve enriched the alert, you should have enough context to conclude whether it’s a false positive or a true positive. If it’s a false positive, feedback should be looped back to Detection Engineering for fine-tuning. If it’s a true positive, you’re ready to proceed to the investigation phase.

Investigation Phase - Threat Analysis

With a confirmed true positive, it’s time to dig deeper. This phase aims to answer two core questions:

What is happening?

At this stage, we ask: What is the incident really about?

• Resource Misuse: Is someone misusing our systems or resources in unexpected ways?

• Compromised Accounts: Has an account been hijacked or misused to gain unauthorized access?

Why is it occurring?

Understanding the root cause is where deeper analysis shines:

• Compromised Credentials: Was there a breach due to weak or stolen credentials?

• Malicious Intent: Is this a targeted attack where the adversary’s goal is to cause damage or extract sensitive data?

This phase involves more detailed tasks. Digging through logs and connecting the dots is time-consuming but critical. Every log file, whether system, network, or application—can be a potential clue. You’re not just looking for errors, but hunting for patterns like unusual login times or access attempts from unfamiliar IP addresses.

• Forensic Evidence Collection is labor-intensive but essential. This involves capturing file samples, images, memory dumps, and network dumps. It’s not just about gathering data—it’s about preserving it with proper chain of custody for future analysis or legal proceedings. This evidence allows for in-depth analysis to uncover the true extent and method of the attack.

• Blast Radius Determination expands the search to other systems and accounts to assess the scope of the impact. By identifying similar anomalies elsewhere, you gauge how widespread the threat might be, which in turn helps in preventing lateral movement within the network.

• Timeline Analysis is like piecing together a puzzle. You reconstruct when the activity started, how it progressed, and whether there’s an identifiable pattern ;be it phishing entry, an exploited vulnerability, or lateral movement. Even at this stage, you might discover that the alert was a false positive or that some logs are missing, reinforcing the importance of a robust feedback loop.

Combining alert enrichment with in-depth threat analysis builds a solid foundation for your incident response process. This integrated approach confirms whether an alert represents a true threat and provides the detailed context needed to tailor your subsequent containment actions.

Side Note:
Just to clarify for the audience, in my view there are two types of enrichment. One is what I call the static enrichment, which usually happens as part of the detection engineering logic. This involves building lookup tables in the SIEM and using that data to provide basic information such as employee details (which team or role they have) and asset information (is it a server, an endpoint, what kind of data it holds). At the end of the day, you need to evaluate whether it’s more cost-effective to store all this data for correlation at the SIEM level or to do API calls to grab the latest info from another system.

On the other side, there’s dynamic enrichment, which involves more up-to-date information. This includes the last known IP or location of the user, the latest changes from the change management process, current threat intelligence (IOCs), and the most recent vulnerability data. Both types of enrichment play crucial roles in ensuring that your analysis is as accurate and timely as possible.

Containment & Eradication

Once you’ve confirmed a true positive, the next step is to immediately halt the threat and remove it from your environment. In this combined stage, we address both the urgent need to stop the attack and the follow-up actions to eliminate its root cause. This streamlined approach makes particular sense for simpler incidents and smaller organizations, where a separate, multi-step process might be unnecessarily complex.

Containment Actions:

• Immediate Response: Blocking IOCs: Stop further damage by blocking malicious IPs, domains, or file hashes via firewalls, proxies, or endpoint security tools.

• Isolating Affected Systems: Quickly isolate compromised machines from the network to prevent the threat from spreading.

• Disabling Compromised Accounts: Lock or disable accounts that have been hijacked to cut off unauthorized access.

Thorough Eradication:

• Clean-Up Actions: Once the immediate danger is contained, focus on eliminating all malicious artifacts from your environment. This includes revoking compromised credentials, removing malware or unauthorized tools, rolling back misconfigurations, and applying necessary patches or updates to close any exploited vulnerabilities.

• Validation and Verification: After clean-up, perform targeted scans and tests to confirm that no remnants of the threat remain. This ensures that any persistence mechanisms or hidden backdoors have been fully removed before moving on to recovery.

By combining containment and eradication, you streamline the response to quickly stop the attack and remove its root cause in one coordinated effort. This integrated approach is especially beneficial for simpler incidents or smaller organizations, where resources are limited and a faster, more efficient response is key to minimizing damage.

Recovery 

Once the threat is contained and eradicated, the focus shifts to restoring normal operations and strengthening defenses to prevent future incidents. This stage involves:

System Recovery:

• Restoring systems from clean backups or snapshots.

• Rebuilding compromised systems if necessary.

Vulnerability Patching:

• Applying patches or configuration updates to close security gaps.

Credential Reset & Hardening:

• Revoking or resetting compromised credentials and implementing stronger authentication measures.

Data & Compliance Actions:

• Removing or encrypting any exfiltrated sensitive data.

• Documenting remediation actions for compliance and continuous improvement.

In this separate stage, automated remediation can be a real asset, ensuring consistent and repeatable recovery processes while reducing human error. Automated processes may handle tasks like patching vulnerabilities, restoring systems, or updating compliance reports—helping to streamline your overall recovery efforts.

Lessons Learned

This is where we do root cause analysis and maintain a proper feedback loop. For example, updating your Threat Intel DB with the indicators extracted from the incident, improving detections, or adding more log sources. You might even need new technology if you identified gaps, or you might update your operating procedures or playbooks.

Manual Labor, Automation, or Autonomy?

Now, let’s break down the different strategies and see their advantages and disadvantages.

Manual Labor

Yes, it’s 2025, but the sad truth is that many SecOps/IR tasks are still done manually. This typically happens because your (PPT) People, Processes, and Technologies are not well-implemented, or your SecOps team is constantly firefighting and doesn’t have the bandwidth to automate.

To put this in perspective:

• It takes 5 to 30 minutes to do initial triage, and analysts might spend 6 hours of their day doing just that.

• Investigations can take, on average, 4-5 days (in some cases up to 20 days for complex incidents).

• Eradication & Recovery can add another 17 days.

Using Traditional Automation / SOAR Style

Some say SOAR is dead, but we haven’t adopted automation nearly enough. With the right framework (e.g., my SDLC framework), you can automate most steps and cut time by 10x. However, you’ll spend time building and maintaining automations—this can be tricky because of unstructured data and all the scenarios you must account for. Next-gen SOAR or hyperautomation platforms make it simpler to build and maintain these automations, which is why adoption has picked up.

You’ll have an upfront investment of time and resources, but the result is faster detection and resolution. Plus, you can handle more alerts in the initial stages, leading to added FTE time. You can process alerts 10x better and faster.

Using Autonomous (AI SOC) Solutions

These solutions often deliver even better results because they come with pre-built automations for handling alerts and incidents, eliminating the build-and-maintain phase. Many will hand you the alerts at the Investigation or Eradication & Recovery stages. The trade-off is that you have less flexibility than a traditional SOAR approach, but it’s faster to deploy, and you often get more added FTE time. If the solution provides out-of-the-box external enrichment, you can also save on threat intel or sandboxing costs.