Three Harmless Things in a Row

Last timeGoing Through It Systematically

Real incidents are rarely one dramatic failure. They are three or four findings nobody would have fixed, arranged in an order, each one making the next one possible.

Severity is not local

The list from the last lesson is full of findings that nobody would fix.

An endpoint that confirms whether an address is registered. A file upload

that keeps the name it was given. A page that reflects a parameter back

into the response. A worker that retries a failed job without checking

whether it already ran.

Taken one at a time each of those is a shrug. Nothing is disclosed,

nothing is lost, and a reasonable engineer asked to prioritise them would

put every one at the bottom.

That instinct is the subject of this lesson, because it is how most real

incidents happen. The question a finding should be asked is not what does

this lose, it is what does this enable, and that question cannot be

answered by looking at the finding.

FIG 1The same four findings, scored twice

	severity alone, 0 to 3	severity in the chain, 0	how easy to fix, 0 to 3	how alarming it sounds,
an endpoint confirms whe	0	3	1	1
an upload keeps the file	0	3	2	1
a page reflects a parame	1	3	2	2
a retry runs a job that	0	2	3	0

The first column is nearly all zeros and the second is nearly all threes. The two marked cells are the same finding scored both ways, and the gap between them is the entire argument of this lesson. Note also that the easiest fix is in the row that sounds least alarming.

What a step hands over

The reframing that makes chains visible is to describe every finding by

the capability it grants rather than by the damage it does.

Almost nothing in a real chain causes damage. The steps hand over

knowledge of a valid name, or an identifier that turns out to be accepted

elsewhere, or one permission more than intended, or a place on disk where

a file can be left, or a way to make one operation slow enough to matter.

FIG 2One chain, drawn as what the attacker holds

Ten nodes alternating between a step and what the attacker now holds. Read only the odd nodes and it is a list of trivia. Read only the even ones and it is an escalation. Neither view alone shows the incident.

FIG 3The same chain, with what it cost and what it was worth

step	step	what it handed over	cost to the attacker	severity if found alone	what happened
1	address confirmation	a real staff name	ten minutes	none, closed as working as intended	This is the step that gets closed with a comment explaining that the behaviour is necessary for the sign-up flow, which is true.
2	a reflected parameter	a link that looks internal	an afternoon	low, needs user interaction	Needs user interaction is the phrase that buries this category, and the chain is precisely a description of how that interaction is obtained.
3	any staff session reaches the console	read access to every account	nothing	not on the list at all	Not a finding. A design decision, made for a good reason, which is why no enumeration pass caught it and why the drawing from lesson two matters.
4	an unattributed export	the table, with no record	minutes	low, internal tool	Internal tool is doing the same work that needs user interaction did two rows up, and it is wrong for the same reason.
5	the whole chain	the outcome you actually care about	one day	the worst thing in the register	One day of work, four findings, none of which would have reached the top of anybodys list.

5 steps

Look down the last column, then at the last row. Four entries of none or low produce the worst outcome on the asset register, and the total cost to the attacker is a single day.

Building the chain

Chains are found backwards. This is the single most useful technique in

the lesson and it is counterintuitive, because the findings are in front

of you and the temptation is to start there.

Starting from a finding and asking what it could lead to produces a story.

There is always a sequence of events in which some trivial thing becomes

terrible, and the room enjoys inventing them, and the output is not

rankable because nobody can say whether any of it is likely.

Starting from an outcome and asking what would be required produces a

requirement. Take the worst line of the asset register. To read every

customer record, somebody needs console access. To get console access,

they need a staff session. To get a staff session, they need either a

password or a way to use one. Each answer is a question, and the questions

terminate either at something on your findings list, which closes a chain,

or at something genuinely hard, which is a defence you can name.

The lesson stops here

2 more paragraphs to go

You have read the opening. The rest of the argument, the problems that check whether it landed, and the lines worth keeping at the end all come with a plan.

The first lesson of every course in the library reads the whole way through, free, so you can see exactly what the rest of them are.

See the plan The contents

This is the reading half

Starting the course gives you your own copy of it. Every idea on every page has problems standing under it, marked with a reason rather than a tick, and any sentence you do not believe can be opened and argued with. None of that can happen on a page nobody owns.

The contents