Detection Is Engineering, Not Improvisation

This is the second chapter in a three-part section on what distinguishes UTIOM from conventional security operations frameworks. The first made the case that UTIOM starts from management science, not tools. This one shows where that foundation becomes concrete: the detection layer, and the measurement model that keeps it honest.

In Part 1, I argued that most SOC failures are management failures wearing technical costumes. Fair question in response: fine — but management principles don't catch adversaries. Detections do. So what does UTIOM actually change about how detection gets built?

Start with a sentence from TID-CMM, the detection maturity model inside the UTIOM family, because it describes the industry's open secret better than any statistic:

"A rule that has never fired on a true positive, running on a log source that stopped reporting six weeks ago, mapped to a technique your adversaries do not use, counts exactly the same as a detection proven to catch a real intrusion in minutes."

That is how most organizations count detection today. Rule count as strength. Matrix coverage as capability. Dashboards as evidence. UTIOM's answer is a single reframing that the book states as doctrine:

"Detection becomes engineering, not improvisation."

Engineering means requirements, tests, pipelines, failure modes, maintenance, retirement — and measurement that refuses to flatter. Here is what that looks like, and why so few frameworks demand it.

Three Ways SOCs Lie to Themselves#

TID-CMM was built to expose three endemic problems, and they are worth naming before any solution, because every one of them produces a green dashboard:

Coverage claimed without visibility. Rules mapped to techniques but running on incomplete or dead data sources. The mapping is real; the telemetry underneath it is not.

Detection built without a threat model. Content subscriptions that raise ATT&CK matrix coverage while ignoring the paths real adversaries would actually take to your crown jewels.

Capability asserted without evidence. "We have a rule for it" travels from the SOC to the board pack without anyone ever testing whether the rule fires.

Notice what these three have in common: none of them is a technology failure. Each is a broken chain of reasoning — exactly the management disease Part 1 diagnosed, resurfacing in the detection layer. UTIOM's detection discipline is built to make each one structurally impossible.

Every Detection Is a Requirement — or It Is Waste#

Most SOCs accumulate detections the way attics accumulate boxes: vendor content packs, rules copied from blog posts, leftovers from analysts who left years ago. Nobody can say what half of them are for.

UTIOM imports the V-Model from systems engineering and applies it without mercy: every detection artifact must trace back to a specific risk or threat model. The book is blunt about the alternative — "if a detection doesn't map to a requirement, it is usually waste in the system."

The V-Model brings its twin disciplines with it:

Verification — building it right. Does the logic actually function as specified?

Validation — building the right thing. Does it reduce a real business risk, or is it orphaned research?

A rule can pass one and fail the other. A beautifully written detection for a technique no adversary would use against your crown jewels is verified, validated by nothing, and costing you money every day it runs.

Figure — Every rule traces back to a risk and forward to a test.

This is the cascade UTIOM enforces, top to bottom: crown jewels → realistic threat models → required telemetry → detections keyed to those paths → response aligned to those detections. And the scoping is not hand-waving: of the 697 Enterprise techniques and sub-techniques in ATT&CK, a serious threat-modeling pass typically leaves 150–250 that matter to a given organization. Detection sprawl is impossible by construction, because a rule with no ancestor in that chain has no right to exist — and a backlog scoped to what is real is a backlog a team can actually finish.

Figure — Detection traceability from crown jewels to validated response.

Visibility Comes First — and Some Gaps Are Physics#

Before UTIOM lets you write a single rule, it makes you answer an uncomfortable question: would you even see the behavior you want to detect?

"You can't build meaningful visibility without knowing what deserves to be seen."

The Threat Visibility domain does the unglamorous work most frameworks skip: mapping ATT&CK tactics and threat models to actual data sources, defining logging and retention standards, enforcing data quality and normalization, placing deception aligned to crown jewels. Its output — a visibility blueprint and gap report — is the input to detection engineering. The book calls visibility the bloodstream of detection, and the metaphor is exact: rules built on telemetry you don't reliably collect are decoration.

TID-CMM makes this brutally concrete. TID-CMM analysis of ATT&CK v19.2 finds that 423 Windows techniques — 89 percent — reference Sysmon-class telemetry. If that telemetry, or its EDR equivalent, is absent, then in TID-CMM's words: "that is not a gap in your rule set. It is a gap in physics." No amount of detection engineering fixes physics. The model computes which techniques your actual log sources can support, bands them — assured, partial, weak, blind — and ranks which telemetry to enable next by how many blind techniques it unblocks. "Detection is bounded by visibility, and that is now measurable."

And where a gap remains, UTIOM demands it be documented and formally accepted. A blind spot you chose is a risk decision. A blind spot you discover mid-incident is a design failure.

Detection-as-Code: The Software Discipline, Uncut#

UTIOM mirrors modern software practice in full, not as a buzzword:

Version control. Every rule's lineage and purpose is traceable — who built it, against which threat, changed when, and why.

CI/CD pipelines. Detections deploy, validate, and roll back safely, in managed release cycles instead of hand-edits in a production console.

DRY — Don't Repeat Yourself. The exclusion list pasted into fifty rules is maintenance debt with a countdown timer. Shared logic moves into shared objects, once.

Abstraction layers. This one quietly protects years of work. In the book's words: "Your detection logic should not care if the data comes from CrowdStrike, SentinelOne, or Sysmon. The logic should sit on top of a standardized schema." When the EDR contract changes — and it will — your detection capital survives the migration.

Three tiers of testing. Unit tests validate a single rule against isolated log snippets. Integration tests confirm it plays correctly with alerting pipelines and SOAR playbooks. Effectuality tests answer the only question leadership cares about: does it actually fire when the real behavior happens? A rule that has never been tested against a simulated adversary is not a detection. It is a hypothesis.

Figure — A rule untested against a real adversary is a hypothesis, not a detection.

Behaviors Outlive Indicators#

UTIOM also takes a position on what a detection should be made of:

"Detection built from behaviours lasts longer than detection built from indicators."

A hash, a domain, an IP — the adversary discards these between breakfast and lunch. A behavior — anomalous command sequences, unauthorized write operations, protocol misuse, impossible token usage across regions — persists as long as the tactic itself persists. The book's OT manufacturing case study builds its entire detection layer this way: behavioral signals around what must never happen to the process, not fingerprints of last month's malware.

Indicators still have a place. They are just not the foundation. Foundations are supposed to last.

The Detection You Retire Is as Important as the One You Build#

Here Part 1's Drucker returns, wearing an engineer's badge. Systematic abandonment — "if you want something new, you must stop doing something old" — is a core engineering discipline in UTIOM, not a spring-cleaning ritual. Every improvement cycle prunes rules that no longer protect crown jewels and telemetry that no longer feeds a detection. The book's warning is vivid: without deliberate pruning, the SOC becomes a factory of data.

Ask a SOC how many detections it has and it will answer proudly. Ask how many it retired last quarter and you learn whether it is engineering or hoarding.

Assume Components Fail#

Real engineering disciplines design for failure, and UTIOM is unusual among security frameworks in demanding the same of detection: redundant visibility paths, so identity and network telemetry carry the load when the endpoint sensor is bypassed; backpressure and circuit breakers, so a noisy day doesn't silently drop the telemetry that mattered; and meta-detections — detections that watch detection itself: a critical log source going quiet, ingestion latency breaching its SLA, a pipeline stage failing.

The most dangerous outage in security operations is the one that produces no alert — the silent visibility failure that turns your SIEM into a confident liar. Remember the rule from TID-CMM's opening line: it had stopped reporting six weeks ago, and nobody noticed. Meta-detections exist so that sentence can never be written about you.

The Analyst Is Part of the System#

UTIOM extends engineering discipline to the point where most frameworks stop: the human reading the alert.

Every alert, regardless of source tool, follows the same hierarchy: what happened, why it matters, and what the first step to fix it is. Signal-to-noise ratio is optimized deliberately, through grouping and narrative incidents rather than raw event streams. And alert fatigue is classified — in writing, as doctrine — as a system design failure, never an HR issue.

That classification changes who is accountable. When analysts burn out, the question is no longer "why can't they keep up?" but "which engineer let this noise into the pipeline?" Dieter Rams' minimalism, imported in Part 1, does its hardest work here: every alert must honestly reflect a business risk and offer an understandable path to response. Less, but better — as detection philosophy.

The Score That Refuses to Flatter#

All of this discipline needs measurement, and this is where the UTIOM family departs hardest from the industry. Most maturity models are self-congratulation machines: answer optimistically, score high, present the chart. TID-CMM is built so that it cannot flatter you — through integrity constraints that only ever lower a score, never raise it:

Evidence ceilings. A rapid self-assessment — answers from team knowledge, no artifacts — cannot score above 3.00, no matter how confident the answers. Scores above 3 require named evidence: a specific test report, a specific validation exercise, a specific artifact someone is accountable for. Claimed capability and proven capability are different numbers, and the model keeps them different.

No grading your own homework. If the assessment tool suggested your threat scope and you simply accepted it, your threat-intelligence score is capped — because a model that supplies its own input and then scores you on it has measured nothing. Your threat model must be chosen, deliberately, by you. That constraint is Mintzberg's strategy-as-pattern, enforced in software.

Validation gates. Detection that has never faced adversarial emulation cannot claim the upper levels, whatever the rule count. The purple team is not an enrichment activity; it is the price of the score.

This is the same honesty the engineering practices build in — the V-Model's evidence discipline, effectuality testing, meta-detections — expressed as arithmetic. It is also why a TID-CMM score is worth defending in front of a board, and a rule count is not. And these instruments are not a sales funnel: The model, workbooks and assessment tool are publicly available and free to use under TID-CMM’s published licence terms, and the assessment runs entirely locally in the browser. The honesty is the product.

Why This Makes UTIOM Different#

Most frameworks tell you what to detect and leave the how to vendors. UTIOM does something more durable — in the book's own words: "UTIOM standardizes the lifecycle and engineering discipline, not the threats or detections themselves." Threats change weekly. Discipline compounds for years.

Design, don't assemble. Detection should be built with purpose, not patched with panic.

That is the second difference — and it is the one your adversary will notice first.

The next chapter follows this engineering discipline across the alert boundary, into response.