Practice · 05

Threat modeling

A model that stops at HTTPS has not met the product. Radios, accessories, and the person holding the device belong on the same sheet.

A radiating product has more than one way to become someone else’s peer.

Threat modeling is the spine of NIIS 9. Testing without a model produces souvenirs. Models without any testing produce fiction. The practice keeps both on the same engagement: name the assets, name the adversaries, draw the flows, argue about trust boundaries, then press on the ones that would actually change a decision.

What gets drawn

  • Data flows that include spectrum, not only API gateways.
  • Trust boundaries at pairing, attestation, SIM, TEE, and human operators.
  • Adversary profiles with proximity, budget, and legality constraints made explicit.
  • STRIDE and LINDDUN questions applied to those boundaries, not copied from a poster.

Who it is for

Product security teams about to ship a radio. Architecture groups inheriting a mobile estate. Privacy counsel who need an engineer’s diagram instead of a slogan. The output is a living model and a short list of tests worth paying for, not a 90-page novelty.

Workshops are structured. The practice does not facilitate sticky-note tourism. Someone has to leave the room with a diagram that would still make sense six months later.

Related note: threat models for things that radiate