Hvordan bliver du specialist i trusselsmodellering?

• Forstå forskellen på trusselsmodellering, penetrationstest og almindelig risikovurdering.
• Lær at arbejde med dataflow, aktiver, misbrugs-cases, sikkerhedskrav og risikolog.
• Vælg metode efter systemets modenhed, forretningsrisiko og den type angreb, der skal analyseres.
• Byg en portefølje, der viser en konkret model, tydelige antagelser og realistiske afbødningsforslag.

En specialist i trusselsmodellering arbejder med en struktureret sikkerhedsaktivitet, hvor et team identificerer, prioriterer og reducerer mulige trusler mod et system, før svaghederne bliver dyre at rette eller udnyttes i drift. Rollen ligger derfor tæt på både softwarearkitektur, risikostyring, DevSecOps og praktisk cybersikkerhed.

En specialist arbejder sjældent isoleret. Opgaven er at få udviklere, produktejere, arkitekter, sikkerhedsfolk og risikointeressenter til at forstå, hvor systemets vigtigste angrebsflader er, og hvilke beslutninger der skal træffes. Det kræver teknisk viden, men også evnen til at stille præcise spørgsmål, dokumentere antagelser og omsætte sikkerhedsfund til krav, som et produktteam faktisk kan implementere.

Hvad laver en specialist i trusselsmodellering?

En trusselsmodelleringsspecialist analyserer systemer ud fra, hvad der kan gå galt, hvem der kan misbruge en funktion, og hvilke kontroller der bør være på plads. Det sker typisk ved at tegne dataflowdiagrammer, beskrive aktiver og tillidsgrænser, identificere relevante trusler og føre resultaterne ind i en risikolog eller backlog. Arbejdet er mest værdifuldt, når det sker tidligt i designet og gentages, når arkitekturen ændrer sig.

I danske og europæiske organisationer vil ansvaret ofte være fordelt mellem flere roller. En Security Architect kan eje metode og kvalitet, en Product Security Engineer kan drive workshops med udviklingsteamet, en DevSecOps-profil kan koble fund til pipelines og sikkerhedstest, mens en Risk Manager kan sikre, at prioriteringen passer til virksomhedens risikoramme. I mindre teams kan den samme person udfylde flere af disse funktioner, men de centrale opgaver er de samme: modellering, risikovurdering, samarbejde med udviklere, formulering af sikkerhedskrav og dokumentation.

Det er vigtigt at skelne trusselsmodellering fra penetrationstest. En penetrationstest undersøger ofte et eksisterende system for udnyttelige svagheder, mens trusselsmodellering hjælper teamet med at forudse mulige angrebsveje og designe kontroller tidligere i livscyklussen. De to discipliner supplerer hinanden, men de har forskellige tidspunkter, artefakter og succeskriterier.

Sådan forankres trusselsmodellering i SDLC og DevSecOps

Trusselsmodellering fungerer bedst, når den bliver en fast del af softwareudviklingsprocessen frem for en lejlighedsvis sikkerhedsworkshop. I praksis betyder det, at nye produkter og større ændringer gennemgår en kort modellering ved krav- eller designgates, og at modellen opdateres, når væsentlige dataflows, integrationer eller tillidsgrænser ændrer sig. De vigtigste artefakter er typisk et dataflowdiagram, en liste over aktiver, misbrugs-cases, sikkerhedskrav og en risikolog med ejere.

I agile miljøer kan trusselsmodellering knyttes til sprintplanlægning, refinement eller PI-planlægning. Et team behøver ikke modellere hele platformen på én gang. En mere realistisk start er at vælge én kritisk brugerrejse, eksempelvis login, betaling, filupload eller administration af brugerrettigheder, og bruge workshoppen til at finde de mest alvorlige risici, som kan omsættes til backlog-elementer før næste release.

Effekten bør måles på adfærd og timing, ikke kun på antallet af modeller. Gode indikatorer er, om højrisikofund flyttes fra sen test til designfasen, om kritiske dataflows har en opdateret model, og hvor hurtigt et team går fra identificeret trussel til aftalt afbødning. Den type måling gør trusselsmodellering mere operationel og mindre afhængig af enkeltpersoners entusiasme.

Metoder: STRIDE, PASTA og attack trees i praksis

Metodevalget bør følge problemet. STRIDE passer godt til komponent- og dataflowtunge web-, SaaS- og integrationssystemer, fordi metoden hjælper teamet med systematisk at tænke over spoofing, tampering, repudiation, information disclosure, denial of service og elevation of privilege. Den fungerer bedst, når arkitekturen kan tegnes tydeligt, og når teamet kan identificere tillidsgrænser mellem brugere, tjenester, databaser og tredjepartssystemer.

PASTA er mere nyttig, når trusselsmodelleringen skal kobles tæt til forretningsmål, risikoscenarier og beslutninger på tværs af teknik og governance. Den kan være relevant i finans, sundhed, offentlig sektor og andre miljøer, hvor en teknisk svaghed skal forstås i forhold til forretningspåvirkning, regulatoriske krav og prioritering af kontroller. Til gengæld kræver PASTA mere modenhed, flere interessenter og mere tid end en enkel STRIDE-workshop.

Attack trees er stærke, når teamet vil undersøge et bestemt scenarie i dybden, for eksempel kontoovertagelse, betalingssvindel, misbrug af rabatkoder eller uautoriseret adgang til et administrativt panel. De hjælper med at bryde angriberens mål ned i mulige trin og forudsætninger. DREAD nævnes stadig i ældre materiale, men bruges sjældnere som primær prioriteringsmodel i moderne teams, fordi scoringerne let bliver subjektive uden en tydelig risikoramme.

Mini-case: checkout-flow i en webapplikation

Et konkret eksempel viser, hvordan arbejdet kan se ud. Antag, at et produktteam driver en webbaseret checkout, hvor en kunde lægger varer i kurven, logger ind, indtaster leveringsoplysninger, betaler via en ekstern betalingsudbyder og modtager en ordrebekræftelse. Teamets første opgave er at beskrive systemet uden at drukne i detaljer.

Med STRIDE kan teamet derefter analysere trusler pr. dataflow. Spoofing kan handle om kaprede kundekonti eller falske callbacks fra betalingsudbyderen. Tampering kan være manipulation af pris eller rabatkode i klienten. Information disclosure kan opstå, hvis ordrebekræftelser eller supportfunktioner eksponerer persondata. Denial of service kan ramme checkout-service eller betalingsintegration, mens elevation of privilege kan opstå, hvis administrative ordrehandlinger ikke adskilles ordentligt fra almindelige brugerfunktioner.

Afbødningen bør være konkret nok til at blive implementeret. Eksempler er server-side validering af pris og rabat, signaturvalidering på betalingscallbacks, stærkere sessionsbeskyttelse, mindst mulige rettigheder mellem services, struktureret auditlogning og dataminimering i ordrebekræftelser. I en DK/EU-kontekst bør modellen også markere, hvilke dataflows der indeholder persondata, hvilket behandlingsgrundlag der gælder, og hvordan retention og adgangsstyring understøtter GDPR og relevante kontroller i ISO/IEC 27005-baseret risikostyring.

OWASP Threat Modeling Cheat Sheet, ENISA Threat Landscape, ISO/IEC 27005 og Microsoft Threat Modeling Tool-dokumentationen er nyttige referencepunkter, men de bør ikke behandles som skabeloner, der kan kopieres ukritisk. De hjælper med terminologi, metode og risikotænkning, mens den konkrete model stadig skal afspejle organisationens arkitektur, trusselsbillede og regulatoriske forpligtelser.

Færdigheder, der gør rollen troværdig

Et solidt fundament i sikkerhedsarkitektur er nødvendigt, men det er ikke nok. En dygtig specialist forstår autentifikation, autorisation, kryptering, logging, netværk, cloud-tjenester, API-design og almindelige webangreb. Samtidig skal vedkommende kunne læse arkitekturdiagrammer, stille spørgsmål til trust boundaries og forklare risiko på en måde, som både udviklere og ledere kan handle på.

Softwareforståelse er særlig vigtig. Trusselsmodellering bliver overfladisk, hvis specialisten ikke forstår, hvordan data bevæger sig gennem en applikation, hvordan services kalder hinanden, eller hvordan fejl i køer, webhooks, identitetsflows og tredjepartsintegrationer skaber angrebsflader. Kendskab til CI/CD, cloud-native arkitektur og sikkerhedskrav i user stories gør arbejdet mere relevant for moderne produktteams.

Derudover kræver rollen moden risikotænkning. Alle fund kan ikke behandles som kritiske, og ikke alle kontroller er realistiske i samme release. Specialisten skal kunne skelne mellem teoretiske trusler og sandsynlige misbrugsscenarier, dokumentere antagelser og hjælpe teamet med at vælge de afbødninger, der reducerer mest risiko uden at blokere produktudviklingen unødigt.

Karriereveje og ansættelsesvirkelighed i DK/EU

Stillingsbetegnelsen “Threat Modeling Specialist” findes, men mange relevante jobs bruger andre titler. I Danmark og EU ses arbejdet ofte i roller som Security Architect, Application Security Engineer, Product Security Engineer, DevSecOps Engineer, Cloud Security Specialist, Security Consultant eller Risk and Compliance Specialist. Det afgørende er ikke titlen, men om rollen arbejder med designrisiko, softwarelivscyklus, sikkerhedskrav og tværfaglig prioritering.

Interviewprocesser kan indeholde en praktisk opgave, hvor kandidaten skal gennemgå et systemdiagram, identificere trusler og foreslå kontroller. Arbejdsgivere lægger typisk mærke til, om kandidaten kan forklare antagelser, afgrænse analysen og prioritere fund. En lang liste af mulige angreb er mindre overbevisende end en kort, veldokumenteret model med tydelige risikobeslutninger.

En portefølje kan gøre erfaring synlig, også for kandidater uden en formel titel inden for trusselsmodellering. Et sanitiseret eksempel med DFD, STRIDE-noter, risikolog, antagelser og et kort readme-dokument viser, hvordan kandidaten tænker. Et lille GitHub-repository med skabeloner, eksempelmodeller og prioriteringskriterier kan være nyttigt, så længe det ikke indeholder fortrolige oplysninger fra tidligere arbejdsgivere eller kunder.

Certificeringer og læringsvalg

Der findes ikke én universel certificering, der alene gør en person til specialist i trusselsmodellering. Certificeringer kan dog give struktur, fælles sprog og dokumentation for beslægtede kompetencer. Valget bør afhænge af, om kandidaten mangler grundlæggende sikkerhedsviden, software security, offensiv forståelse, risikostyring eller trusselsefterretning.

Begyndere kan bruge CompTIA Security+ til at opbygge et bredt fundament i sikkerhedsbegreber, risici og kontroller. Kandidater med arkitektur- eller governanceansvar kan se på CISSP, fordi pensum dækker risikostyring, sikkerhedsarkitektur og sikker softwareudvikling. Softwarefolk, der vil tættere på secure SDLC, kan overveje CSSLP, mens CEH kan styrke forståelsen af angrebsveje og teknikker. CTIA er relevant, når trusselsmodelleringen skal informeres af trusselsefterretning og aktuelle modstanderprofiler.

Readynez kan være et relevant sted at undersøge certificeringsforberedelse, hvis læringsplanen skal kobles til etablerede sikkerhedscertificeringer. Det bør dog ses som et supplement til praktisk arbejde: læsning af arkitektur, deltagelse i designreviews, facilitering af workshops og opbygning af realistiske modelartefakter.

Sådan bygger erfaringen op uden at vente på den perfekte titel

Den mest realistiske vej ind i området er at begynde med et afgrænset system eller en kritisk brugerrejse. En udvikler kan modellere en ny API-integration. En DevOps-profil kan analysere deployment-pipeline og secrets-håndtering. En risiko- eller complianceprofil kan koble persondataflows, behandlingsgrundlag og sikkerhedskrav til en teknisk model.

Det første mål bør være kvalitet frem for volumen. En enkel model, der tydeligt viser aktiver, dataflows, tillidsgrænser, antagelser, trusler og afbødninger, er mere værd end et stort diagram uden beslutninger. Når teamet har prøvet processen på én brugerrejse, kan metoden gentages ved nye releases, større arkitekturændringer og integrationer med høj risiko.

Der opstår ofte organisatoriske barrierer. Nogle teams frygter, at sikkerhed bremser leverancer, mens andre ikke ved, hvem der ejer modellen efter workshoppen. Derfor bør trusselsmodellering afsluttes med konkrete backlog-elementer, ejere og en aftale om, hvornår modellen opdateres. Uden ejerskab bliver dokumentet hurtigt historisk; med ejerskab bliver det et levende designværktøj.

Ofte stillede spørgsmål om trusselsmodellering som karriere

Skal man kunne kode for at arbejde med trusselsmodellering?

Man behøver ikke nødvendigvis være fuldtidsudvikler, men man skal forstå softwarearkitektur, API'er, identitet, dataflow og almindelige fejlkilder i moderne systemer. Jo tættere rollen er på applikationssikkerhed og produktteams, desto mere værdifuld bliver praktisk kode- og arkitekturforståelse.

Er trusselsmodellering det samme som penetrationstest?

Nej. Penetrationstest undersøger typisk et eksisterende system for sårbarheder, mens trusselsmodellering bruges til at identificere og prioritere mulige trusler under design og ændringer. Resultater fra penetrationstest kan dog forbedre fremtidige modeller, fordi de viser, hvor antagelser eller kontroller ikke holdt i praksis.

Hvilken metode bør en nybegynder starte med?

STRIDE er ofte det mest tilgængelige udgangspunkt, fordi metoden passer godt til dataflowdiagrammer og almindelige web- eller SaaS-arkitekturer. Når teamet senere skal koble analysen tættere til forretningsrisiko, regulatoriske krav eller scenarier som svindel og kontoovertagelse, kan PASTA eller attack trees give mere dybde.

Hvordan viser man erfaring, hvis man ikke har haft titlen før?

En god vej er at udarbejde en sanitiseret eksempelmodel, der ikke afslører fortrolige oplysninger. Modellen bør indeholde DFD, metodevalg, antagelser, prioriterede trusler, anbefalede kontroller og en kort forklaring af, hvorfor visse risici blev prioriteret over andre.

Næste skridt mod en stærkere trusselsmodelleringsprofil

En karriere inden for trusselsmodellering bygges bedst gennem en kombination af sikkerhedsfundament, softwareforståelse, metodevalg og dokumenteret praksis. Rollen handler mindre om at kende alle angreb og mere om at skabe en proces, hvor de vigtigste trusler bliver synlige tidligt nok til, at et team kan gøre noget ved dem.

Et praktisk næste skridt er at vælge et kendt system, modellere én kritisk brugerrejse og skrive resultaterne i et format, der kunne bruges i et rigtigt designreview. Kandidater, der samtidig vil strukturere deres certificeringsforberedelse, kan undersøge Readynez Unlimited Security Training som en fleksibel mulighed for at opbygge bredere sikkerhedskompetencer ved siden af praktiske projekter.