The Builder Who Asked No Questions
Nirmata the builder was ready to start. The kingdom needed a new treasury. He had the blueprint, the materials, the workers. He was about to pour the first foundation when Rekhakar the map-drawer asked him to stop. "Before you build," Rekhakar said, "let me draw the flows. Let us see what moves through this treasury, who touches it, and where it crosses from safe hands to unsafe ones." Nirmata was impatient. Every day he waited was a day the treasury was not built. Rekhakar replied: "Every day you build without the map is a day you might build the thief's route into the walls." Nirmata paused. Rekhakar began to draw.
“Threat modeling happens before building. A system designed against known threats is cheaper to secure than one retrofitted after deployment.”
Chalaka Teaches the Six Questions
Rekhakar invited Chalaka the clever fox to review the map. Chalaka named six ways a thief thinks — each a question to ask about every asset on the map. Spoofing: can a thief pretend to be someone they are not? Tampering: can a thief alter goods in transit? Repudiation: can a thief deny they were there? Information Disclosure: can a thief see what they should not see? Denial of Service: can a thief block the treasury from serving its rightful customers? Elevation of Privilege: can a thief who enters as a guest become the treasury master? Together, these six questions formed STRIDE. Asked once for every flow on Rekhakar's map, they produced a list of threats. Most builders had never asked even one.
“STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) is a structured vocabulary for threat discovery.”
The Boundary Where Trust Changes
Rekhakar's map had a special kind of line: the trust boundary. On one side lived the treasury workers — trusted. On the other side lived the merchants who came to deposit — untrusted until verified. Every point where information crossed a trust boundary was a potential threat surface. The most dangerous flows were those crossing from untrusted to trusted without sufficient verification. Rekhakar circled every trust boundary crossing on the map in red. Each red circle became a question: "What must be true before this crossing is allowed?" If the answer was "nothing," the circle was a critical finding. Many of Nirmata's original designs had crossings with no verification at all — not because Nirmata was careless, but because he had never drawn the map.
“Trust boundaries in a data flow diagram reveal where verification is needed. Every crossing demands an explicit trust decision.”
The Weigher Who Decided What to Fix
The STRIDE analysis produced sixty threats. Nirmata was overwhelmed. Tulaka the weigher introduced a scoring system. For each threat, two questions: how likely is a thief to try this? And if they succeed, how much harm results? Threats with high likelihood and high impact were fixed immediately — they were the most valuable targets for the least effort. Threats with low likelihood and low impact were documented but not immediately addressed. This was risk prioritisation. Not every threat needed to be fixed before building could begin. The highest-value threats — the ones that would cause the most damage if exploited — were the ones that justified delaying construction. The rest would be addressed in order.
“Threat modeling produces a risk-ranked backlog. Fix the highest impact and highest likelihood threats first; not all threats require the same urgency.”
The Living Map
Two years after the treasury opened, Nirmata added a new feature: a side entrance for large merchant caravans. He came to Rekhakar. "Do we need to re-examine the map?" Rekhakar said yes. The new entrance crossed a trust boundary. The STRIDE questions were asked again for the new flow. Three new threats were discovered. Two were addressed before the entrance opened. One was accepted with a documented mitigation plan. The map was updated. Threat modeling was not a ceremony performed once at the beginning. It was a practice performed at every significant change. The map was the living record of what the kingdom understood about its own vulnerabilities. Its value grew with every update.
“Threat model at design time and at every significant change. The threat model is a living document, not a one-time artefact.”
🪔 Deepak — the lamp of meaning · what this fable means in code
Threat modeling is a structured process to identify, enumerate, and prioritise security threats before they are built in. Process: (1) Decompose the system — draw a Data Flow Diagram (DFD): processes, data stores, data flows, external entities, and trust boundaries. (2) Identify threats using STRIDE against each DFD element: Spoofing (authentication controls), Tampering (integrity controls), Repudiation (non-repudiation/logging), Information Disclosure (confidentiality controls), Denial of Service (availability controls), Elevation of Privilege (authorisation controls). (3) Prioritise using DREAD (Damage, Reproducibility, Exploitability, Affected Users, Discoverability) or CVSS scoring. (4) Mitigate or accept — document decisions. (5) Validate — threat model is reviewed as part of security design review and updated at every significant feature change. Tools: Microsoft Threat Modeling Tool (DFD-based, STRIDE output), OWASP Threat Dragon, IriusRisk. Integrate threat model reviews into your Definition of Ready for significant features.