Detection drift at MSSP scale
Forking rules per client doesn't scale past a dozen tenants. A short note on why we track drift instead.
When you onboard your tenth client and they want “just one tweak” to a Sentinel rule, you have a choice: fork the rule, parameterize the rule, or refuse the tweak. Most MSSPs fork. We tried that for about a year before the math broke.
The fork tax
Every forked rule is a separate code path: separate tuning history, separate false-positive accounting, separate maintenance burden when the upstream rule updates. Multiply by 30 clients and a few hundred rules and you have a content backlog you cannot staff.
Drift, not forks
What we do now: keep one canonical version of each rule, ship it everywhere, and track per-tenant drift as data. If a client needs a parameter override, the override lives on the deployment record, not the rule. The rule stays single-source.
This means:
- Upstream improvements propagate without merge conflicts
- Drift becomes a query, not a code audit
- Tuning history aggregates across the tenant base — we see which parameters get tuned most often, and that informs the next canonical version
The hard part
The hard part isn’t the schema. It’s getting your engineers to stop forking when a client asks. Forking feels like service; it’s actually a debt you’re charging the next engineer.