{"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://atlas.maintz.dev/)"},"id":"security/threat-modelling","url":{"en":"https://atlas.maintz.dev/en/terms/security/threat-modelling/","da":"https://atlas.maintz.dev/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."},"howTo":{"steps":{"en":["Pick what to model, such as a new system, a new feature or a change that crosses a trust boundary, and book a session with the architect, developers, product owner and someone from security.","Draw a data flow diagram with users, external systems, processes, data stores, data flows and trust boundaries, and agree that it matches how the system really works.","Walk through each element and flow with STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege), and add LINDDUN where personal data is involved.","Decide for each threat whether to mitigate it, remove it by changing the design, transfer it or accept it, and name an owner for every accepted risk.","Record the mitigations as security requirements or backlog items with acceptance criteria, so they are built and tested like any other feature.","Keep the diagram and the threat list in version control next to the code, drawn in a tool such as OWASP Threat Dragon or the Microsoft Threat Modeling Tool.","Check before release that the mitigations were built, through tests, code review or a penetration test aimed at the threats you found.","Update the model when the design changes, a new integration or type of data is added, or an incident shows that a threat was missed."],"da":["Vælg, hvad der skal modelleres, fx et nyt system, en ny funktion eller en ændring, der krydser en tillidsgrænse, og book en session med arkitekten, udviklerne, produktejeren og en fra sikkerhed.","Tegn et dataflowdiagram med brugere, eksterne systemer, processer, datalagre, dataflows og tillidsgrænser, og bliv enige om, at det svarer til, hvordan systemet faktisk fungerer.","Gå hvert element og hvert flow igennem med STRIDE (spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege), og tilføj LINDDUN, hvor der indgår personoplysninger.","Beslut for hver trussel, om den skal afhjælpes, fjernes ved at ændre designet, overføres eller accepteres, og udpeg en ejer for hver accepteret risiko.","Registrér modforanstaltningerne som sikkerhedskrav eller backlog-punkter med acceptkriterier, så de bygges og testes som enhver anden funktion.","Gem diagrammet og trusselslisten i versionsstyring ved siden af koden, tegnet i et værktøj som OWASP Threat Dragon eller Microsoft Threat Modeling Tool.","Tjek før release, at modforanstaltningerne er bygget, via test, code review eller en penetrationstest rettet mod de trusler, I fandt.","Opdatér modellen, når designet ændres, en ny integration eller datatype kommer til, eller en hændelse viser, at en trussel blev overset."]},"pitfalls":{"en":["Modelling once at the start of the project and never updating the diagram.","Producing a long list of generic threats with no decisions, owners or backlog items attached.","Leaving the work to one security expert instead of the team that builds the system.","Going deep into one component and missing the integrations between systems, where many real flaws sit."],"da":["At modellere én gang i starten af projektet og aldrig opdatere diagrammet.","At producere en lang liste generiske trusler uden beslutninger, ejere eller backlog-punkter.","At overlade arbejdet til én sikkerhedsekspert i stedet for det team, der bygger systemet.","At gå i dybden med én komponent og overse integrationerne mellem systemer, hvor mange reelle fejl findes."]},"guides":[{"title":"OWASP Cheat Sheet Series - Threat Modeling","url":"https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html","publisher":"OWASP","tier":"reference"},{"title":"NIST SP 800-218 - Secure Software Development Framework (SSDF) Version 1.1","url":"https://csrc.nist.gov/pubs/sp/800/218/final","publisher":"NIST","tier":"standard"},{"title":"Microsoft Threat Modeling Tool overview","url":"https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool","publisher":"Microsoft","tier":"official-doc"},{"title":"OWASP Threat Dragon","url":"https://owasp.org/www-project-threat-dragon/","publisher":"OWASP","tier":"reference"}]},"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}