You've Invested in Security Tools. Has Anyone Checked If They Actually Work?

The Picus Blue Report 2026 — based on more than 338 million attack simulations run against real production environments — found that organizations logged 58% of attacker behavior across their security stacks. They alerted on 14%.

 

That 44-point gap between what was logged and what anyone was actually told about isn't a breach. Nobody got fired over it. The dashboards stayed green. But it represents the single most consequential blind spot in enterprise security today: the difference between security tools that are deployed and security controls that are working.

 

Most organizations live in that gap without knowing it.

 

 

Why Tools Drift From the Day They're Configured

Security stacks don't fail catastrophically. They erode quietly, through a hundred individually reasonable decisions made by people under pressure.

 

An analyst exhausted by false positives adds an exclusion to quiet a noisy EDR rule. A newly provisioned cloud server gets the EDR agent installed but nobody checks whether it's running with full system privileges. A SIEM log source changes its format after a vendor update — and suddenly the correlation rules built on the old format are running against data they no longer parse correctly. A firewall rule that made sense for an architecture that existed eighteen months ago is still in place for a network topology that no longer resembles it.

 

None of these are negligent decisions. Each made sense in the moment. Together, they produce an environment where the security stack looks healthy from the outside and has meaningful gaps from the inside.

 

 

The Four Failure Modes That Show Up Most Consistently

When security controls are tested against realistic attack behavior — not scanned, but actually tested — the same categories of failure appear across organizations regardless of their stack size, budget, or maturity.

 

1. SIEM rule degradation.

Rules that were accurate when they were written become unreliable as environments change. Performance problems — rules running too slowly to process high-volume events, or generating so much noise they've been deprioritized — were the leading cause of rule failure in 2026, accounting for nearly half of all SIEM issues. The second leading cause was log collection problems: events being dropped or compressed before they ever reach the correlation engine. The most common version is a setting called Improper Log Source Coalescing — it compresses events at the log collector to manage volume. The side effect is that some events never make it to the SIEM at all. An attacker clearing the local Windows event log gets away clean because the copy that should have been forwarded was compressed away.

 

2. EDR exclusion exploitation.

This is the failure mode that practitioners recognise immediately. After a wave of false positives — typically following a software deployment or a legitimate tool that triggers detections — someone adds a folder exclusion to quiet the noise. The console returns to normal. The exclusion stays. Attackers who know their target's endpoint security configuration drop payloads in exactly those excluded locations. The EDR that should catch it has an instruction not to look there. Testing for this means deliberately executing known-bad behavior in excluded paths and confirming whether the exclusion is still in place and still exploitable.

 

3. Detection-response gaps.

An alert fires. Nobody receives it in a form that allows a meaningful response. This failure lives at the interface between the technical layer and the operational layer — alert routing that sends high-priority detections to a queue that's processed the next business day, escalation paths that assume a staffing model that doesn't match how the SOC actually operates, playbooks that describe a response workflow that requires tools or access the responding analyst doesn't have. The detection worked. The response didn't. In a real incident, the gap between those two things determines the outcome.

 

4. Inter-control blindspots.

Each security tool covers its own domain. The EDR monitors endpoints. The SIEM correlates logs. The network controls watch traffic. The cloud security platform watches cloud-native behavior. What none of them do automatically is talk to each other in a way that closes the gap between domains. An attacker who moves laterally from a cloud workload to an on-premises endpoint may be visible in both environments independently — but the correlation that would surface the movement as a connected event never happens because the tools aren't configured to share that context. Testing inter-control coverage means running multi-stage attack sequences that cross security domains and checking whether the stack sees the attack as a connected chain, or as isolated, unrelated events.

 

 

What Actually Telling You Something Different Looks Like

Here's what a control validation exercise surfaces that a conventional penetration test doesn't.

 

A penetration test answers the question: can an attacker get in? A control validation exercise answers: if they got in through a path we already know about, would we know?

 

Run a credential dumping technique — LSASS memory access, a well-documented attacker behavior — against a live Windows environment. The expected result is a SIEM alert correlated with EDR telemetry. The actual result, in many environments, is silence: the technique executed cleanly, the log was generated, and the SIEM rule that should have fired didn't — either because the rule was misconfigured, because the log source wasn't feeding into the right index, or because an exclusion was in place that nobody documented.

 

Run a simulated command-and-control callback to an external IP over an encrypted channel. The expected result is a firewall block or a network detection alert. The actual result is sometimes an unimpeded connection — because the outbound rule that should have blocked it was modified during a troubleshooting session months ago and never restored.

 

Run an exfiltration simulation — a large data transfer to an external cloud storage service. The expected result is a DLP alert. The actual result, frequently, is that the DLP policy has a cloud storage exclusion for a whitelisted service that the simulated exfiltration happened to use.

 

In each case, the control existed. It was deployed, configured, and appeared operational. The simulation revealed that it wasn't working as designed under the specific conditions an attacker would use.

 

 

What You Can Actually Do With These Findings

The value of knowing where controls are failing is entirely in what happens next. A few practical principles that separate programs that improve from programs that produce findings reports nobody acts on.

 

* Prioritise by attack path, not by control. A finding that says "SIEM rule X isn't firing" is less useful than "SIEM rule X isn't firing, and that rule is the primary detection mechanism for lateral movement in your environment, which is the most likely path an attacker would use after initial access." The second framing tells you which gap to close first, and why.

 

* Fix, then retest. A remediated control that hasn't been retested is an assumption, not a verification. The test cycle should end with confirmation that the specific technique that produced a gap now produces the expected detection outcome. In environments where exclusions were the problem, this is especially important — the fix is often removing the exclusion, but the only way to know if the detection is working is to run the technique again.

 

* Track coverage over time, not just at point-in-time. Security controls that are validated today will drift again as the environment changes. The organizations that maintain coverage awareness — rather than treating a validation exercise as a one-time project — are the ones that don't find themselves back in the same gap six months later without knowing it.

 

* Test under degraded conditions. Most validation exercises run under normal operating conditions. Real incidents don't. Testing what happens to detection coverage when a key tool is in maintenance mode, when log ingestion is delayed by high volume, or when the on-call analyst is working a non-standard shift surface resilience gaps that normal testing never reaches.

 

 

The Right Question to Be Asking

Security teams ask "are our tools configured correctly" regularly. They ask "do our tools detect real attacker behavior under real conditions" far less often — and the Picus data suggests the gap between those two questions is worth about 44 percentage points of detection coverage.

 

The tools are deployed. The question is whether they're working. And the only way to answer that with confidence is to actually test it.

---

Comments

---

No Comments Found.