Driftline’s quarterly review was going the way their demos usually went: graphs up, churn down, the anomaly models earning their salaries. Then the external auditor asked one question that none of the dashboards answered — why a hardening finding on the build runners had been open for 291 days. Priya, who runs the platform team, had no good reply. The company sells anomaly detection and still could not get its own queue moving. What they were missing was SecOps in the contract sense: an operating agreement that binds the security function to the people who actually run the systems, with owners, dates and evidence named in writing. The story of how a confident AI vendor grew that agreement is a useful caution for anyone who believes good tooling is a governance plan.
A Monitoring Powerhouse With an Ownerless Queue
Driftline’s security operations centre is genuinely good. Detections fire in minutes, analysts are staffed around the clock, and the SIEM dashboards are the envy of their customers. The gap sat one layer down. Findings from the vulnerability scanner were exported to a spreadsheet, discussed in a meeting, and then trusted to soak. “The SOC will catch it” had quietly become the estate’s risk strategy — a phrase that belongs on a list of anti-patterns, because detection is not remediation and a console defines no owners and no timeframes. A platform, however clever, supports the monitoring function; it cannot sign obligations on its behalf. That distinction is the whole difference between owning a tool and holding a SecOps agreement.
SecOps as an Operating Agreement, Not Another Console
The Ops Atlas, in sorting out a term that NIST has never standardised, settles on the collaboration meaning: not the monitoring centre itself, and not Google’s renamed product, but the working arrangement between security and IT operations. For Driftline, translating that into a two-page document took one afternoon and changed more than a year of meetings had. Four clauses made the cut.
- Baselines chosen per platform from published benchmarks, tailored and recorded.
- One queue. Every finding gets exactly one owning team and one date.
- Exceptions expire. Each carries a justification, a reviewer and a review date.
- Joint numbers. Both teams read the same scorecard, monthly.
Nobody merged the teams, because merging was never required — the contract suffices. Nobody outsourced the clauses either: an MDR provider watches telemetry and can page people, but it does not absorb remediation, hardening or risk acceptance. Those stay in-house or they stay undone.
The July 2024 Reminder That Security Changes Are Changes
The event that finally made the argument for them happened to the whole industry. On 19 July 2024 a content update for a widely deployed endpoint sensor went live between 04:09 and 05:27 UTC and crashed Windows hosts running sensor version 7.11 and above. The subsequent recommendation was pointed: customers should hold control over how rapidly such content deploys into their estates. Driftline runs endpoint agents of exactly this class — their strengths and failure modes are covered in this overview of the Falcon platform — so the lesson landed close to home. Security tooling ships changes like any other software, and a SecOps agreement treats it that way: through rings, with windows, and with a rollback answer ready before the rollout, not after.
Rings Before Rollout: SecOps Change Discipline
Driftline’s first hardening push under the new agreement followed a sequence worth copying.
- Pick the benchmark and tailor it; record every deviation with a reason.
- Run the tailored policy in log-only mode on a pilot ring and let it cool off for two weeks.
- Read what the logs caught, adjust, then enforce ring by ring.
- Watch drift afterwards and re-review the baseline yearly.
Microsoft’s documentation says teams can usually promote the standard-protection ASR set straight to Block or Warn with no test cycle, which saves real time, and Driftline took the shortcut — but the rings survived anyway, because trust in a control is earned per estate, not per vendor. The value showed up in the counter-metric: disruptions attributed to security changes, tracked alongside on-time remediation. Across one quarter the score stood at three disruptions in 120 changes, and all three traced to a single estate-wide baseline pushed without a pilot ring. One number, one obvious fix.
SecOps Trust Boundaries: Guard the Agents and the Tokens
The agreement’s sharpest clause came from an argument nobody won until they wrote it down. Scanning engines run as root or SYSTEM. Orchestration tokens can isolate hosts and push configurations. Whoever can edit the routing rules decides which findings reach a human — which means an attacker, or a careless edit, can make an entire class of problems disappear without a trace. Driftline now treats those assets the way access reviewers treat domain admin: named holders, break-glass procedure, and every routing-rule change reviewed by a second person. Teams that model detection coverage drift the way machine-learning people model out-of-distribution inputs, as explained in this piece on OOD data, will recognise the shape: silent divergence between what you believe the system sees and what it actually sees.
What the Contract Bought Them
Twelve months later the numbers read differently. The build-runner class of findings has a permanent owner and a resourced window. Exceptions are counted, and the count past review date trends toward zero because the monthly scorecard names the laggards. The monitoring centre gets the telemetry floor it was promised, and operations gets change slots it agreed to in advance. Governance frameworks come and go — the survey of where AI governance is heading in enterprise security practice makes that clear — but a signed SecOps agreement ages well precisely because it is boring: owners, dates, evidence. For the reference definition the team keeps pinned in their wiki, they use the Ops Atlas’s SecOps entry, which is where this whole reading of the term comes from.
Driftline still sells anomaly detection. The difference is that the company no longer confuses seeing a problem with being structurally unable to ignore it. That is what the contract did: it made ignoring expensive, and fixing ordinary.