Before You Lock the Door: Security in System Design Explained from First Principles

The suitcase is zipped. The cab is fifteen minutes away. A person reaches for the front-door key, then stops. Locking the door feels responsible, but a better question arrives first: what exactly am I protecting, and how could someone reach it? The jewellery is not threatened in the same way as the garden chair. The weak bathroom-window latch matters more than the expensive lock on a door nobody can reach.

That pause is security design in its simplest form. A team should not begin with a shopping list of login providers, firewalls, scanners, and encryption products. It should begin with what matters, what could go wrong, how the system is reachable, what the damage would be, and which protection is proportionate.

I like this starting point because it removes the drama from security. Security is not a mysterious battle between a hooded attacker and a genius defender. It is a sequence of ordinary engineering decisions made under uncertainty. The system will change, attackers will adapt, controls will occasionally fail, and the team must still protect the promises that matter.

Security starts with an asset and a path to harm, not with a security product.

The Vocabulary Map: From Something Valuable to Remaining Risk

Imagine the house again. Jewellery and documents are assets: things whose loss, exposure, alteration, or unavailability would hurt. A burglar who may target the house is a threat actor. Burglary is a threat: a possible harmful event. These words are related, but they are not interchangeable. The actor is the entity; the threat is what may happen.

The weak latch is a vulnerability: a weakness that can be exploited or triggered. The window is an entry point. Every reachable door, window, skylight, key holder, and person who can admit a visitor forms the broader attack surface. The route through the weak window is an attack vector: the method used to turn possibility into action.

A stronger latch, an alarm, a locked cupboard, and a neighbour checking the house are controls. None makes burglary impossible. They reduce likelihood, reduce impact, improve detection, or improve recovery. What remains after those choices is residual risk. Risk is not the same as fear or certainty; it is a reasoned view of likelihood, impact, exposure, and the confidence we have in our controls.

Analogy limit: a software attack surface changes every time a new endpoint, dependency, administrator, integration, queue, credential, or data flow is added. A house map is mostly static; a production system is not.

Now map the same chain to a file-upload feature. The private document is the asset. The upload endpoint is an entry point. Accepting any file type and trusting the supplied filename are vulnerabilities. A crafted file or path is an attack vector. Validation, size limits, malware scanning, generated storage names, authorization, and audit logs are controls. The remaining chance of a novel malicious file or a scanner failure is residual risk.

Read the visual from left to right. Start at the valuable object, follow the reachable entry point to the weakness and attempted route, then inspect which controls interrupt the path. The final box is deliberately not labelled 'safe'; it is labelled 'remaining risk'. That one word prevents the false promise that a control ends the discussion.

CIA: Three Different Promises Made to One Office File

A private salary file sits on an office system. Three different failures are possible. If an unauthorised person reads it, confidentiality failed. If someone silently changes a salary amount or approval instruction, integrity failed. If an authorised payroll employee cannot open the file on processing day, availability failed. The same object can be private but wrong, correct but unavailable, or available to everyone.

What this table is telling you is that CIA describes objectives, not products. Encryption may support confidentiality. Signatures, validation, and controlled writes may support integrity. Redundancy and DDoS protection may support availability. The objective comes first; the control is selected later.

Availability belongs in both security and reliability conversations. A failed disk may remove availability accidentally; a denial-of-service attack may remove it deliberately. The visible customer symptom can be identical, while prevention and response require different evidence. The deeper reliability treatment is useful in System Reliability Explained, but here the point is simple: preventing legitimate access can be a security harm.

Read the three panels as alternate states of the same document. Do not assign one tool to each panel. Ask instead which promise broke, which evidence would reveal it, and whether one control designed for another goal would have helped.

Security Goals Can Pull in Opposite Directions

Suppose an account locks permanently after one incorrect password. Brute-force attempts become harder, but an attacker can now deny service by deliberately submitting one wrong password for every known user. Suppose a company blocks all traffic during a suspicious spike. Attack traffic stops, and so do paying customers. A security decision can protect one objective while damaging another.

Controls also have operating costs. More approval steps can reduce unauthorised changes but delay urgent work. Deep traffic inspection can improve detection but add latency and privacy concerns. Detailed logs can help investigations but become a new sensitive asset. Risk-based security asks whether the expected reduction in harm justifies friction, cost, complexity, and new failure modes.

The goal is not maximum restriction. The goal is enough justified protection for the business promise, with remaining risk understood and owned.

Pause and retrieve

Without looking back, explain why a perfect door lock does not protect a weak window, and why blocking every request is not a successful availability strategy. If your answer mentions the asset, path, objective, and tradeoff, the vocabulary has started connecting.

Risk Prioritisation Turns a Threat List Into Decisions

A threat list can become endless. Risk prioritisation asks which scenario deserves action first. Consider the likely business impact, the ease and exposure of the path, the attractiveness of the asset, existing controls, how quickly harm would be detected, and how confident the team is in those assumptions. A precise-looking score is not automatically more honest than a reasoned high, medium, or low judgement.

For the upload feature, reading another user's identity document has severe privacy impact and a direct internet path, so object-level authorization and storage isolation are urgent. A rare scanner outage may be handled by quarantining uploads and delaying review. A hypothetical attack that requires physical access to a retired test server may rank lower, but should still be recorded if the assumption can change.

Prioritisation should produce an action, owner, and decision date. The team may mitigate the risk, avoid the risky feature, transfer part of it through a service or contract, or explicitly accept the residual risk. Acceptance is not silence. Someone with the right business authority understands the consequence and the conditions under which the decision must be revisited.

• Impact: What happens to people, money, operations, law, trust, or safety?

• Likelihood and exposure: How reachable and repeatable is the path under realistic attacker capability?

• Control confidence: Is the protection tested, monitored, independent, and operated reliably?

• Recovery: How quickly can the team contain, understand, and reverse the harm?

Risk changes after the control. A short-lived upload permission may reduce unauthorized reuse; quarantine may reduce parser exposure; monitoring may reduce time to detection. Recalculate the scenario instead of declaring it solved. This is the bridge between threat modelling and an engineering backlog: each control exists because it changes a named path and leaves a known remainder.

Threat Modelling: Draw the System Before Listing Attacks

Threat modelling is a structured design conversation about a bounded system. It is not a prediction of every attacker move and it is not a document written once by a security specialist. OWASP frames the work through four practical questions: what are we building, what can go wrong, what will we do about it, and did we do a good enough job? The current project guidance is available from OWASP Threat Modeling.

Take the upload flow: browser to upload API, malware scanner, object storage, and a database row containing metadata. Draw the components and arrows. Mark where internet input enters, where one identity becomes another, where data leaves your control for a vendor, and where a trusted internal process reads untrusted content. Those are trust boundaries: places where assumptions or authority change.

Next identify assets: the document, the owner's identity, access decision, storage key, scan result, and audit record. Ask misuse questions: can one user read another user's file? Can a huge upload exhaust memory? Can the scanner be bypassed? Can a callback be forged? Can an employee replace a scan result? Then estimate impact and likelihood well enough to prioritise, choose controls, assign owners, and record what is deliberately accepted.

The model must be revisited when the system changes. A new mobile client, direct-to-storage upload, third-party scanner, admin download feature, or public sharing link changes the attack surface and trust boundaries. Architecture decisions are easier to review when the flow is explicit; this is also why the diagrams in Software Architecture Patterns in System Design are useful context rather than decoration.

A threat model is useful when it changes a design decision, an engineering task, or a monitoring plan.green

Read the upload diagram from the browser to storage. At every numbered boundary ask what identity, data, and assumption crossed. The visual is not asking you to memorise icons. It is teaching the order of thought: draw, mark boundaries, ask misuse questions, then decide.

STRIDE as Six Questions on the Upload Flow

STRIDE is a way to organise threat questions. It does not score risk, replace business context, or guarantee completeness. Apply each letter to something concrete rather than reciting the expansion in an interview.

• Spoofing: Can a caller or service pretend to be another identity? A stolen session identifier could make one user appear to be another.

• Tampering: Can the file, owner ID, scan result, or download instruction be changed without permission or detection?

• Repudiation: Can someone deny uploading, approving, replacing, or downloading a file because trustworthy evidence is missing?

• Information disclosure: Can a private document, storage key, log entry, or metadata record leak to an unintended reader?

• Denial of service: Can oversized files, repeated scans, or expensive parsing exhaust capacity and block legitimate uploads?

• Elevation of privilege: Can a normal user gain reviewer, administrator, or storage-level capability they were never granted?

One threat can touch several categories. A forged scanner callback may spoof a service and tamper with the scan result. That is not a flaw in STRIDE. The categories are prompts for thinking, not mutually exclusive folders. Prioritisation still depends on exposure, business impact, likelihood, control strength, and recovery.

Read each question around the same upload path. The memory target is not the six nouns; it is the six verbs: pretend, change, deny, reveal, block, and gain power. Those verbs are easier to apply during a design review.

Four Attacks, Four Different Problems

Security conversations become vague when every harmful action is called 'hacking'. Four familiar attacks show why the affected objective and first defence differ.

What this table is telling you is that a named attack should trigger a mechanism question, not a product reflex. Autoscaling may keep extra capacity available during DDoS pressure, but it can also scale the bill and does not stop an upstream link from saturating. TLS protects data on a validated connection, but cannot make a malicious authorised client honest. A WAF may filter patterns, but safe database APIs and server-side authorization still belong in code.

If HTTP, cookies, CORS, sessions, and browser boundaries still feel blurred, Web Concepts in System Design provides the transport and browser foundation. Security controls work only when the underlying request journey is understood.

Secure by Design and Shift Left Without Process Theatre

A house designed with safe exits, sensible sight lines, fire separation, and proper locks is different from a finished building covered later with random bolts and cameras. Secure by design means security objectives and misuse cases influence requirements and architecture before expensive choices harden. It does not mean every risk is solved during design.

Shift left means asking relevant security questions earlier: during requirements, architecture, interface design, coding, and automated testing. It does not mean shifting all responsibility onto developers or stopping after a pre-release scan. Production monitoring, patching, access review, incident response, backup testing, and lessons from failures are the 'shift right' half of the same lifecycle.

• Before building: classify sensitive assets, draw data flows, mark trust boundaries, and define allowed actions.

• While building: use maintained libraries, validate at boundaries, parameterise queries, keep secrets out of source, and enforce authorization on the server.

• Before release: review configuration, dependencies, abuse cases, error handling, logs, and recovery paths.

• After release: monitor meaningful signals, patch, rotate, review access, test recovery, and update the threat model when the system changes.

Defence in Depth: Assume One Control Will Fail

The house has a gate, front-door lock, locked cupboard, alarm, and access record. In software, identity checks, network restrictions, authorization, safe input handling, encryption, monitoring, and recovery controls can interrupt different parts of a path. A bypassed WAF should still meet parameterised queries. A stolen employee session should still meet resource-level authorization and unusual-action detection.

Layers should fail as independently as practical. Five controls that all depend on the same shared administrator credential are not five independent layers. Nor is endless duplication free: every policy can drift, every alert can create noise, and every dependency becomes something to maintain. Defence in depth is deliberate coverage of different failure modes, not a contest to install the most tools.

Read the path as an attacker bypassing one layer. Notice that another layer either blocks the action, limits the accessible asset, records evidence, or makes recovery possible. Remember the outcome rather than the stack: prevent where possible, contain what passes, detect what happens, and recover what matters.

A Workplace Threat Model You Can Start Tomorrow

Your team is adding private identity-document uploads for an internal verification team. Begin with the promises: only the owner and assigned reviewer may read a document; the file and decision cannot change silently; authorised work must remain available; retention and deletion rules must be honoured. Those sentences turn security into testable design intent.

Draw browser, API, authentication service, upload worker, scanner, object storage, metadata database, reviewer interface, and audit system. Mark internet, third-party, employee, and storage boundaries. Ask who issues upload permission, how ownership is bound to the stored object, how file type is established, what happens when scanning is unavailable, who can override a result, how downloads are logged, and how deletion reaches backups.

The design review should end with decisions and owners: direct uploads use short-lived scoped permission; generated object names avoid user-controlled paths; asynchronous scanning quarantines files; reviewer access is server-authorised per case; logs avoid document content; exceptional overrides require evidence; retention jobs are monitored. The team also records residual risk, such as a new parser exploit, and what signal would reveal it.

Interview phrasing: I start with assets and security objectives, draw data flows and trust boundaries, use STRIDE to find misuse paths, prioritise by impact and likelihood, then choose layered controls and define how we will know they worked.

Common Misunderstandings That Break Designs

• Security means adding login. Login may establish identity. It does not validate input, authorise every action, protect data at rest, contain networks, or provide recovery.

• HTTPS makes the application secure. HTTPS protects a connection. The endpoint can still expose another user's data or execute an unsafe query.

• The internal network is trusted. A compromised internal workload, employee device, or credential can still move through overly broad paths.

• A WAF fixes insecure code. It may filter known patterns, but code and data-layer controls remain necessary.

• Security ends before launch. Dependencies, identities, data flows, attackers, and business impact continue changing.

• Threat modelling is only for specialists. Security expertise helps, but developers and product owners know the real data flow and business consequences.

Explain It Back Without Looking

Close the article or cover the previous sections. Rebuild the lesson from these five objects: jewellery, weak latch, doors-and-windows map, lock and alarm, office file. Say what each represents and where the analogy stops.

1. Reconstruct the chain: asset -> entry point -> vulnerability -> attack vector -> control -> residual risk.

2. Use the office file to explain confidentiality, integrity, and availability without naming a product.

3. Draw browser -> upload API -> scanner -> object storage -> metadata database and mark two trust boundaries.

4. Ask STRIDE as six verbs: pretend, change, deny, reveal, block, gain power.

5. Contrast threat with threat actor, vulnerability with attack vector, and control with guaranteed safety.

Now transfer it. A team adds a 'share document by link' feature. Which asset and entry point changed? Which trust boundary moved? What new disclosure, spoofing, repudiation, and denial questions appear? Which control could harm usability or availability? If you can answer without copying a checklist, you are threat modelling.

A sixty-second retelling might sound like this: security design begins by identifying valuable assets and the paths that can harm confidentiality, integrity, or availability. We draw components and trust boundaries, ask what can go wrong, use STRIDE to organise questions, prioritise risk, and choose layered controls. Every control has limits and tradeoffs, so we monitor, recover, and revisit the model whenever the system changes.