What does a Security Cards deck surface that a checklist-driven threat review misses?
answer
- Prompts about people, not mechanisms
- Two of four dimensions concern the attacker
- Motive need not be money
- Widens who and why, not what to build
- You only look where the suits point
basics
~20 sSecurity Cards is organised around human impact, adversary motivations, adversary resources and adversary methods, so it forces a team to name who would attack and why. Control-oriented lists never prompt that, and miss attackers whose goal is not money.
solid answer
~50 sA control checklist prompts about mechanisms. Security Cards prompts about people and consequences: its four dimensions are human impact, the adversary's motivations, the adversary's resources and the adversary's methods. Drawing a motivation card forces the question a mechanism list never asks - who wants this to go wrong, and what do they get. On a newsroom's election-night results widget that changes everything: the plausible adversary is a resourced political actor whose payoff is making the published results look wrong, or unavailable at the moment they matter. The assets are audit truth and public trust plus availability at peak, not stolen records. A checklist would sign off a widget with perfect transport security and no way to prove afterwards which numbers it served. The cost is that cards give prompts, not requirements: you still convert each into a threat and a fix.
go deeper
Know that Security Cards is a deck organised around adversaries and harm, used to prompt threats a control-oriented list would never raise. Being able to say what it is for is enough at this level.
Be able to name the four dimensions and explain why prompting about motivations and human impact changes which threats a team writes down, especially when the attacker is not after money.
Show that you pick a deck for the blind spot you actually have, and that you record the categories the deck never prompted so the gap stays visible instead of being assumed covered.
Own the tradeoff between the coverage a printed deck guarantees and the ceiling it quietly imposes, and decide where prompt-driven breadth belongs in a programme versus depth on a single flow.
## Why a deck at all Card-based methods exist because unaided threat elicitation is bounded by what the people in the room happen to think of, and that is reliably narrower than reality. A deck is an externalised prompt list with a physical rhythm: you draw or deal a card, you argue about whether it applies to your system, you write down what it surfaced. The value is not the cardboard - it is that the prompts are *someone else's*, so they reach past the room's assumptions. Different decks aim at different blind spots, and knowing which blind spot a deck was built for is what separates a candidate who has used one from a candidate who has heard of one. ## Security Cards: attacker-centric prompts The Security Cards deck (from University of Washington researchers) is organised into four dimensions: | Dimension | The question it forces | |---|---| | Human impact | Who is harmed, and how - emotional wellbeing, finances, personal data, relationships, unusual harms | | Adversary's motivations | Why would anyone do this - money, curiosity, politics, spectacle, revenge, self-promotion | | Adversary's resources | What do they have - time, money, expertise, insider access, physical access | | Adversary's methods | How do they act - technical attack, manipulation of people, physical means, processes and legal channels | Two of those four dimensions are about *who and why*, and one is about *the cost to a person*. That is the deck's whole thesis: teams under-imagine attackers and under-imagine harm, and a mechanism-oriented review will never correct either, because it starts from controls. The method is also deliberately broad and open-ended. It is a brainstorming aid for early design and for systems whose threat landscape is not obvious, not a per-element sweep and not a source of ready-made requirements. ## Worked example A newsroom builds an election-night results ingestion widget under a hard deadline. Checklist thinking asks about transport security, authentication on the ingest endpoint, dependency hygiene, and rate limits. All correct, all insufficient. Deal a motivation card that says something other than financial gain and the conversation changes. The plausible adversary here is a resourced political actor. The payoff is not stolen data - there is nothing to steal. It is making the published numbers wrong, or making them disappear for the two hours they matter. An impact card pushes further: the harm is to public trust and to people who make decisions on the published figures, and it does not require the attack to succeed - a *credible claim* that the numbers were tampered with does damage on its own. That reframing produces threats a control list cannot generate. Tampering with the ingest feed upstream of the widget. Availability at peak, where an outage at 11pm is indistinguishable from suppression. And critically a non-repudiation gap: if there is no signed, append-only record of which numbers were served at which moment, the newsroom cannot *disprove* an accusation, which is the attacker's actual win condition. ## The deck's own bias Every deck biases a team toward the categories printed on it, and this is the senior half of the answer. Security Cards is strong on who and why, and gives you almost nothing concrete about *what to build*. A requirement-oriented deck sits at the other end: OWASP Cornucopia deals cards grouped into suits covering data validation and encoding, authentication, session management, authorization, cryptography, and a catch-all suit, each card phrased as an attacker capability that maps to a secure-coding requirement. Run a sixty-minute Cornucopia-style round over a game studio's live-ops config push path and you will get precise, actionable findings about who may sign a config push and how it is validated - and you will not get one prompt about a contractor with console access whose motive is selling an in-game economy exploit, because motive is not on those cards. So the pairing matters: attacker-centric decks widen the *who*, requirement-centric decks sharpen the *what to do*, and neither one covers the other's ground. ## Working with the bias instead of inside it - **Choose the deck for the blind spot you have.** A team that keeps missing non-financial adversaries needs different prompts than a team that names threats well and writes vague mitigations. - **Record what the deck never asked.** After the session, write the categories that never came up. This turns a silent gap into a visible one and is the single cheapest guard against "we used the deck, so we are covered." - **Do not let the suits become the model's boundary.** The deck is an input to elicitation, not the definition of the threat space. - **Know when not to use one.** A fluent team working on a well-understood system usually needs depth on a specific flow rather than breadth of prompts; the deck's ritual costs time it will not repay there.
- How do you stop a deck's printed suits from becoming the edge of the model?Close the session by writing down what the deck never prompted about - the flows, assets or attacker types no card touched - and carry that list forward as known-unexamined. I also avoid running one deck as the whole method: the deck is elicitation input, and the model still needs the system's own flows and boundaries walked independently of what the cards happened to say.
- A studio runs an OWASP Cornucopia-style round over its live-ops config push path. What will that deck not prompt?It will sharpen validation, authentication, session, authorization and cryptography questions around who may push a config and how it is checked. It will not raise adversary motive or human impact, so the contractor with console access selling an in-game economy exploit, and the harm to players when the economy is broken, have to come from somewhere else.
- When would you not reach for a card deck at all?When the team already elicits threats fluently and the system is well understood - then the shortage is depth on a specific flow, not breadth of prompts, and the deck's ritual costs time it will not repay. Decks earn their keep on novel systems, on teams new to modeling, and wherever the room's imagination about attackers is the binding constraint.
A card deck is a set of conversation prompts, not an exam paper. It reliably drags the discussion somewhere the room would not have gone, and it just as reliably never mentions whatever is not printed on it.
saying these in an interview costs you the question
- Treats the deck's printed suits as the full threat space
- Assumes every adversary is motivated by money
- Says card decks are only for beginners
- Confuses a motivation prompt with a concrete requirement
- Runs one deck once and calls the model complete
- Ignores harms to people that are not data loss