Control Coverage Has Gaps and Failure Modes

A control map should answer two questions:

1. Which threat/failure path does this control affect?
2. What happens when the control itself fails?

The second question is where architecture review becomes interesting.

Reuse the Week 10 threat paths

Example path:

excessive role
   ↓
privileged action
   ↓
data/configuration change

Mapped controls:

role approval        preventive
service authorization preventive
role-change log      detective
privilege alert      detective
change history       recovery/support

That looks strong until you inspect dependencies.

Shared control dependency

Suppose both the role-change log and privilege alert depend on the same collector.

If the collector is unavailable:

role-change event generated
   ↓
forwarder fails
   ↓
collector receives nothing
   ↓
alert never evaluates

Two detective controls disappear together.

This is a common dependency, not independent defense in depth.

Preventive controls can share assumptions too

Suppose:

• UI requires approval ID before privileged role change;
• API endpoint trusts the UI and does not enforce approval itself.

The architecture appears to have an approval control, but the true enforcement point is weaker than the diagram suggests.

The control map should distinguish:

policy/documented expectation

from:

technical enforcement point

Recovery controls need evidence too

A backup is not a recovery control until restore is tested against a required function.

A rollback file is not a recovery plan until:

• it is available;
• the operator knows when to use it;
• restore procedure is documented;
• the resulting system is retested.

Control coverage should include recovery verification.

Build a coverage matrix

Use columns:

Populate at least five paths:

1. excessive privilege;
2. unintended service exposure;
3. malformed data/input;
4. logging pipeline failure;
5. backup/restore failure.

Add one path of your own.

A gap is not always “no control”

Gaps include:

• control exists but is not verified;
• control depends on the same failing component as the asset;
• monitoring exists but nobody owns response;
• recovery exists but restore never tested;
• authorization exists but stale sessions preserve old privilege;
• baseline exists but change records do not update it.

Architecture review is about control quality, not control count.

Failure-mode exercise

Choose one control and ask:

If this control silently failed for one day, what evidence would tell us?

Examples:

Log forwarder

Heartbeat/queue health should reveal failure.

Role approval

Negative test should reject privileged change without approval.

Backup job

Job success + periodic restore test provides stronger evidence than job success alone.

Host firewall/policy

Defined negative and positive network-path tests should verify intended relationship after changes.

A control with no failure detector can become a source of false confidence.

Measure coverage without fake precision

Do not create a “93% secure” score.

Use categories with rationale:

• covered and verified;
• covered but not recently verified;
• partially covered;
• uncovered;
• unknown — evidence missing.

These categories are more honest than a made-up percentage.

Identify five review findings

Write findings in this format:

Condition: role-change alert and audit search both depend on the same log collector.
Risk: a collector outage can remove both detection and investigation evidence for privileged changes.
Evidence: Week 13 pipeline model + Week 14 rule dependency.
Current controls: forwarder heartbeat.
Gap: no independent alert that the collector itself stopped ingesting privileged events.
Recommended next step: add collector/source freshness check and verify it with a safe synthetic canary.

Now the finding is actionable.

Extend your Defensive Architecture Review

Add:

• six threat/failure paths;
• control coverage matrix;
• shared dependencies;
• control failure indicators;
• five evidence-backed gaps;
• current residual risk;
• verification status for each control.

Lesson 3 turns those gaps into a prioritized architecture decision package.