Finding the Threats Before the Attacker Does

The last post listed things that can go wrong with an autonomous vessel. Reading such a list, it is natural to wonder how the list was arrived at – and whether anything is missing. That question matters more than it might sound. Almost every serious security failure has the same post-mortem: nobody had thought of that particular path. Not because the team was careless, but because they were relying on memory and intuition to enumerate an attacker’s options.
The discipline that replaces intuition is called threat modelling, and it is the least glamorous and most valuable security activity there is.

Draw the system honestly

Threat modelling starts with a picture — but a specific kind of picture. Not a marketing diagram, and not a network cable plan. What you draw is the flow of information: every place data is created, every place it is stored, every place it moves from one part of the system to another, and every human or external service that touches it.
Then you draw the boundaries. A boundary is any line across which trust changes: between the vessel and the open air of a wireless link; between a shore server and the public internet; between one software component and another that runs with different privileges; between the operator’s browser and the system behind it. Boundaries are where attacks happen, because a boundary is exactly the place where something outside your control hands data to something inside it.
This step is deceptively hard, because it demands honesty. The diagram has to show the system as it actually is, including the awkward connection that was added late, the legacy interface nobody wants to discuss, and the maintenance access route that exists but isn’t on any architecture slide. A flattering diagram produces a flattering threat model, which is worse than none at all.

Then ask the same six questions of everything

With the picture drawn, you go through it methodically. The most widely used approach asks six questions of every component and every flow, one for each broad category of thing that can go wrong: can someone pretend to be something they are not; can someone alter data in transit or at rest; can someone deny having done something they did; can someone read what they shouldn’t; can someone stop the thing working; can someone gain more privilege than they were given.
The power of this is not that the six questions are profound. It is that they are exhaustive and repeatable. You cannot skip a box because it looked boring, and a colleague repeating the exercise next year will cover the same ground. Boring components are where attackers live — the logging service, the health-check endpoint, the reverse proxy nobody thinks about.

Every threat gets an owner and an answer

A list of threats is not the deliverable. The deliverable is a chain: each threat is either accepted with a documented reason, or matched to a specific mitigation — a concrete change in the design or the process that reduces it. Each mitigation is then traced to a requirement in a recognised standard, so the whole thing hangs together as an argument rather than a set of good intentions.
That chain is what turns “we take security seriously” into something a customer or an assessor can actually inspect. It answers the question behind the question: not “is this system secure”, which nobody can honestly answer, but “what did you consider, what did you do about it, and how do you know”.

A threat model is a living document

The other thing that separates a real threat model from a compliance exercise is that it is maintained. Systems change. A new sensor, a new integration, a new deployment option — each one potentially opens a path that didn’t exist when the model was drawn. So does the outside world: new attack techniques are catalogued constantly, and a threat that was theoretical last year may have a working tool published this year. A threat model that was completed once and filed away is describing a system that no longer exists