By Luke Fritz

If your SOC tooling only starts working when an alert fires, you bought half of security operations.

The reactive half.

It investigates faster. It responds faster. It closes more tickets. And the next attacker still finds the same open path, the same blind spot and the same rule that never fires.

The market spent the last two years making the reactive half faster using AI. The next gains are in the proactive half, and it only works if the two halves feed each other.

And yes, I'm going to say "shift left". But not the data one. In the data plane, shift left means moving detection into the pipeline, closer to where logs are collected. Different conversation. Here I mean shifting the SOC's work to the proactive side, before an alert exists.

"Closing the loop" is the other one you hear everywhere. Here's what it should mean: what the SOC learns while investigating and responding goes back into the proactive work. A missed TTP becomes a rule. A noisy rule gets tuned. An attacked path gets closed. That's it. No magic.

The two halves

Every SOC runs two jobs.

• Reactive: solves today's incident. Investigate the alert, turn it into an answer, contain and remediate.
• Proactive: builds a stronger tomorrow. Hunt with intel, remove what enables the next attack, turn every investigation into a better detection.

The reactive half is easy to measure. MTTI, MTTR, alerts closed. Everyone has a dashboard for it.

The proactive half needs its own numbers: detections added, coverage gaps closed, exposure removed. If you can't show those, you're not doing proactive work. You're planning to.

They also think differently. Triage is built to optimize. Most of the queue is noise, so the goal is a confident verdict without overkill.

Hunting is the opposite. You want overkill. One bad IP is enough reason to go through every data store you have, with federated search across one or several SIEMs, and rebuild what actually happened.

Splitting the work is fine. Two halves that never talk to each other is the problem.

How the loop feeds back

Here's the kicker. Every response should have three outputs, not one.

• Contain now. Stop today's threat.
• Strengthen detection. Create and tune rules from what the investigation found. Detect earlier, with less noise.
• Preempt exposure. Prioritize the related vulnerabilities, fix the misconfiguration, close the attack path.

The first one solves today's incident. The other two are what compounds.

Better detections and less exposure change what the reactive half sees next. Fewer alerts. Better ones. Less for the attacker to reach.

Skip the feedback and you have two tools sitting next to each other. Not a loop.

Where CTEM fits: deciding what to fix first

CTEM sits on the proactive half. Five stages: scoping, discovery, prioritization, validation, mobilization. For me, the one that makes it preemptive is prioritization.

Think about it. Every environment has more exposures than any team can fix. Finding them is not the hard part. Scanners never run out of findings. The hard part is deciding which ones an attacker is likely to use against you, and closing those first.

That decision needs more than severity scores:

• Scanners and asset lists tell you what is vulnerable.
• Threat intel tells you which campaigns are active and which TTPs they use.
• The SOC tells you what is actually being targeted, which identities keep showing up in alerts and which attack path an investigation just walked through.

Keep those in separate teams and prioritization falls back to CVSS. The fix list grows, in the wrong order.

Join them and an investigation does more than close a ticket. It moves the related vulnerability up the list, flags the misconfiguration that made the path possible and gets the path closed before the next attacker finds it.

Then check what you would actually see

Prioritizing exposures shrinks what an attacker can reach. It doesn't tell you if you would see them once they're in. That's the second question: which active campaigns are relevant to us, and do we have working detections for their TTPs?

Hunting with threat intel is the passive check: is the attacker already here? The coverage check is active. Map the TTPs of relevant campaigns to the rules you run and see where the gaps are.

Then comes the uncomfortable part. Do the rules you already have actually work?

In a recent proof of value, 75 of the customer’s 120 active rules never fired, and 20 of those never could. Broken queries. Data that was never collected. About one in six rules the team counted as coverage was not coverage.

And a rule that never fires looks exactly like a rule that works. Green on the dashboard, silent in production.

Same customer: mapping relevant active campaigns against existing coverage gave 120 recommended rules for TTPs with no detection. None of that shows up in a vulnerability scan.

What one pilot showed

Numbers from one customer are a data point, not a trend. I'm sharing them because they show the loop working in layers. Not because it's the best case.

The customer runs a cloud SIEM. Over about four weeks they had roughly 8,000 incidents built from 10,000 alerts, and about 30% of incidents were escalated. Noise came down in three layers: the customer's own automation, then AiStrike's analytics, then the customer's context automated and applied by AiStrike through learning from the knowledge base.

• Escalations dropped from 30% to 5%. High-severity incidents went under 1%.
• Modeled mean time to resolve, including L3 actions, dropped from about 180 to about 30 minutes.
• Modeled High-priority handling time dropped from about 1,400 hours to about 60 hours.
• Each High-severity incident reached an analyst with about 50 queries already run, and each Medium with about 20, so analysts started from evidence instead of a raw alert.
• AiStrike independently agreed with 99.8% of what the customer had auto-closed.
• On incidents the team had closed as false or benign positives, AiStrike reached the same verdict about 90% of the time. Most of the rest was real activity the team had judged acceptable, such as blocked ransomware and password spray, which AiStrike surfaced for a second look. The remainder became the tuning backlog for the knowledge base.

That last one is the loop in action. Faster triage is expected. Showing a team what its own process deprioritized, and why, is what feeds the next round of detection work.

So, what does the full SecOps look like?

Preemptive is not a feature you buy. It's what SecOps looks like when both halves are there and the loop is closed. Three things have to be true:

1. Exposures get prioritized by threat, not by score. Threat intel and what the SOC sees decide what gets fixed first and which attack paths get closed.
2. Detections get validated, continuously. Start with simulation against your own rules. Autonomous pentesting can wait until the market is ready for it.
3. What triage and hunting learn goes back in. Every missed TTP, broken rule, false verdict and attacked path becomes input for the next cycle.

Final thoughts

That's the loop AiStrike is built around: investigation and response to solve today's incident, preemption and detection engineering to build a stronger tomorrow, every outcome feeding the next.

If your tools do each half well but never talk to each other, you have speed. You don't have a loop.

Fast triage closes the ticket. The loop closes the path.