A managed detection library can be working exactly as contracted and still stay silent while an attack walks through it. The rule was written for one shape of one behavior, and the attacker used another. Nothing about that miss surfaces anywhere, because a rule that never fires looks identical to a rule with nothing to catch.
For an enterprise buying managed detection and response, that silence is the expensive part. The service does its own job well. It was never built to keep a detection alive, and a coverage report won’t show the difference.
A Java web application carries a deserialization flaw. An attacker exploits it, uploads a file, and gets a shell.
You’d expect the EDR to catch it. Often it doesn’t. So the weight lands on the detection rule watching what happens next. That rule is looking for cmd.exe. The attacker used PowerShell.
Nothing fires.
There’s a second version of the same story. The rule gets written broad enough to catch every way of starting a shell, and now it fires all day. Analysts close its alerts again and again, until the close becomes routine.
Every detection engineer has lived both halves of that bind. The outcome turns on who owns the rule and what it costs them to keep it honest, and for an enterprise buying the service, both answers sit inside the service model.
The short version
- Most MDR detection libraries are a fixed set of 50 to 200 signature-shaped rules mapped to MITRE tactics and techniques. Each rule describes one shape of one behavior, and a small change in how the attacker moves can get past it without a flag.
- The library stays small on purpose. Volume fear and SLA adherence are the same mechanism. Every added detection means more alerts against the same response promises.
- The honest fix keeps the MDR. A resilient cyber defense platform runs the living detection work on the stack the SOC already owns, inside approval thresholds the organization sets.
One rule, one shape
A signature-shaped rule describes one way an attack looks. One invocation path. One command string worth flagging. When activity matches the shape, the alert fires. When the activity deviates even slightly, the rule has nothing to say.
That design is deliberate. Narrow rules are cheap to run and quiet in the queue, and quiet is what a service with response-time promises needs. Narrow also means brittle. The deserialization attack above stepped around its rule without touching it, by running a different binary to do the same thing.
Attackers understand this economy. Changing an invocation is free. Rewriting a detection library is a project with an owner and a budget.
What sits inside the rule library
Most MDR services run a defined detection library, somewhere between 50 and 200 rules, mapped to MITRE tactics and techniques. On a proposal slide, that mapping reads as coverage. Inside the SOC it means something thinner. The rules cover types of tactics and techniques, but they’re not atomic. One rule stands in for a family of behaviors, shaped to the most common version of each, and a small deviation from that behavior might not trigger anything.
Two more things tend to be true about that library. It arrived largely fixed, tuned to serve many customer environments at once. And the customer is mostly locked out of it. You don’t always get the ability to influence the rules or bring your own. Some services say it plainly. These are our rules. This is what we support. Anything beyond that sits with the customer.
That posture is rational from inside the service. The reason lives in the volume math.
Why the library stays small
An MDR prices and staffs against its response promises, tiered by severity and written into the contract. Every alert the library produces lands on a human with one of those clocks already running.
Now add a detection. Volume goes up. The promises stay where they are. Add a few more and the service is holding the same clocks against a queue it keeps making deeper. From inside the model, capping the library is self-defense. Volume fear and SLA adherence are the same mechanism.
Operators in the MDR space describe the same mechanism tightening from the other side. Buyers who accepted response windows of up to 72 hours a year or two ago now ask for one to four. A provider protecting a tighter promise takes on fewer new detections and narrows the scope it agrees to watch.
The result is a library that stays small and stays still, in front of attackers who change their paths for free.
Detections are living things
They have to adapt as the actors do, and they need refreshing when they stop matching the behavior they were written for.
What feeds that life is a loop. Threat intelligence feeds detection engineering. Detection engineering feeds investigation. Investigation outcomes feed back into the detections and into the intelligence picture. Run that loop around actor tracking and it compounds, because every campaign the SOC studies makes next quarter’s rules sharper.
Skip the loop and rules age in place. Log sources move. Fields get renamed. The behavior a rule described in January stops matching how anyone does the thing by June. Nobody notices, because a silent rule looks exactly like a healthy rule with nothing to report.
This is how a small change in an attacker’s path gets past the library. The library is a fixed set of signature-shaped rules, most of them mapped to MITRE tactics but written for a specific shape of behavior. A small deviation from that shape can pass without a flag, and a rule that quietly broke months ago can’t fire at all. Neither failure announces itself.
Any fixed rule library ages this way once it’s left alone. A managed library ages the same way, and a customer without input into the rule set has fewer ways to notice.
The service is doing the job it was priced for
Enterprises buy managed detection and response for reasons that hold up. The provider takes on risk, and that transfer is what the business signing the contract is paying for. It also hands a small team a full program. A team of two or three analysts and maybe a manager gets around-the-clock triage and an escalation path they could never staff on their own.
The analysts inside that service are good. They close what the rules put in front of them, at the pace the promises demand.
The limits belong to the model and to the era that produced it. The model comes from a world where adding capacity meant adding people, and where a fixed set of well-chosen rules could keep pace with how attacks changed. Held against this decade’s attackers, both of those assumptions have expired, and no amount of talent inside the service brings them back.
What changes when detections live inside a connected system
The Five Eyes intelligence alliance warned in a June 23, 2026, advisory that AI can outpace cyber defenses within months. A detection library refreshed by hand, on a service’s schedule, has no path to staying current against offense that moves at that pace.
Conifers built CognitiveSOC™ for the upkeep the old model was never priced to do. CognitiveSOC is an agentic AI SOC platform that delivers resilient cyber defense. It connects the five functions of the SOC into one system. Threat intelligence, threat hunting, detection engineering, investigation, and remediation feed one another inside it, so the loop that keeps detections alive runs continuously instead of by hand.
New intelligence turns into a detection without waiting on a handoff. Investigation outcomes feed straight back into tuning.
AI doing detection work needs to be governed, and it needs to be backed by people who know what they’re doing. Every conclusion the platform hands back carries its reasoning and evidence, and the organization sets the approval thresholds those changes run inside. The judgment stays with the team.
The platform runs on top of the SIEM, EDR, identity, and cloud systems the SOC already owns. No rip-and-replace, and no rip-out of the MDR either. Budget and risk appetite decide the mix. If there’s money, do both. Keep the provider for the program it delivers and run the platform under it for the living work. Where budget is tight, the cost taken out can fund one or two people focused on maturity.
The cmd.exe rule from the top of this piece is still waiting, unchanged, for an attacker who moved on months ago. Inside a connected system, last month’s investigation would already have rewritten it.
Ask your MDR when each rule in your library last changed. Then run the rest of the exercise. Our guide, Where your MDR coverage ends, carries the full question set across all five functions, with what to pull for each answer. It’s at conifers.ai.
Frequently asked questions
Does this argue for dropping the MDR?
No. The provider is doing the job it was priced for, and the risk transfer it sells is the value the business is paying for. Budget and risk appetite decide the rest. Where there’s money, keep the service for the program and the coverage and run an agentic platform under it for the living detection work. Where budget is tight, the cost taken out can fund one or two people focused on maturity. The point of benchmarking your MDR is knowing where its model ends, so the decision about what runs underneath it is yours and made on evidence.
What does signature-shaped mean?
A signature-shaped rule describes one specific shape of one behavior. One invocation path, one command string. If activity matches the shape, the rule fires. If an attacker does the same thing a slightly different way, it stays quiet. A library described as mapped to MITRE tactics and techniques can still be signature-shaped underneath, because one rule often stands in for a whole family of behaviors. The mapping tells you which techniques were considered. It doesn’t tell you how many versions of each the rules can see.
Why would a provider decline detections we ask for?
Because every detection adds alert volume against response promises that don’t move. An MDR prices and staffs to its SLAs, so a bigger library means more clocks running on the same bench. From inside the model, capping the rule set is rational self-protection, and the pressure grows as buyers push for faster response. It reads as inflexibility from the outside. From the inside it’s volume fear, and it’s honest. The useful question for a provider is which requested detections were declined, and what would have to change for them to be supported.
How does an agentic platform keep detections current?
By running the loop a fixed library skips. Threat intelligence feeds detection engineering, detection engineering feeds investigation, and investigation outcomes feed back into both. On the Conifers platform that loop runs continuously across the five functions, so new intelligence turns into a detection without waiting on a handoff, and investigation outcomes feed back into the rules. The platform does this on the stack the SOC already owns, with no rip-and-replace, so the detections that come alive are the ones watching your actual environment.
Who stays in control when AI maintains detections?
People do, by design. AI doing this work needs to be governed and backed by people who know what they’re doing. On CognitiveSOC, every proposed change arrives with its reasoning and evidence attached, and analysts can challenge any conclusion before it lands. The organization defines the scope and the approval requirements up front. Machine speed applies to the work. Judgment stays with the team, and the team can always see why the system believes what it believes.
Sources
- Five Eyes intelligence alliance advisory, June 23, 2026. AI can outpace cyber defenses within months, and cyber risk assumptions can become outdated in months rather than years.