If your analysts have to log into your SIEM, then your EDR, and then a Threat Intel portal just to validate a single alert, your SOC is failing at the most basic level: efficiency.
Every pivot is a pause where a real threat could slip through. The core value of a true SOAR platform isn’t just running scripts; it’s the ability to act as the centralized intelligence hub.
Welcome to Part 2 of my Enterprise SOC Automation series. Today, we are moving beyond the basic concept of automation to discuss architecture. Here is how to transform your SOAR from a simple “playbook runner” into the Operating System of your Security Operations Center.
1. Why “Out-of-the-Box” (OOB) Integrations Are a Trap
When you are in the vendor selection phase, every SOAR provider will boast about having hundreds of Out-of-the-Box (OOB) integrations. It is an arms race among vendors, but here is the reality: OOB is rarely enough.
When you start implementing these integrations, you will quickly find that you need customizations. Furthermore, if you purchase a brand-new security solution, it likely won’t be supported OOB. The sales engineer might promise you that their team will “build a custom connector within a week,” but operations dictate a different reality. Feature requests get delayed, and you cannot afford to wait.
The Solution: Make sure the platform you choose supports easy, custom integration building. You must have the ability to clone existing connectors, modify their code, or build your own from scratch using standard APIs.
Additionally, you will often need to treat specific IT tools (like HR databases or GRC platforms) as alert sources, even if they don’t natively generate security alerts. Your SOAR must support scheduled playbook execution (cron jobs) to actively poll these tools, fetch the necessary data, and dynamically create new alert records.
2. Fetching the Alert is Not Enough: The “Main Playbook” Strategy
One of the biggest mistakes SOC engineers make is pulling a raw alert from the SIEM into the SOAR and calling it a day.
If you look at an alert on your SIEM portal, you see a rich narrative: related events, network flows, triggered rules, and asset information. However, when the SOAR pulls that same alert via the SIEM’s API, it usually only gets the bare minimum: Alert Title, Description, Timestamp, and a few basic fields.
To fix this, the SOAR must independently fetch the missing context. I implement a concept called the “Main Playbook.” Here is how it works:
- The raw alert is ingested into the SOAR.
- The “Main Playbook” executes immediately, reaching back into the SIEM (or EDR) to pull all related events, flow data, and asset contexts, attaching them directly to the SOAR Alert Object.
- Crucial Step: Only after the Main Playbook finishes should your Cyber Threat Intelligence (CTI) enrichment playbooks run. Why? Because the Main Playbook will inevitably uncover additional observables (hidden IPs, domain names, hashes) that the initial raw API payload missed. If CTI runs first, you miss enriching the most critical data.
3. Stop Using Your SIEM as a Dumb Funnel
Historically, SOC teams have used the SIEM as the ultimate aggregator. For raw logs (servers, workstations, firewalls) that don’t have their own detection engines, the SIEM is strictly necessary to correlate events and detect attacks.
However, many modern tools—like EDRs, NDRs, and Anti-Phishing platforms—have their own highly sophisticated detection engines. Often, SOC engineers will forward these pre-processed alerts into the SIEM, build a generic “catch-all” use case just to trigger them, and then send them to the SOAR.
This architecture destroys context. It strips the rich telemetry from the source tool. Furthermore, many vital defense layers (Asset Management tools, Identity platforms, specialized Anti-Phishing gateways) are never integrated into the SIEM at all, leaving massive blind spots.
As mentioned in the previous post, automation is a strategy. The SOC Manager must make a strategic architectural decision: Connect the SOAR directly to the native intelligence/alert sources, rather than funneling everything through the SIEM. Let the SIEM do what it does best (log correlation), and let the SOAR act as the true centralized operational hub.
4. Measuring Success: The “Replacement Ratio” KPI
If your SOAR is acting as a true Operating System, your analysts should rarely need to leave it. The main objective of this centralization is minimizing manual effort and eliminating context-switching.
An L1 analyst should be able to conclude whether an alert is a True Positive (TP) or False Positive (FP) entirely within the SOAR view. They should never have to log into the source tool just to ask for more enrichment data. (It is perfectly fine for L2/L3 analysts to pivot to the SIEM for deep, historical threat hunting, but L1 triage should be centralized).
To measure this, we use the Replacement Ratio.
Replacement Ratio = (Alerts resolved entirely within SOAR) / (Total Alerts)
This metric calculates how effectively the SOAR has replaced the need to log into the SIEM or the original alert source. If your Replacement Ratio is low, your playbooks aren’t pulling enough context. If your Replacement Ratio is consistently above 80-85%, you have successfully turned your SOAR into the beating heart of your SOC.
Leave a Reply