RobotnixAcademy

Week 10 · lesson

Threats Are Paths Through a System

A threat is more useful when it is tied to a mechanism.

“Hackers could attack the server” tells you almost nothing.

A stronger scenario says:

An account assigned the wrong role could receive update permission intended only for operators, allowing unauthorized modification of match notes.

Now you have a path:

IDENTITY
   ↓
ROLE ASSIGNMENT
   ↓
AUTHORIZATION DECISION
   ↓
DATA CHANGE

A control can interrupt that path.

Use bounded threat scenarios

For a high-school defensive course, we do not need step-by-step exploitation procedures.

We need enough mechanism to reason about architecture.

A useful format is:

Condition — what must be true?
Path — which components/boundaries are involved?
Impact — which required property can be harmed?
Evidence — what would reveal or disprove the condition?
Control opportunity — where can the path be interrupted?

Scenario 1: excessive role

Condition:

viewer account accidentally assigned operator role

Path:

account → role map → update endpoint → database row

Potential impact:

integrity of match notes

Evidence:

  • role-assignment record;
  • authorization log;
  • update event;
  • change history.

Potential controls:

  • least-privilege role mapping;
  • approval for privileged role changes;
  • authorization checks on the service;
  • alert on unusual privileged assignment;
  • immutable/auditable change record.

Scenario 2: public endpoint exposes admin function

Condition:

admin interface unintentionally bound to a public-facing network path

Path:

public network → service binding → admin interface

Potential impact:

  • larger attack surface;
  • unauthorized interaction attempts;
  • increased exposure of privileged interface.

Notice we did not explain how to attack it. We explained why the architecture violates the intended boundary.

Scenario 3: logs stop arriving

Condition:

application continues serving requests but log forwarding fails

Potential impact:

  • reduced detection;
  • weaker troubleshooting evidence;
  • incomplete audit trail.

This is a defensive failure even if the application stays online.

Scenario 4: backup exists but cannot restore

Condition:

backup job reports success but restore procedure has never been tested

Potential impact:

  • false confidence in recoverability.

Control opportunity:

  • periodic restore test using a disposable environment;
  • evidence of file integrity and usable application state;
  • documented recovery time.

Security includes the ability to recover, not just prevent.

Threat paths can share controls

One control may reduce several scenarios.

For example, a strong identity lifecycle process may reduce:

  • excessive privilege;
  • stale accounts;
  • orphaned access;
  • unclear accountability.

But do not claim a control solves a threat unless the mechanism matches.

A password policy will not fix an accidentally public service binding.

A firewall will not fix corrupted backup content.

Activity: write four threat paths

Using your Week 10 architecture, write four scenarios from different categories:

  1. identity/authorization;
  2. service exposure/configuration;
  3. monitoring/evidence failure;
  4. availability/recovery.

For each, fill:

Condition:
Components:
Trust boundary:
Required property at risk:
Observable evidence:
Control point:
One limitation:

Avoid dramatic language. A threat model is engineering documentation, not a movie trailer.

Rank with reason, not fear

You may prioritize scenarios using a simple classroom matrix:

impact: low / medium / high
likelihood in this fictional environment: low / medium / high

But scores need justification.

“High because cybersecurity is scary” is not evidence.

A stronger justification might be:

Role assignment is performed manually by several staff accounts and the current design has no approval record, so accidental excessive privilege is plausible within the fictional operating model.

The wording names a system condition.

Do not confuse threat with vulnerability

A threat scenario describes a harmful path or event.

A vulnerability/weakness is a condition that can make a harmful path possible or easier.

A risk combines possible harm with uncertainty and context.

These concepts overlap, but they are not synonyms.

You will revisit risk formally in Week 15.

Extend your Threat Model and Control Map

Add the four scenarios and prioritize them.

Then circle one scenario where the proposed control could accidentally break required function.

Explain how you would test both:

  • the control's defensive effect; and
  • the preserved required function.

Lesson 3 turns your scenarios into a control map.