Leaders LoopMost breaches do not begin with a genius hacker. They begin with something ordinary, a reused password, a permission nobody revoked, a "temporary" admin account that outlived the person who needed it. Security fundamentals are how you stop losing to the ordinary; threat modelling is how you find the gap before someone else does.
The quick version
- Three goals, one shorthand. Almost every security decision protects confidentiality, integrity or availability, the "CIA triad". Name which one you are protecting and the right control usually becomes obvious.
- One principle pays for itself. Least privilege, give every person and program only the access it needs, limits the blast radius of every mistake and every break-in.
- Threat modelling is four questions, not a tool. What are we working on? What can go wrong? What are we going to do about it? Did we do a good job? You can run it on a whiteboard.
- People are the surface. Most breaches involve a non-malicious human error or someone falling for a social-engineering trick, so the controls that assume people will slip are the ones that earn their keep.
The idea in depth
Security has a reputation for being arcane, and a lot of it is. But the part a leader actually needs fits on an index card. Three ideas do most of the work: a definition of what you are protecting, a principle for how to limit damage, and a method for finding problems early. Get those three working and you are ahead of most organisations, including ones that have spent far more money than you.
Confidentiality, integrity, availability, name what you are protecting
The oldest useful idea in the field is the CIA triad: information security means protecting three things at once. Confidentiality, keeping data away from people who shouldn't see it. Integrity, making sure data isn't altered or destroyed without authorisation. Availability, keeping systems and data reachable when they're needed. The triad is baked into US federal standards: NIST's FIPS Publication 199 defines security categories in exactly these terms, drawing on the statutory definition in 44 U.S.C. § 3542.
Why does a leader care about a three-letter mnemonic? Because the three pull in different directions, and confusing them is how teams buy the wrong control. Encrypting a database protects confidentiality but does nothing for availability, an attacker who deletes it has still hurt you. Locking a system down so hard that staff can't use it trades availability for confidentiality, often badly. So the move is: before any security spend or design decision, ask which of the three you are protecting and which you might be sacrificing. A backup strategy is an availability and integrity control; a permissions review is a confidentiality control; ransomware attacks all three at once, which is why they hurt. Naming the goal turns a vague worry into a specific, fundable decision.
The honest limitation: the triad tells you what to protect, not how much or against whom. It has no notion of cost, likelihood, or who your actual adversary is. It is a vocabulary, not a strategy, useful for sorting controls, useless for prioritising them. For prioritising, you need the next two ideas.
Least privilege, the one principle that limits the damage
In 1975, Jerome Saltzer and Michael Schroeder published "The Protection of Information in Computer Systems", still the reference text for security design principles half a century on. Their most quoted rule is the principle of least privilege: "Every program and every user of the system should operate using the least set of privileges necessary to complete the job." The military "need to know" rule is the same idea in older clothing.
The reason this principle outlasts every passing technology is that it shrinks the blast radius of failure. If a marketing intern's laptop is compromised but that account can only touch marketing files, the attacker is stuck. If the same laptop carries domain-admin rights "because it was easier", one phished password becomes a company-wide incident. Least privilege doesn't prevent the break-in, it caps what the break-in can become. So the move is: stop granting access by job title and start granting it by task, with an expiry date. The practical entry point is dull and powerful, run an access review. List who can reach your most sensitive system, and for each name ask "would anything break if we removed this?" The accounts where the answer is "no, probably not" are your cheapest security win this quarter. This is why identity is the front line, and why identity & access management is the discipline that operationalises least privilege at scale.
The honest limitation: least privilege is easy to state and miserable to maintain. Access accumulates, people change roles, projects spin up, and revoking access feels like an accusation, so nobody does it. Without automation and a regular review cadence, a system that started least-privileged drifts back to over-privileged within a year. The principle is sound; the discipline is the hard part.
Threat modelling, ask "what can go wrong" before you build
Fundamentals tell you what to protect and how to limit damage. Threat modelling tells you where to look. It is a structured way of imagining how a system could be attacked or fail, done early enough to change the design rather than apologise for it. Security author Adam Shostack reduced it to a four-question framework that any team can run: What are we working on? What can go wrong? What are we going to do about it? Did we do a good job? They aren't a full methodology, they're a frame that other techniques fit inside. The same spirit runs through the Threat Modeling Manifesto (2020), written by a working group of practitioners who value, in their words, "a culture of finding and fixing design issues over checkbox compliance".
The most common answer to "what can go wrong" is a mnemonic called STRIDE, developed at Microsoft by Loren Kohnfelder and Praerit Garg in 1999. Each letter is a category of threat to probe: Spoofing (pretending to be someone), Tampering (altering data), Repudiation (denying an action with no proof), Information disclosure (a leak), Denial of service (knocking it offline), and Elevation of privilege (gaining rights you shouldn't have). Walk a diagram of your system and ask each STRIDE question at every point where data crosses a boundary.
flowchart LR A(["What are we
working on?"]) --> B(["What can
go wrong?"]) B --> C(["What are we
going to do
about it?"]) C --> D(["Did we do
a good job?"]) D -. "revisit as the
design changes" .-> A
So the move is: pick one system that matters, the one holding your customer data is a good start, and spend an hour drawing how data flows through it on a whiteboard. Mark every boundary where data passes between a user, your code, and an outside service. At each boundary, run the four questions and use STRIDE to prompt the second one. You will surface real gaps in an afternoon, no security hire required. The point isn't a perfect document; it's the conversation, repeated whenever the design changes.
The honest limitation: threat modelling finds the problems you can imagine, and a determined attacker's job is to find the ones you didn't. STRIDE is strong on technical threats and weak on business-logic abuse, social engineering, and supply-chain risk. It is a flashlight, not floodlights, invaluable for lighting the corners you point it at, no help for the rooms you never enter. Treat it as a recurring habit that narrows your blind spots, not a certificate that you have none.
A worked example
Picture a small company launching a customer portal where clients upload documents and download invoices. The team is about to ship. Instead, they spend an hour threat modelling. (Figures and details below are illustrative.)
What are we working on? They sketch the flow: a browser logs in, talks to the app server, which reads and writes a database and stores files in cloud storage. Three trust boundaries appear, browser-to-server, server-to-database, server-to-storage.
What can go wrong? Running STRIDE at each boundary surfaces three concrete issues. Spoofing: the login allows weak passwords and has no multi-factor option, so a leaked password from another site walks right in, which matters because most breaches involve stolen credentials or human error, not exotic exploits. Information disclosure: uploaded files sit under predictable URLs, so one customer could guess another's invoice link. Elevation of privilege: the app server connects to the database using an all-powerful admin account, a single flaw in the app would expose every table.
flowchart TD U(["Customer
browser"]) -->|"① login: weak
password, no MFA
(Spoofing)"| S(["App
server"]) S -->|"③ admin DB account
(Elevation of Privilege)"| DB([("Database")]) S -->|"② guessable file URLs
(Information Disclosure)"| FS(["File
storage"])
What are we going to do about it? Each finding maps to a fundamental. Add multi-factor authentication and block known-breached passwords (confidentiality; defends the human surface). Generate unguessable, time-limited file links (confidentiality and integrity). Give the app a database account scoped to only the tables it uses (least privilege; caps the blast radius). None of this needs a new vendor, it is configuration and a day of work.
Did we do a good job? They note that they never examined the invoice-generation logic or the third-party email provider, and book a follow-up. That honesty is the method working: the model is a living document, and naming what you skipped is more useful than pretending you covered everything.
Frequently asked questions
Do we need to hire a security expert to do this?
No, not to start. The four questions and the CIA triad are deliberately plain enough for a product team to use on a whiteboard, and the biggest early wins (access reviews, multi-factor authentication, least-privilege accounts) are configuration, not specialist work. You will eventually want expert review for high-stakes systems, but waiting for a hire is the most common reason teams never start at all.
Isn't this just common sense?
The principles are; the practice isn't. "Only give people the access they need" is obvious, yet over-privileged accounts are among the most common findings in real breaches, because access accumulates quietly and nobody is rewarded for taking it away. Threat modelling's value is that it forces the obvious questions to be asked on purpose, before you ship, rather than discovered afterwards in an incident review.
How often should we threat model?
Whenever the design changes meaningfully, a new feature that handles sensitive data, a new integration, a new way users authenticate. That is why Shostack's framework loops back on itself. A model from two years ago describes a system that no longer exists. A lightweight model revisited often beats an exhaustive one done once.
Where does compliance (GDPR, ISO 27001) fit in?
Compliance frameworks tell you what good looks like; fundamentals and threat modelling are how you get there and stay there. Threat modelling will surface privacy risks that map directly to obligations under data-protection law, but treat compliance as a floor, not a ceiling. Passing an audit is not the same as being secure, and your jurisdiction's specifics are a question for a qualified professional.
What's the single highest-value thing to do first?
Turn on multi-factor authentication everywhere it's available, then run one access review on your most sensitive system. Between them, those two moves blunt the two most common breach paths, stolen credentials and over-privileged accounts, for almost no money.
Related in the Toolkit
- Identity & access management, the discipline that turns least privilege from a principle into a running system of accounts, roles and reviews.
- Data privacy & PII handling (GDPR and equivalents), what the law requires once you hold personal data, and how threat modelling surfaces privacy risk.
- Data retention, residency & sovereignty, where data lives and how long you keep it, both of which change your threat picture.
- Product & data risk, folding security and privacy thinking into product decisions rather than bolting it on later.
- Cyber risk & incident response, what to do when prevention fails and a control you modelled gets tested for real.
- Financial statements (P&L, balance sheet, cash flow), the language for arguing security spend as managed risk, not insurance you hope to never use.
- Lean, Six Sigma, Kaizen & continuous improvement, the recurring-review mindset that keeps a threat model alive instead of stale.
- Hosting & cloud architecture, the trust boundaries and shared-responsibility lines a cloud threat model has to draw.
Where to go next
- Saltzer & Schroeder, "The Protection of Information in Computer Systems" (1975), the original source of least privilege and the design principles that still anchor the field; surprisingly readable for a foundational paper.
- Adam Shostack, "Threat Modeling: What, Why, and How?", a short, plain-English whitepaper from the author of the four-question framework; the fastest way to understand how to run a model.
- The Threat Modeling Manifesto (2020), a one-page distillation of values, principles, patterns and anti-patterns from a working group of practitioners; bookmark it as your sanity check.
- NIST FIPS 199, the federal standard that puts confidentiality, integrity and availability on a formal footing; skim it to see the triad used in anger.
- "Game On: Adding Privacy to Threat Modeling", Adam Shostack & Mark Vinkovits (talk), a watchable session on extending threat modelling beyond pure security into privacy, from the people who shaped the practice.