{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"security/threat-modelling","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/threat-modelling/","da":"https://cmaintz.github.io/tech-atlas/da/terms/security/threat-modelling/"},"term":{"en":"Threat modelling","da":"Trusselsmodellering"},"aka":{"en":["threat modeling"],"da":[]},"domain":["security"],"cluster":"application-security","layer":"application","status":"current","summary":{"en":"Sitting down with a drawing of a system to work out what could go wrong, who might cause it and what to do about it.","da":"At sætte sig ned med en tegning af et system og finde ud af, hvad der kan gå galt, hvem der kan stå bag, og hvad man vil gøre ved det."},"body":{"formal":{"en":"A structured method for finding threats against a planned or existing system by mapping its parts, data flows and trust boundaries, listing what could go wrong at each point, and deciding which controls to add; it does most good while the design can still change.","da":"En struktureret metode til at finde trusler mod et planlagt eller eksisterende system ved at kortlægge dets dele, datastrømme og tillidsgrænser, gennemgå, hvad der kan gå galt i hvert punkt, og beslutte, hvilke kontroller der skal tilføjes; den gør mest gavn, mens designet stadig kan ændres."},"plain":{"en":"Like walking through the plans for a new house and asking at every door and window how someone could get in there, and what would stop them.","da":"Som at gennemgå tegningerne til et nyt hus og ved hver dør og hvert vindue spørge, hvordan nogen kunne komme ind her, og hvad der ville stoppe dem."},"inPractice":{"en":"Before adding online payment of nursery fees to a municipality's self-service site, the team draws how card data moves between the site, its server and the payment provider, and finds an internal service that accepts requests from anyone - so they add a check before writing any code.","da":"Før teamet bygger betaling for daginstitutionspladser ind i en kommunes selvbetjening, tegner det, hvordan kortdata bevæger sig mellem siden, serveren og betalingsudbyderen, og opdager en intern tjeneste, der tager imod forespørgsler fra alle - så det tilføjer et tjek, før der skrives en linje kode."},"whyItMatters":{"en":"A flaw in the design itself cannot be patched away later and may force a costly rebuild after launch; found on paper, it is cheap to fix.","da":"En fejl i selve designet kan ikke fjernes med en patch bagefter og kan kræve en dyr ombygning efter lancering; findes den på tegnebrættet, er den billig at rette."}},"deepDive":{"en":"Most methods can be reduced to Adam Shostack's four questions, which the Threat Modeling Manifesto (2020) also adopts: What are we working on? What can go wrong? What are we going to do about it? Did we do a good enough job? The first question is answered with a model of the system, usually a data flow diagram showing external entities, processes, data stores, data flows and trust boundaries, or a sequence diagram for protocol-heavy designs. The quality of everything that follows depends on this model being accurate and at the right level of detail, which is why threat modelling is most effective as a conversation between architects, developers and security staff rather than a document produced by a security team alone.\n\nThe second question is answered with an elicitation technique. STRIDE, applied per element or per interaction, is the most widely used; attack trees, introduced by Bruce Schneier in 1999, decompose an attacker goal into AND/OR subgoals; PASTA is a seven-stage, risk-centric process that ties technical threats to business impact; LINDDUN covers privacy threats; and MITRE ATT&CK or CAPEC catalogues can be used to check coverage against known techniques. The third question produces decisions for each threat: mitigate, eliminate by redesign, transfer, or accept with a named owner. Findings are recorded as security requirements or backlog items so they can be tracked and tested, and the fourth question closes the loop by checking that mitigations were built and that the model still matches the system.\n\nIn a secure development lifecycle, threat modelling happens at design time and again when a change crosses a trust boundary, adds a new data type or introduces a new external dependency. NIST SP 800-218 (SSDF) practice PW.1.1 explicitly lists threat modelling, attack modelling and attack surface mapping as forms of risk modelling to evaluate security requirements. Tooling ranges from whiteboards to Microsoft Threat Modeling Tool, OWASP Threat Dragon and code-based approaches such as pytm and Threagile, which generate diagrams and findings from a model kept in version control.\n\nCommon failure modes are modelling once and never updating, producing a long list of generic threats with no decisions attached, and going too deep in one component while missing the integrations where most real flaws sit. Threat modelling differs from risk assessment in scope and timing: a risk assessment ranks risks to the organisation's assets, while a threat model examines how a specific system could be attacked, early enough to change its design. It also differs from penetration testing, which finds flaws in what has already been built.","da":"De fleste metoder kan koges ned til Adam Shostacks fire spørgsmål, som Threat Modeling Manifesto (2020) også bygger på: Hvad arbejder vi på? Hvad kan gå galt? Hvad vil vi gøre ved det? Gjorde vi det godt nok? Det første spørgsmål besvares med en model af systemet, typisk et dataflowdiagram med eksterne entiteter, processer, datalagre, dataflows og tillidsgrænser eller et sekvensdiagram for protokoltunge designs. Kvaliteten af alt det følgende afhænger af, at modellen er korrekt og har det rette detaljeniveau, og derfor virker trusselsmodellering bedst som en samtale mellem arkitekter, udviklere og sikkerhedsfolk frem for et dokument, som sikkerhedsteamet laver alene.\n\nDet andet spørgsmål besvares med en teknik til at finde trusler. STRIDE, anvendt pr. element eller pr. interaktion, er den mest udbredte; angrebstræer, som Bruce Schneier introducerede i 1999, deler et angribermål op i AND/OR-delmål; PASTA er en risikocentreret proces i syv trin, der kobler tekniske trusler til forretningsmæssig konsekvens; LINDDUN dækker privatlivstrusler; og kataloger som MITRE ATT&CK eller CAPEC kan bruges til at tjekke dækningen mod kendte teknikker. Det tredje spørgsmål giver en beslutning for hver trussel: afhjælp, fjern den ved at ændre designet, overfør den eller accepter den med en navngiven ejer. Fundene registreres som sikkerhedskrav eller backlog-punkter, så de kan følges og testes, og det fjerde spørgsmål lukker sløjfen ved at tjekke, at modforanstaltningerne blev bygget, og at modellen stadig passer til systemet.\n\nI en sikker udviklingslivscyklus foregår trusselsmodellering i designfasen og igen, når en ændring krydser en tillidsgrænse, tilføjer en ny datatype eller indfører en ny ekstern afhængighed. NIST SP 800-218 (SSDF) praksis PW.1.1 nævner udtrykkeligt trusselsmodellering, angrebsmodellering og kortlægning af angrebsfladen som former for risikomodellering til at vurdere sikkerhedskrav. Værktøjerne spænder fra whiteboards til Microsoft Threat Modeling Tool, OWASP Threat Dragon og kodebaserede tilgange som pytm og Threagile, der genererer diagrammer og fund ud fra en model, der ligger i versionsstyring.\n\nTypiske fejl er at modellere én gang og aldrig opdatere, at producere en lang liste generiske trusler uden tilknyttede beslutninger og at gå for dybt i én komponent og overse integrationerne, hvor de fleste reelle fejl findes. Trusselsmodellering adskiller sig fra risikovurdering i omfang og timing: en risikovurdering rangordner risici for organisationens aktiver, mens en trusselsmodel undersøger, hvordan et bestemt system kan angribes, tidligt nok til at ændre designet. Den adskiller sig også fra penetrationstest, der finder fejl i det, der allerede er bygget."},"edges":[{"type":"requires","to":"security/threat","confidence":"high","strength":"normal"},{"type":"requires","to":"security/asset","confidence":"high","strength":"normal"},{"type":"part-of","to":"security/secure-development-lifecycle","confidence":"high","strength":"normal"},{"type":"mitigates","to":"security/vulnerability","why":{"en":"Weak spots in the design are found and fixed before they are built into the system.","da":"Svage punkter i designet findes og rettes, før de bygges ind i systemet."},"confidence":"high","strength":"primary"}],"depth":2,"sources":[{"title":"OWASP Cheat Sheet Series - Threat Modeling","url":"https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html","tier":"reference","publisher":"OWASP"},{"title":"Threat Modeling Manifesto","url":"https://www.threatmodelingmanifesto.org/","tier":"reference"}],"draft":true}