Divan-e-Cyber

As with cybersecurity, interpretation and attribution count.

  • The Backup Model Isn’t the Backup Plan

    Hugging Face got breached in July 2026 by an autonomous AI agent that logged over 17,000 actions before anyone caught it. That story alone is worth your attention. But the detail that matters for your SOC isn’t the breach. It’s what happened when Hugging Face tried to investigate it.

    Their team turned to commercial frontier models to analyze the attack logs. The models refused. Safety guardrails built to stop malicious use also stopped Hugging Face’s own incident responders, because the requests contained real exploit payloads and C2 artifacts, and the guardrails can’t tell an analyst from an attacker. So the team pivoted to GLM 5.2, an open-weight model, running locally with no restrictions.

    Every writeup of this incident has landed on the same lesson: have a local model ready before you need one. That’s correct. It’s also not enough.

    The gate nobody’s testing

    Provisioning a backup model solves an availability problem. It doesn’t solve a competence problem. Your team can have GLM 5.2, or any open-weight model, sitting on infrastructure ready to go, and still fail the moment it matters, because nobody on the team has actually driven a raw model without the scaffolding a commercial product quietly provides.

    Commercial tools do more work than they get credit for. They structure your queries, manage context so you don’t blow past a token limit halfway through an investigation, and steer you away from prompts that produce garbage output. Take that scaffolding away and hand an analyst a bare model during a live incident, and the failure mode isn’t “the model can’t do this.” It’s “the analyst doesn’t know how to ask.”

    This isn’t a new problem. Sentence structure has been a technical control for AI security tools for a while now, not a soft skill. The same investigative prompt, worded two different ways, can produce two different answers from the same model, even when the underlying facts are identical. Swap the word order in a query about a set of user sign-ins, and you can get inconsistent results back, not because the model is unreliable, but because the syntax carrying the request wasn’t. Commercial products with prompt templates paper over that inconsistency. A raw model exposes it immediately. An incident is the worst possible moment to discover that your team never learned to write a structured prompt.

    Run the tabletop before you need it

    Here’s the exercise. Pick a realistic incident scenario, ideally one that resembles the kind of log volume and payload type in the Hugging Face case. Hand your team the local model with zero commercial tooling in front of it. No preset prompt templates, no guided workflow. Just the model and the raw data.

    Time how long it takes to get usable output. Not perfect output. Usable. Can the analyst structure a query that pulls a clear answer out of the noise, or do they spend the first twenty minutes rewording the same question because the model keeps giving them something unusable?

    That’s the test. If your team clears it fast, you’ve actually closed the gate. If they don’t, you’ve found the failure before an attacker did.

    Worth checking while you’re at it

    The operator gate is the one most teams haven’t considered, but it’s not the only one exposed by this incident. Three others are worth a quick pass:

    • Capability: can the model actually parse the type of payload you’d realistically need analyzed, or does it choke on the same content that triggered the commercial guardrails in the first place?
    • Scale: Hugging Face processed over 17,000 logged actions. Does your local setup hold up at that volume, or does it fall apart past a few hundred entries?
    • Latency: how long from “we need this analyzed” to an answer you can act on, compared to what commercial access would have given you on a good day?

    These are faster checks than the operator gate and worth running once you’ve confirmed the model is provisioned. But don’t let them substitute for the harder question.

    The model was never the gap

    Hugging Face had a model to fall back on. That’s the part everyone’s repeating. What’s less discussed is that having the model available and having a team that can drive it under pressure are two different capabilities, and only one of them shows up on a procurement checklist.

    Test the operator gate before an incident forces you to test it live.

    Sources

    Read more: The Backup Model Isn’t the Backup Plan

  • Your Detection Rules Are Artifacts. Your Tuning Decisions Are Too.

    The point up front: Every detection is actually three artifacts, not one. The rule logic, the tuning decisions, and the operational context. Most SOC teams document only the first. When the other two live in someone’s head, your institutional memory has a countdown timer on it. The fix is a single, version-controlled config artifact per rule that captures all three.

    Here’s the argument.

    The Problem: One Rule, Three Artifacts, One Documented

    A detection rule made it to Sentinel during a migration. The logic was sound. The tuning wasn’t. Thresholds and exclusions refined over 18 months of live operation were copied as hardcoded values. No documentation. No reasoning. No record of the conditions they depended on.

    Within days, alert volume spiked. The SOC couldn’t separate signal from noise. Real detections got buried. Months later, when a new engineer needed to re-tune the rule, nobody knew why the original values existed. She spent weeks reverse-engineering decisions that had already been made once, by someone who was paid to make them, who wrote them down nowhere.

    That failure happened because the team treated the detection as one artifact. It’s three:

    1. Rule logic: the pattern you’re hunting. Five failed logins in two minutes. This is the detection premise. It’s the part that lives in the rule itself, and it’s the only part most teams document.

    2. Tuning decisions: the operational choices that make the logic work in your environment. Threshold set to five because four generated noise from legitimate behavior. Service account excluded because it fails logins during batch jobs. Time window set to two minutes because that’s how fast real attacks escalate.

    3. Operational context: the infrastructure conditions that make the tuning valid. Which table the rule queries. What storage tier it runs against. Ingestion latency. Upstream DCR filtering. ASIM schema dependencies. Query cost at scale.

    These three are mutually dependent but separately owned. Lose the logic and you lose the detection. Lose the tuning reasoning and you lose the decisions. Lose the operational context and you lose the conditions under which those decisions were ever valid. A threshold of five makes sense against hot tier data with five-minute latency. It fails against cold tier data with a two-hour lag. Same number, same rule, broken detection. The rule will not send a notification about this.

    Why Now: Three Forces Compounding the Loss

    This has always been a risk. Three things make it acute right now.

    1. People are leaving faster than knowledge is captured. Layoffs have thinned SOC teams. The engineers who made the tuning decisions are gone. What they knew walked out with them, and the documentation debt they left behind compounds with every departure.

    2. Detection-as-code makes changes visible but not explained. DCRs, KQL in repos, infrastructure-as-code pipelines. You can see that a threshold changed in the commit history. You cannot see why. The commit message says “updated threshold.” Very helpful. Visibility without reasoning is a false sense of security.

    3. Detection is scaling faster than documentation practices. Automation and AI tooling are multiplying rule counts and config changes. Every undocumented change is debt. The volume of debt is growing faster than any team’s capacity to pay it down manually.

    Each force is independent. Together, they mean the migration story above stops being an edge case and becomes the default outcome.

    The Fix: One Artifact Per Rule, Three Sections

    Create a config file per detection rule. Version-controlled, living alongside the rule itself. Three sections, mapping directly to the three artifacts.

    Section 1: Operational context (the conditions the rule depends on)

    • Data source and table (CommonSecurityLog, SecurityEvent, etc.)
    • Storage tier and retention
    • Expected ingestion latency
    • DCR and upstream filtering that shapes what data arrives
    • ASIM schema dependencies, including any vendor-specific fields
    • Approximate query cost and performance constraints

    Section 2: Tuning decisions (the choices made within that context)

    • Threshold value, when it was last changed, and by whom
    • The reasoning: what incident, noise pattern, or analysis produced this value
    • Each exclusion, its reasoning, and the conditions under which it stops being valid
    • The dependency: which operational context items this tuning assumes stay true

    Section 3: Change log (the memory itself)

    • Date, author, what changed, why
    • Not the git diff. The reasoning behind the diff. The part that currently lives in a Slack thread from 2024 that nobody can find.

    That’s it. No new tooling. No platform lift. The structure matters less than the consistency. What matters is that every decision and every dependency exists somewhere other than a person’s head.

    The Test: Three Questions Against Your Oldest Rule

    Audit one rule this week. Pick the detection that’s been in your environment the longest, and ask:

    1. Could someone else understand why the threshold is set where it is, without asking you?
    2. Could they re-tune it safely if the operational conditions changed, knowing which constraints have to stay true?
    3. If they had to rebuild it tomorrow, how much of your knowledge would they waste time rediscovering?

    Any “no” means the knowledge is already lost. You just haven’t been forced to notice yet. The next migration, reorg, or departure will handle that part on your behalf.

    Three artifacts. One config file. Start with one rule.

    Read more: Your Detection Rules Are Artifacts. Your Tuning Decisions Are Too.

  • Part 3: Who Closes the Second Loop?”

    Series: Part 3 of 3

    Parts 1 and 2 of this series made two arguments.

    First: CTEM’s mobilization stage closes the loop on findings. It doesn’t close the loop on fixes. AI-proposed remediations re-enter your codebase as unverified code, and most vulnerability management workflows have no process for that.

    Second: fix verification isn’t a single control. It’s a tiered risk decision — automated rescan gates for bounded, well-understood fixes; senior practitioner review for complex logic, critical assets, and AI-generated code where no human holds a complete mental model.

    This part asks the operational question both of those arguments were building toward: who actually runs this, and what does it take to do it reliably?

    What the Model Requires

    Be honest about what Tier 1 and Tier 2 verification demand before you decide how to staff them.

    Tier 1 is an engineering problem.

    Running MDASH as a post-fix pipeline gate requires integration work. The CLI needs to be embedded in your GitHub Actions or equivalent pipeline. The rescan needs to run against the fix branch before merge. Pass/fail criteria need to be defined and enforced. Results need to feed back to the same initiative dashboard your security team is already using.

    None of this is technically complex. All of it requires someone to own it, build it, and maintain it as the toolchain evolves. In most organizations, that work sits in a gap between the security team and the platform engineering team, which means it either doesn’t get built or it gets built once and quietly degrades.

    Tier 2 is a people problem.

    Senior practitioner review against defined criteria requires practitioners who can sit at the intersection of security depth and code comprehension. They need to understand what MDASH found, why Copilot proposed the fix it did, whether the fix scope is appropriate, and whether any net-new risk was introduced.

    That is not a common skill profile. It is not produced by a security certification path or a development career path alone. It requires deliberate development, and it requires enough volume of Tier 2 reviews to keep the skill sharp.

    Most organizations have two or three people who can do this well. That is not enough to run Tier 2 verification at the velocity AI-assisted development produces.

    Where Most Organizations Actually Are

    Across AppSec programs right now, the gap between where teams are and where this model requires them to be shows up in three places consistently:

    No post-fix scan gate exists. The pipeline runs SAST on the original code. It does not rescan after remediation. The fix merges through code review alone. This is the default state of most AI-assisted remediation workflows today.

    Tier criteria aren’t defined. Teams know that complex changes need more scrutiny. They don’t have a written threshold for what “complex” means in the context of AI-generated code, or what “sufficient comprehension” means as a reviewer qualification. The norm exists. The decision rule doesn’t.

    Mobilization metrics measure closure, not verification. Dashboards show findings closed and mean time to remediate. They don’t show whether Tier 2 criteria were met, whether the post-fix rescan was clean, or whether the practitioner who signed off had the right skill profile. The metric looks good. The control is invisible.

    None of this is negligence. It’s the natural state of a program that was well-designed for the problem it was built to solve, encountering a problem it wasn’t built for.

    The Build vs. Partner Decision

    If you’re running an AppSec program and you’ve read this far, you’re probably doing the math on what it would take to close these gaps internally.

    Here’s the honest version of that math.

    The Tier 1 integration is buildable internally for most organizations with a mature platform engineering function. It requires a few weeks of work, a defined owner, and a commitment to treat it as infrastructure rather than a one-time project. If you have the engineering capacity, build it. The tooling — MDASH, GitHub Advanced Security, Defender for Cloud — is already there. The pipeline integration is the gap.

    The Tier 2 staffing problem is harder to solve internally at scale. You can build the criteria. You can identify two or three practitioners who can run the reviews. You cannot easily scale that capacity to match AI-assisted development velocity without either hiring specifically for this profile — which the market does not have in abundance — or accepting that Tier 2 reviews will become a bottleneck that slows down the remediation cycle this toolchain was designed to accelerate.

    That bottleneck is worth taking seriously. A Tier 2 review that takes a week defeats a significant part of the value of AI-assisted remediation. Speed matters. So does verification. The operating model needs to deliver both.

    What a Mature Second Loop Looks Like

    Whether you build it internally or bring in external capacity for the Tier 2 layer, the operating model has the same shape.

    Discovery stays in your pipeline. MDASH runs on every scan surface — CLI for developer-local, GitHub Actions for the pipeline gate, agentless for running workloads. Findings roll up to the Defender for Cloud initiative view with runtime context and attack path correlation. Nothing changes here from current best practice.

    Mobilization has two explicit exits, not one. Tier 1 findings close when the post-fix rescan is clean. Tier 2 findings close when the rescan is clean AND practitioner sign-off is recorded against defined criteria. Both exits are documented in the pipeline. Neither is optional.

    Metrics reflect verification, not just closure. Mean time to remediate is still a useful metric. It is not sufficient on its own. Add: percentage of fixes with post-fix rescan completed, Tier 2 review cycle time, and practitioner qualification rate for Tier 2 reviewers. These metrics make the second loop visible in a way that finding-closure metrics don’t.

    The skill baseline is maintained deliberately. Tier 2 reviewers need regular exposure to AI-generated vulnerability classes to stay current. This is not a one-time training investment. The attack surface is evolving. The reviewer skill baseline needs to evolve with it.

    Three Things to Implement This Week

    Regardless of how you resolve the build vs. partner question, these three changes are available to any team right now:

    1. Add a post-fix rescan step to one pipeline. Pick your highest-criticality repository. Add MDASH as a gate after Copilot-proposed fixes, before merge. Run it for four weeks. Look at what it catches. That data will tell you more about your second loop gap than any assessment will.

    2. Write down your Tier 2 criteria. It doesn’t need to be perfect. It needs to exist. Define what triggers senior practitioner review — at minimum: auth/authz code, internet-exposed assets with sensitive data paths, AI-generated code above a complexity threshold. Get it into your CTEM mobilization process documentation.

    3. Change one metric. Add “post-fix rescan completed” as a condition on your finding-closure definition. Even informally, as a team norm. Closing a finding without a clean rescan becomes an exception that requires documentation, not a default that goes unnoticed.

    None of these close the entire gap. All of them make the gap visible — which is the prerequisite for closing it.

    The Actual Stakes

    CTEM works. The framework is sound and the toolchain supporting it — MDASH, Security Copilot, GitHub Advanced Security, Defender for Cloud — is the most capable it has ever been.

    The risk isn’t that the tools fail. The risk is that the operating model around the tools doesn’t keep pace with what the tools are now doing. AI-assisted remediation is faster, more contextual, and more scalable than anything that came before it. It also introduces a class of unverified code into your environment that your existing mobilization process wasn’t designed to catch.

    The second loop is closable. It requires deliberate design, defined criteria, the right skill profile at the Tier 2 layer, and metrics that make verification visible rather than assumed.

    Most programs haven’t built it yet. The ones that build it now will be ahead of a problem that is only going to get harder to retrofit later.

    The Second Loop is a three-part series on what CTEM’s mobilization stage gets wrong in an AI-assisted development environment, and what to build instead.

    Part 1: AI proposed your last fix. Did anyone scan it?
    Part 2: Fix Verification Isn’t a Code Review. It’s a Risk Decision.

    Read more: Part 3: Who Closes the Second Loop?”
poetry

🔐 Ghazal: “All Access Is Conditional”

(a modern security poem in ghazal form)

In this realm of cloud and claim, all access is conditional
The lover may knock, but still — permission is provisional

—

The gate is silent, the ID speaks, its posture holds the key
From signal comes salvation — detection is intuitional

—

Trust no device, no sign-in time, unless the risk aligns
The dance of context and control is wholly intuitional

—

Her token glowed, yet prompts appeared — a second factor asked
The veil may lift, but only when the bond is traditional

—

No open ports, no phantom guests, no silent lateral flow
My realm is built on principle, protection constitutional

—

From Persia’s gardens to Azure clouds, the guardians still remain
Their watchful eyes in every log — the shield is unadditional

—

And Mona writes, like Hafez would, of XDR and fate
To love the user is to test — the trust must be conditional*

Poetry inspired by a cybersecurity mindset

Exploring the intersection of creativity and security through poetry. Mona reflects on thoughts and lessons that shape her approach.

poetry

© 2025 Mona Ghadiri. All content, including text, images, and original poetry, is the intellectual property of Mona Ghadiri unless otherwise noted. Unauthorized use or reproduction is prohibited.