Controls Should Break a Mechanism

A security control is strongest when you can point to the exact part of a threat path it changes.

The point is not to collect controls. The point is to interrupt harmful mechanisms while preserving required function.

Three broad control roles

Preventive

Attempts to prevent or reduce the undesired condition.

Examples:

• least-privilege role assignment;
• strict service binding;
• input validation;
• segmentation;
• change approval;
• secure configuration.

Detective

Helps reveal that a condition or event occurred.

Examples:

• authentication logs;
• configuration-change records;
• alerts on privileged-role assignment;
• service-health monitoring;
• integrity checks.

Recovery / corrective

Helps restore acceptable state after failure.

Examples:

• known-good configuration restore;
• account disable/revocation;
• tested backup restore;
• rollback;
• service failover;
• incident procedure.

Strong systems often use several roles together.

Map controls directly to the path

Threat path:

wrong role
   ↓
authorization permits update
   ↓
match data changes

Control map:

role approval --------┐
                      ↓
wrong role → authorization → data change
                ↑              ↑
       service-side check    change log
                               ↓
                          recovery history

Now you can explain why each control exists.

Defense in depth is not duplication for its own sake

Two controls are useful together when they fail differently.

Example:

• correct role assignment reduces excessive privilege;
• service-side authorization verifies each sensitive action anyway;
• logging records privileged updates;
• change history supports recovery.

If one role assignment is wrong, another layer may still prevent or expose the action.

But if all controls depend on the same broken identity source, the apparent “layers” may share one failure mode.

Architecture matters.

Test controls against requirements

Suppose you restrict the database so only the application service identity may connect.

Defensive test:

unauthorized fictional client path → denied

Required-function test:

status service → database read/update according to role → still works

Recovery test:

known-good config can be restored if rule is incorrect

A control is not finished when it blocks something. It is finished when the intended boundary is tested and required function survives.

Residual risk is what remains

No realistic control removes all uncertainty.

After role approval + authorization + logging, residual risk may still include:

• privileged staff misuse;
• compromised authorized account;
• software bug in authorization logic;
• logging outage;
• configuration drift.

Recording residual risk is not admitting failure. It is refusing to pretend.

Lab: build a control matrix

For your four Week 10 scenarios, create:

Every cell does not need a control. Sometimes “none in current design” is the most honest answer.

Choose one scenario and write a verification plan with:

1. baseline state;
2. controlled changed/misconfigured state in the fictional model;
3. expected control behavior;
4. positive test;
5. negative test;
6. recovery step; and
7. limitation.

Do not perform real attacks. Use supplied identities, logs, configuration states, and deterministic test cases.

Example: privileged role assignment

Baseline:

alice → viewer
bob → operator
coach → admin

Changed state:

alice → operator   # accidental

Preventive control:

privileged role changes require coach approval

Detective control:

log event role_change old=viewer new=operator approver=...

Recovery:

restore viewer role; revoke active privileged session if policy requires

Retest:

• Alice cannot submit operator update;
• Bob can still perform required operator update;
• coach admin remains functional;
• role-change record exists.

That is a complete control story.

Finish the Threat Model and Control Map

Submit:

• architecture/data-flow sketch;
• required functions;
• assets and trust boundaries;
• four threat/failure paths;
• priority rationale;
• preventive/detective/recovery map;
• one verification plan;
• residual risk; and
• limitation.

A strong final statement:

The Week 10 model maps each proposed control to a specific fictional threat path and includes a preserved-function test. The model does not claim complete threat coverage or predict real-world likelihood outside the stated system assumptions.

That is architecture-first defense.