PARTNERS

Add selected Workbench capabilities through bounded OEM and partner integrations

Deliverablesdeliverable
deliverable

Defend Pillar Figures

Canonical figures for the Defend pillar.

Public sample
Client deliverable
public-sample
System
Defend Pillar Figures
Environment
Production pilot

# Defend Pillar Figures

DEF-01

What Defend Changes

Defend reduces dangerous authority, strengthens control boundaries, and converts remediation into retestable system changes.

Three-part figure showing qualified attack evidence, the Defend capability, and changed controls with retest criteria.

INPUTSQualified risk contextQualified paths andfailuresDangerous authoritycompositionWeak trust andpolicy boundariesUncertainty andresidual riskENGINEDefendReduceunnecessaryauthorityStrengthenapproval andpolicy gatesSegment data andaction pathsRedesign unsafeworkflowtransitionsRESULTSRetestable system changeImplementedcontrolNamedimplementationownerRetest criteriaExpected proofartifact
DEF-02

Interrupt the Paths

The highest-value control is often the chokepoint that disrupts several plausible attack paths at once.

Several attack paths converging on a shared weakness, followed by a selected control, blocked paths, and visible residual risk.

Prompt-to-tool pathRetrieval-to-actionpathDelegated-authoritypathSHARED WEAKNESSShared weaknessCONTROLSelectedcontrolPath A blockedPath B blockedPath C reducedbut noteliminatedRetest required
Path blockedReduced, not eliminatedPending retest
DEF-03

Remediation Operating Model

Security, product, platform, and engineering teams need explicit ownership for control design, implementation, and proof.

Operating model assigning risk interpretation, product decisions, platform controls, engineering implementation, and evidence signoff.

Shared Foundation
  • Security
    • Interpret evidence and consequence
    • Prioritize control opportunities
    • Define security acceptance criteria
  • Platform
    • Own identity, policy, and shared controls
    • Provide reusable guardrails
    • Instrument shared control evidence
  • Product
    • Own user and workflow impact
    • Approve product tradeoffs
    • Set rollout and exception policy
  • Engineering
    • Implement the system change
    • Add test and evidence hooks
    • Preserve regression coverage
DEF-04

Fix, Retest, Prove

A remediation is not complete until the control change is retested and the resulting evidence closes or updates the finding.

Governed remediation lifecycle from accepted finding through control implementation, retest, decision gate, closure, residual risk, or rework.

Remediation lifecycle
  1. 1
    Accept the finding
    Confirm scope, consequence, owner, and evidence state.
  2. 2
    Design the control
    Choose the least disruptive change that addresses the supported path.
  3. 3
    Implement and instrument
    Change the system and preserve the evidence needed to retest it.
  4. 4
    Retest the path
    Replay the relevant conditions, alternatives, and expected controls.
Does the evidence support closure?
  • Closed
  • Residual risk
  • Control failed
  • Inconclusive