Trusselsmodellering for apps: en enkel metode til hverdagen

Når apps håndterer login, betaling, persondata eller integrationer til andre systemer, opstår der hurtigt flere angrebsflader, end man umiddelbart ser. Trusselsmodellering gør det lettere at få overblik: Hvad forsøger vi at beskytte, hvem kan angribe, og hvor kan noget gå galt? Nøglen i en travl hverdag er at bruge en letvægtsproces, der kan gentages ved nye features, ændrede integrationer og større release-milesten.

Trusselsmodellering handler i praksis om at stille de rigtige spørgsmål tidligt. Start med at afgrænse en funktion eller et flow, for eksempel “opret konto”, “nulstil adgangskode” eller “upload dokument”. Beskriv derefter systemets vigtigste dele: klient (mobil/web), API, databaser, tredjepartstjenester og eventuelle baggrundsjobs. Et simpelt diagram er ofte nok, så længe dataflow og trust boundaries (overgange mellem komponenter med forskellig tillid) er tydelige.

Dernæst identificeres aktiverne: brugeridentiteter, sessions, adgangstokens, betalingsdata, forretningskritiske regler, logdata og personoplysninger. I en dansk kontekst vil persondata ofte også være koblet til krav om fortrolighed og integritet, og dermed et ekstra fokuspunkt. Når aktiverne er tydelige, er det lettere at se, hvilke konsekvenser et brud kan få, og hvilke kontroller der bør prioriteres.

Som en enkel metode kan du bruge en kort trusselsliste pr. flow. Tænk i kategorier som: spoofing (udgive sig for at være en anden), tampering (ændre data), information disclosure (læk), denial of service (overbelastning) og elevation of privilege (opnå højere rettigheder). Du behøver ikke formelle rammer for at få værdi; det vigtigste er konsistens, så teamet bruger samme sprog fra sprint til sprint.

Smart steps Applikationssikkerhed i hverdagen

En praktisk tilgang er at gøre trusselsmodellering til en fast del af planlægningen for ændringer, der påvirker dataflow eller adgangskontrol. Et “smart steps Applikationssikkerhed”-forløb kan være fem korte trin, der kan klares på 15–30 minutter:

1) Afgræns scenariet: Én brugerhistorie eller ét endpoint-adfærd ad gangen. 2) Skitser dataflow: Hvor kommer data fra, hvor behandles de, hvor gemmes de, og hvor sendes de hen? 3) Find trust boundaries: Hvor krydser data fra en mindre betroet zone (klient/internet) til en mere betroet (API/databaser)? 4) Skriv 5–10 trusler: Brug faste kategorier og vær konkret (f.eks. “token kan stjæles fra lokal lagring” frem for “der kan ske et hack”). 5) Vælg kontroller og tests: Hvilke ændringer i design, konfiguration eller test kan reducere risikoen?

For at holde metoden let kan du føre resultaterne ind i samme værktøj, som I bruger til krav og bugs. En kort note pr. trussel med “årsag → konsekvens → kontrol” er ofte tilstrækkeligt. Det gør det også nemmere at følge op: Når koden ændres, kan truslerne revideres uden at starte forfra.

Applikationssikkerhed: hvad skal du kigge efter først?

Når tiden er knap, giver det mening at prioritere efter både sandsynlighed og effekt. Følgende områder går igen i mange apps og giver typisk høj sikkerhedsværdi, hvis de gennemgås systematisk som del af applikationssikkerhed:

Adgangskontrol og roller: Tjek, at alle kritiske handlinger autoriseres server-side, og at objektadgang (f.eks. dokumenter, profiler eller ordrer) ikke kan omgås ved at ændre ID’er. Mange fejl opstår, når klienten antages at være “ærlig”.

Autentifikation og sessioner: Overvej risiko ved token-læk, genbrug af sessions, svage nulstillingsflows og manglende beskyttelse mod brute force. Tænk også i livscyklus: udløb, rotation, logout og håndtering af kompromitterede enheder.

Inputvalidering og datahåndtering: Identificér hvor brugerinput ender (SQL, søgninger, filnavne, skabeloner). Vurder risiko for injection, path traversal og uventede filtyper. Overvej også, om fejlbeskeder kan lække detaljer om systemet.

Databeskyttelse: Kortlæg, hvilke data der er følsomme, og hvordan de beskyttes under transport og i hvile. Trusselsmodellering hjælper med at afgøre, hvor kryptering, nøglestyring og adskillelse af data er mest relevant.

Logning og overvågning: Spørg, hvilke hændelser der bør logges for at kunne opdage misbrug, og om logs kan indeholde persondata eller tokens. Et godt princip er at logge sikkerhedsrelevante hændelser, men minimere følsomme data i loglinjer.

Afhængigheder og tredjepart: Hvis appen bruger SDK’er, identitetsudbydere, betalingsgateways eller cloud-tjenester, bør trusler også omfatte fejlkonfiguration, scopes/permissions og leverandørens driftsrisici.

Softwareudviklingsløsninger til applikationssikkerhed

Trusselsmodellering giver mest værdi, når den kobles til konkrete udviklingsaktiviteter. Softwareudviklingsløsninger til applikationssikkerhed handler derfor ikke kun om værktøjer, men om arbejdsgange, der gør sikkerhed målbar og gentagelig.

En effektiv praksis er at knytte hver identificeret trussel til én af tre typer handlinger: designkontrol (ændring i arkitektur), implementeringskontrol (kode og konfiguration) eller verifikation (test og monitorering). Eksempler:

Designkontrol: Indfør tydelige trust boundaries, brug least privilege for servicekonti, og adskil administrative flows fra almindelige brugerflows.

Implementeringskontrol: Server-side autorisation på alle endpoints, sikre standarder for filupload, beskyttelse mod CSRF hvor relevant, stramme CORS-regler og en konsekvent strategi for secrets.

Verifikation: Sikkerhedstests i CI (for eksempel statisk kodeanalyse), dependency scanning, målrettede tests for adgangskontrol (misuse cases) og kontrollerede negative tests, der bekræfter, at systemet afviser ugyldige anmodninger.

For at gøre det hverdagsvenligt kan du oprette en enkel “trussels-checkliste” pr. komponent (API, mobilklient, admin-portal). Når et nyt endpoint tilføjes, gennemgås checklisten hurtigt. Over tid bliver det et fælles sprog, som gør code review skarpere og designbeslutninger mere gennemsigtige.

Trusselsmodellering bør også opdateres, når konteksten ændrer sig: nye integrationspartnere, ændret datalagring, nye tilladelser i en mobilapp eller nye regulatoriske krav. I stedet for at se modellen som et dokument, kan du se den som en log over beslutninger: Hvilke risici så vi, hvilke kontroller valgte vi, og hvad udestår?

Til sidst er det værd at huske, at en “enkel metode” ikke betyder overfladisk. Små, hyppige vurderinger fanger ofte flere realistiske problemer end sjældne, tunge workshops. Når trusselsmodellering er en del af daglig udvikling, bliver applikationssikkerhed mere forudsigelig: færre overraskelser sent i forløbet, bedre prioritering af sikkerhedsarbejde og en mere robust app, der bedre tåler fejl, misbrug og uventede scenarier.