You Cannot Defend What You Have Not Modeled

A security product cannot tell you what matters to the system owner.

A scanner cannot tell you which function must keep working during a failure.

A firewall rule cannot tell you whether two components were supposed to communicate in the first place.

Those questions belong to architecture.

Start with required function

Consider a fictional organization called Northstar Robotics Club.

Its simple status platform has:

• student laptops that view public robot status;
• an operator workstation that updates match notes;
• a status web service;
• a database holding fictional match data;
• an admin interface used only by coaches;
• log collection; and
• backups.

Before talking about threats, define the important functions:

1. public viewers can read approved status information;
2. operators can update match notes;
3. ordinary viewers cannot change records;
4. admin functions are limited to authorized staff;
5. logs support troubleshooting and security review;
6. backups can restore the required dataset.

Security exists to preserve required properties of a system — not to maximize the number of tools installed.

Inventory assets by role, not only by device name

An asset is something valuable enough that its loss, corruption, disclosure, or unavailability matters.

Examples:

A server is also an asset, but a good inventory goes deeper than hardware.

Draw data flows

A simple architecture:

PUBLIC VIEWER
     |
     | HTTPS read
     v
STATUS WEB SERVICE --------> LOG STORE
     |
     | application query
     v
DATABASE

OPERATOR WORKSTATION
     |
     | authenticated update
     v
STATUS WEB SERVICE

COACH ADMIN
     |
     | privileged admin action
     v
ADMIN INTERFACE

Now the system has relationships you can inspect.

Mark trust boundaries

A trust boundary is a place where assumptions, authority, ownership, or control change.

Examples in this model:

• public browser → web service;
• operator workstation → authenticated application session;
• web service → database;
• admin user → privileged interface;
• application → log system;
• production-like data → backup storage.

A boundary does not mean one side is “evil.” It means the receiving side should not blindly inherit assumptions from the sending side.

Ask what crosses each boundary

For every flow, write:

source
destination
data/action
identity or authority carried
expected direction
required protection
evidence available

Example:

source: operator workstation
destination: status web service
action: update match note
authority: authenticated operator session
required protection: confidentiality/integrity in transit + authorization at service
evidence: request ID, operator identity, update result

That is an architecture statement that can later be tested.

Availability is part of the model too

Threat modeling is not only about unauthorized access.

Failures can include:

• database unavailable;
• disk full;
• certificate expired;
• backup unusable;
• dependency timeout;
• configuration mistake;
• loss of network path;
• accidental privilege assignment.

Defensive systems engineering includes accidental and environmental failure because the required function does not care whether the cause was malicious.

Activity: build the Northstar asset model

Create a table with at least eight entries:

Then draw at least five arrows showing flows.

For each arrow, label the action or data, not just “network.”

Bad label:

HTTP

Better label:

read status

or:

authenticated note update

Protocol and purpose are both useful.

Architecture prevents fake fixes

Suppose someone proposes:

Block the database from the network.

If the web service legitimately needs a database connection, that control may destroy the required function.

A better question is:

Which component actually needs database access, over which path, using which identity, for which operations?

Now you can reduce access while preserving function.

Begin your Threat Model and Control Map

Include:

1. required functions;
2. at least eight assets/components;
3. five or more data/action flows;
4. trust boundaries;
5. privileged identities;
6. important dependencies;
7. evidence sources; and
8. one function that must survive a partial failure.

Lesson 2 will use this architecture to build realistic threat paths.