Threat-Informed Defense Strategy

At 09:20, a release engineer approves a routine deployment. The artifact is correctly signed, the pipeline is green, and the change reaches production through the expected identity. What nobody sees is that the identity was stolen the night before. The artifact contains a new export path, and the same deployment role can read the secret that opens the tenant-data store.

The organization can point to MFA, code review, signed artifacts, centralized logging, and tested backups. Every control exists. The attacker can still move from one trusted step to the next.

Threat-informed defense asks a harder question than whether controls are present: against a named attack path, where will the system stop the attacker, reveal the attempt, support a decision, and restore trust?

Name the path before choosing the controls

Begin with something the organization cannot casually lose: tenant data, the production control plane, signing authority, identity recovery, or the ability to restore service. Then give the adversary a goal and a plausible starting condition. “Protect CI/CD” is a control domain. “Use a stolen release identity to introduce a tenant export and conceal it as a normal deployment” is a scenario the team can reason about.

Write the path as a sequence of state changes. In this case, the attacker must:

1. obtain or reuse release authority;
2. place malicious behavior in an artifact that production will accept;
3. use the workload’s identity or secrets to reach tenant data;
4. export enough data to create material harm; and
5. delay investigation by blending into expected release and service activity.

Initial access, privilege escalation, lateral movement, data access, exfiltration, destructive action, and recovery interference are useful names when they fit the path. Public ATT&CK techniques can give teams a shared vocabulary and reveal missing stages, but the catalog is not the defense model. The local identity edges, data routes, owners, and recovery dependencies decide whether a technique is possible here.

The path also has assumptions worth writing down. The stolen identity is still valid. The pipeline accepts a release without a second independent authorization. The workload can obtain credentials with broader data access than its normal request path requires. Deployment and bulk-export events arrive in time to matter. If any assumption is false, that is a control to verify, not a reason to abandon the scenario.

Let intelligence change the queue

Threat intelligence earns attention when it changes which path the team fixes or tests next. Inputs may include incident history, abuse and customer reports, bug-bounty findings, sector reporting, vendor advisories, public ATT&CK techniques, and authoritative records of vulnerabilities under active exploitation. Current campaigns and exploited-vulnerability claims require current authoritative sources; a durable scenario should not depend on a news item remaining current.

Turn each useful input into a proposed change to an existing scenario: raise its priority, add a newly observed entry path, revise an assumption, demand a telemetry source, or retire an implausible branch. The owner then weighs exposure, asset value, existing weakness, possible harm, and recovery difficulty. A report that changes none of those things may be informative, but it has not yet become defensive work.

This keeps the scenario set deliberately small. Five paths that have owners, evidence, and recent exercises are more defensible than a comprehensive technique inventory whose cells mean only “a product claims coverage.”

Follow each step through the defense

Now ask what happens at every transition. Prevention should make the transition impossible or narrower. Detection should observe evidence that the transition was attempted or completed. Response should name a decision and an authority, not merely “investigate.” Recovery should say how the team re-establishes a trusted state and proves the result.

For the release scenario, the first pass might look like this:

The matrix is a claim about a system, not a list of aspirations. Every cell needs an owner and a way to produce the proof in its final column. A blank cell is useful when it exposes an owned, prioritized gap. A filled cell with no test is merely disguised uncertainty.

Coverage is not strongest where the most cells are filled. The release path still has a dangerous coupling: ordinary deployment authority can lead to broad data access. Improving an alert does not remove that edge. Separating export authority or narrowing workload access may collapse several later attack steps at once. Attack-path analysis helps the team prefer such structural changes over a stack of compensating detections.

Draw only the edges that change a decision

An enterprise graph can become too large to challenge. Keep the working path short enough to inspect. For each step, record the source identity or system, the destination, the authority or reachability that connects them, the prerequisite state, the control expected to interrupt the move, and the evidence that would confirm or refute it.

Trace across boundaries that are usually reviewed separately: public exposure to identity, identity to source control, source control to CI/CD, CI/CD to the cloud control plane, workload identity to data, and production to backups and evidence. Include recovery edges. An attacker who can delete the only clean backup or rewrite the only audit record can turn a contained compromise into an uncertain recovery.

Stop drawing when another edge would not change a fix, a detection, a response decision, or an exercise. Record excluded branches and why they are lower priority. The artifact should help an owner choose work, not pretend to be a complete map of the organization.

Rehearse the uncertain transition

The team suspects the stolen release identity would look ordinary. That is the uncertainty worth exercising. A bounded purple-team plan uses an approved test identity and inert artifact in a non-customer environment that emits production-equivalent telemetry. The plan names the systems and time window, permitted actions, prohibited data and destructive actions, safety observer, communication path, evidence to preserve, expected events and alert, response owner, stop conditions, cleanup, and rollback.

Do not tell the monitoring team the exact timestamp if the exercise is meant to test discovery. Do tell the responsible operators enough to prevent the simulation from becoming an unauthorized incident. The purpose is to observe the defense, not to reward surprise.

Suppose the artifact-digest alert arrives in four minutes, but it routes to a queue nobody owns. The export anomaly never fires because the test environment omits tenant identifiers. Containment relies on disabling the entire release system, and nobody can say whether doing so will block an emergency repair. Those are not exercise footnotes. They become engineering work: assign the route, repair environment parity, create a bounded suspension procedure, and test the procedure again.

Record actual timestamps and decisions rather than a verdict such as “exercise passed.” Preserve the simulated action, telemetry arrival, alert creation, acknowledgement, containment decision, recovery validation, observed gap, owner, due date, and retest result. That history shows whether coverage is improving or only being discussed.

Keep coverage aligned with the system

Threat-informed defense decays when its scenarios remain fixed while the architecture moves. Revisit a path when exposure, identity, data flow, deployment authority, evidence storage, recovery design, incident history, or current threat inputs change. A renamed role can break a detection. A new export feature can create a shorter path. A migration can retire a data source while leaving the coverage matrix looking complete.

Three failure patterns deserve suspicion. Compliance-only defense counts safeguards without testing how they compose along an attacker path. Passive intelligence circulates reports without changing a scenario or work queue. Tool-reported coverage treats a product’s technique label as proof that local telemetry, routing, containment, and recovery work. In each case, activity substitutes for an observed defensive capability.

The record to keep

For each priority scenario, keep one working record containing:

• the critical asset, attacker goal, path, assumptions, and excluded branches;
• the system and identity edges that make each transition possible;
• prevention, detection, response, and recovery claims for every material step;
• the owner, evidence, review trigger, known gap, priority, and due date;
• the authorized exercise plan and its safety limits; and
• the most recent observed result, corrective work, and retest date.

The record is ready to guide work when a team can point to the weakest transition and decide whether to remove the edge, narrow it, observe it, prepare containment, or improve recovery. If nobody can produce evidence for a cell, the uncertainty is the finding. If nobody owns the finding, the path is not covered.