Every SOC has a graveyard, and it’s not the one with the decommissioned rules. It’s the tag field. Go open your detection platform right now and search by tag. Go on. You’ll find apt sitting next to APT sitting next to apt29 sitting next to cozy-bear-maybe, four analysts’ worth of vibes masquerading as a taxonomy nobody agreed to. Somebody typed test into a tag field eighteen months ago and it is still there, load-bearing, referenced by exactly one dead rule that nobody will delete because deleting things is scary and tagging things is free.
This is the part of detection engineering nobody puts in the conference talk. Everyone wants to demo the AI-assisted rule generation and the fancy coverage heatmap. Nobody wants to admit that underneath all of it is a folksonomy built by whoever was on shift, with zero governance, that has quietly become the primary way your team finds anything. Search is not a nice-to-have UX layer bolted onto detection content. Search is the interface to your entire detection program for anyone who isn’t the person who wrote the rule. And most platforms let that interface rot.
The lie of “we have tags, therefore we have organization”
Tags feel like structure because they look like metadata. They are not structure. Structure implies a schema, a controlled vocabulary, someone whose job it is to say “no, we already have a tag for that, use credential-access instead of inventing creds-stuff.” Without that enforcement layer, tags are just free-text fields with delusions of grandeur. They accrete. They never get pruned. And because nobody owns the taxonomy, everybody owns it a little bit, which in practice means nobody does.
We’ve crawled tenants where a single detection platform carried over 40 distinct tags in active use across one workbench hub — ATT&CK technique tags, platform tags, implementation tags, and a pile of ad-hoc custom ones invented under a detect:: prefix by whoever felt like it that week. Forty-plus tags is not a taxonomy. It’s an inbox nobody’s cleaned since onboarding.
And here’s the failure mode that actually bites you in an incident: when tags rot, search rots with them, and when search rots, your analysts stop trusting it. Once an L1 analyst learns that searching “lateral movement” misses half the relevant rules because someone tagged theirs “lat-move” instead, they stop searching. They start scrolling. Or worse, they start asking in Slack, because at least a human gives them a straight answer instead of a broken index. Congratulations, you’ve built a search feature that trained your own team to route around it.
Filters are not a substitute for curation
The other lie is thinking that adding more filter dropdowns fixes a bad taxonomy. It doesn’t. A filter is only as good as the field it’s filtering on. If your tag field is a swamp, your “filter by tag” control is a swamp with a UI on top. We’ve watched teams respond to messy search results by shipping more filter chips — author, status, technique ID, repository, sort order — as if surface area compensates for garbage underneath. It doesn’t. It just gives you more precise ways to filter a garbage set down to a smaller garbage set.
The actual fix is boring and nobody wants to fund it: someone has to own the vocabulary. Tags need a lifecycle too — the same discipline you’d apply to a detection rule (proposed, reviewed, merged into the controlled set, deprecated, retired) has to apply to the metadata describing that rule, or the metadata becomes exactly as untrustworthy as an unreviewed detection would be. We spent real effort making Review Workflow and Lifecycle mean something in HEFAISTOS — gating states, peer review, approval — and then almost shipped a tagging model with none of that discipline, because tags feel low-stakes. They aren’t. A detection with the wrong ATT&CK technique tag is invisible to every coverage calculation that depends on that mapping. That’s not a cosmetic bug, that’s a false sense of coverage.
What we actually did about it in HEFAISTOS
Workbench Hub in HEFAISTOS exposes search by title or tag, plus status, author, and ATT&CK technique filters, and — this is the part that matters — tags are clickable and pivot you directly into Rule Hub filtered on that same tag. That sounds like a small UX detail. It’s not. It means a tag isn’t a dead-end label sitting in a detail pane; it’s a live pivot point that has to resolve consistently across two different surfaces of the platform. If your tag taxonomy is inconsistent, that pivot breaks in an obvious, visible way — you click a tag expecting five related rules and get zero, or fifty unrelated ones. That visibility is a feature. A taxonomy that only has to look coherent in one screen will always be worse than one that has to survive being clicked through into a second one.
Rule Hub layers the same filter set on top — free text, author, repository, status, technique ID, tags — because search across a growing rule repository needs more than one axis or it collapses back into “scroll and pray.” None of this fixes a bad taxonomy by itself. What it does is make a bad taxonomy observable, which is the precondition for someone actually fixing it instead of shrugging and adding another filter chip.
The bug we found while building this
Full disclosure, because pretending we shipped this perfectly would make us exactly the kind of platform we’re roasting: early on, technique-ID filtering and tag search lived as two half-related code paths that agreed most of the time and quietly disagreed at the edges — a rule tagged with a technique ID wouldn’t always show up when you filtered Workbench Hub by that same technique via the ATT&CK filter, because one path trusted the tag string and the other trusted the structured technique field, and nothing forced them to reconcile. It’s the exact failure mode this whole article is about: two sources of truth for the same fact, drifting apart in silence until someone searches for something they know exists and gets nothing back. We fixed it by making the structured technique mapping the source of truth and treating the tag as a derived label, not the other way around. If your platform lets free text and structured fields disagree indefinitely, you don’t have search, you have a coin flip with a search bar’s clothes on.
Do this instead of trusting your tag cloud
- Audit your tag field the way you’d audit a rule set — for duplicates, dead entries, and case-sensitivity nonsense that splits one concept into three tags.
- Make technique/ATT&CK mappings structured fields, not free-text tags, and treat tags as a display layer derived from structure, never the other way around.
- Give tag pivots somewhere real to go — if clicking a tag doesn’t take you to every related object across your platform, your tags are decoration, not navigation.
- Assign an actual owner to the controlled vocabulary. Not a committee. A person who says no.
- Periodically ask “when did anyone last search successfully by tag and trust the result?” If the honest answer is “we don’t remember,” your search feature is a placebo.
Search is supposed to be the thing that makes a growing detection program navigable instead of terrifying. Most platforms treat it as an afterthought UI feature instead of the load-bearing discovery layer it actually is, and then act surprised when analysts stop trusting it and start reinventing tribal knowledge in a Slack channel instead. Don’t be surprised. Own the taxonomy or don’t pretend you have one.
Happy tagging. Correctly, this time.
Featured image generated using Artificial Intelligence (EU AI Act transparency notice).