Security operations: An infinite problem space isn't a staffing problem
TL;DR: If you're building for everyone, you're satisfying no one. Your detection program has infinite scope because nobody defined who it actually serves. Every hire, tool, and process layer added before answering that question accelerates the problem.
Here is what your detection program is being asked to do simultaneously:
- Identify confirmed active threats with enough fidelity that incident response can act immediately
- Maintain a long-horizon behavioral corpus for insider risk investigation
- Demonstrate control coverage for every framework your compliance team is measured against
- Generate high-recall signal that gives threat hunters a starting point for hypothesis-driven investigation
- Map coverage to business risk so owners can answer "are we protected" in board language
- Confirm within 24 hours that any TTP mentioned in the news is either covered or in queue
- Intersect detection coverage with unpatched vulnerability surface for risk prioritization
- Operate within legal constraints that vary by jurisdiction and may contradict each other
Read that list again. Then ask whether the people making those requests understand they're all pointing at the same team.
This is a scope problem, not a capacity problem
A team trying to do all of the above simultaneously doesn't have a capacity problem. It has a scope problem. The backlog that never empties is what infinite scope looks like from the inside, not a staffing failure. You cannot hire your way out of it. Every analyst added, every tool deployed, every process improved before addressing the scope question executes the confusion at higher velocity.
The detection program becomes a catch-all not because anyone decided it should. It happens because it's often the only team with the telemetry and tooling to answer questions that don't belong anywhere else, and because nobody decided otherwise. Scope accumulates by default, one reasonable-sounding request at a time.
Some of these drivers don't just compete for priority. They point in opposite directions. Consider a multi-national org where compliance frameworks mandate specific monitoring controls while privacy law in certain jurisdictions restricts exactly that monitoring. The detection program absorbs the tension either way.
What actually matters is who funds the mission. Every other request, however well-intentioned, is unfunded opinion. Handle it professionally. Don't treat it as equivalent to funded accountability.
Forced prioritization: what it looks like from the outside
Specialist vendors pick a lane not because they're disciplined but because the commercial relationship forces it. MDR vendors optimize for IR. Compliance monitoring platforms optimize for control evidence. UBA platforms optimize for behavioral baselines. Someone is paying for a specific outcome and that payment creates clarity the enterprise SOC never has to achieve on its own.
Product selection is clarifying for exactly that reason. Scoping down to what a specific tool will solve forces a question your internal program has probably never had to answer explicitly: what are we actually optimizing for?
The enterprise SOC never faces that question directly. It accumulates drivers because unfunded accountability gets treated the same as funded accountability. Comprehensive on paper. Underperforming everywhere in practice.
Every capability investment made before answering this question makes it worse
This pattern predates any specific technology wave. SIEM was supposed to centralize visibility and solve the coverage problem. SOAR was supposed to automate response and close the analyst capacity gap. Each delivered real capability. Each also accelerated the underlying scope problem because the scope problem was never addressed directly. The new tool executed the confusion faster and at larger scale.
The reason: every tool has different design requirements depending on what it's optimizing for. A triage system built for IR looks completely different from one built for compliance evidence collection. An alert queue designed for hunter-accessible high-recall signal is actively hostile to an IR team working confirmed threats. Without a defined primary customer, coherent design decisions are impossible. You build something that serves nobody well rather than somebody well.
The question isn't whether to invest in new capability. It's whether you've done the work to tell that capability what success looks like before you deploy it.
What to do with this
You can't fix what you haven't named. That's true whether you're the person who can redefine the program's scope or the person who has to operate inside it while building toward that authority.
Naming the problem precisely is the first move, not a preliminary to the real work. With a clear diagnosis you can push back on a poorly scoped request with a framework instead of just friction. You can make the prioritization case to leadership by articulating what the unprioritized state actually costs rather than asking them to take it on faith. You can evaluate a capability investment or an outsourcing decision against a defined success criterion instead of a vague sense that it should help.
Practitioners rarely have the authority to reject requests outright. What you can do is stop delivering a unified output to everyone. Tailoring what you produce to who receives it: a high-confidence feed for IR, high-recall signal for hunters, coverage mapping for compliance, starts a conversation about what each customer actually needs. That conversation is how scope gets defined from the bottom up when it hasn't been defined from the top down.
If you have authority to act: three moves. Identify who funds the mission and make that primary customer explicit, written down and visible, not just understood. Tier the remaining drivers honestly. Some can be answered by the same program with different reporting surfaces. Some belong on dedicated platforms. Some need a professionally delivered no. Where drivers conflict structurally, surface the conflict so the right people make an informed risk acceptance decision rather than letting it get encoded invisibly into detection logic by whoever wrote the rule last.
If you're building toward that authority: every well-reasoned pushback on an infeasible request, every clearly articulated cost of undefined scope, every time you name the game accurately to someone who hasn't named it yet is how the leverage accumulates.
The programs that perform well aren't the ones with the most coverage or the most capability. They're the ones that know what they're optimizing for and make every decision against that standard. That clarity doesn't arrive with the next tooling cycle. It's a choice, available before the next capability wave arrives and accelerates whatever hasn't been resolved.
Appendix: Who is asking what from your detection program
| Driver | What they actually want | Where it belongs | Compatible with IR-first? |
|---|---|---|---|
| Senior IR | Confirmed active threats, low noise | Core SOC mission | Yes: this is the primary customer |
| Insider risk / UBA | Behavioral baselines, long-horizon corpus | Dedicated UBA platform | Partial: shared telemetry, separate analysis |
| Compliance | Control checkboxes, audit evidence | GRC tooling + compliance reporting layer | Partial: coverage mapping, not alert queue |
| Business owners | Risk-mapped coverage by business impact | Threat modeling + coverage dashboard | Yes: informs prioritization |
| Threat hunters | High-recall signal, weak indicators | Detection program with explicit high-recall tier | Yes: different queue, same data |
| Intel / news chasers | Confirmation that this week's TTP is covered | Catalog query interface | Yes: answered without touching the alert queue |
| Vulnerability mgmt | Exploitability intersected with unpatched surface | Risk-scoring integration, not detection | Indirect: informs priority, not rules |
| Legal / privacy | Data handling constraints by jurisdiction | Governance layer above detection program | Must be resolved before engineering |
| Regulators / compliance frameworks | Mandated controls regardless of feasibility | Compensating control narrative where detection isn't viable | Requires explicit gap documentation |
No comments:
Post a Comment