En nyttig trusselsmodel forklarer, hvad du beskytter, hvem eller hvad der kan påvirke det, hvor tilliden ændrer sig, og hvordan du vil reducere og teste de vigtigste risici. Start med det faktiske projekt frem for en generisk liste over værktøjer.
Definér et omfang, der er lille nok til at kunne ræsonneres om
Start med én fungerende tjeneste: en kundeportal, et publiceringssite eller en intern applikation. Skriv de komponenter ned, du driver, og de eksterne systemer, du er afhængig af. En trusselsmodel bør synliggøre antagelser, ikke antyde, at ethvert muligt angreb er løst. Hold den første version lille nok til, at de personer, der udruller applikationen, kan forklare den uden en separat konsulent til at fortolke diagrammet.
List de værdifulde resultater og aktiver. Det kan omfatte kundedata, administrationsadgang, betalingstilstand, publiceret indhold og evnen til at genoprette tjenesten. Tilgængelighed kan være et aktiv, selv når oplysningerne er offentlige. Beslut, hvilke fejl der ville være besværlige, og hvilke der ville skade personer eller organisationen. Den sondring hjælper dig med at prioritere kontroller i stedet for at behandle enhver advarsel ens.
Tegn de steder, hvor tilliden ændrer sig
OWASPs vejledning om trusselsmodellering bruger dataflows og tillidsgrænser til at gøre et design forståeligt. For en lille hostet applikation tegner du browseren, webprocessen, databasen, administratoren, destinationsmålet for sikkerhedskopier og eksterne integrationer. Markér de oplysninger, der bevæger sig mellem dem. En anmodning, der krydser fra en ubetroet klient ind i en privilegeret serverhandling, fortjener eksplicit validering og autorisation.
Antag ikke, at det at være inde i den samme maskine gør enhver komponent lige så betroet. En offentlig uploadproces bør ikke have samme tilladelser som databaseadministration. Et sikkerhedskopijob kan have brug for læseadgang uden evnen til at ændre aktive applikationsposter. Adskillelse af disse roller gør virkningen af en kompromitteret komponent lettere at inddæmme og de nødvendige tilladelser lettere at gennemgå.
Vælg konkrete fejlscenarier
Brug en håndfuld sandsynlige hændelser til at udfordre designet. En angriber stjæler en administratoradgangskode; en bruger anmoder om en anden brugers post; en upload fylder disken; en udrulning blotlægger en konfigurationsfil; en gendannelseskopi kan ikke gendannes. Beskriv startbetingelsen, den berørte komponent og konsekvensen. Et specifikt scenarie er lettere at teste end en bred instruktion om at forbedre sikkerheden.
Medtag fejl og misbrug af legitime arbejdsgange såvel som ekstern indtrængen. Et nyt forsøg kan skabe to værdifulde handlinger, eller to anmodninger kan kappes om at ændre det samme objekt. OWASPs vejledning om forretningslogik fremhæver disse antagelser om processer. Kontrollér, hvem der har tilladelse til at flytte en arbejdsgang til dens næste tilstand, og om gentagelse eller omarrangering af en anmodning ændrer resultatet uventet.
| Scenarie | Kontrol, der skal undersøges | Dokumentation, der skal indsamles |
|---|---|---|
| Stjålet administrationslegitimationsoplysning | Begrænset adgang og en anden faktor, hvor det understøttes | Et uautoriseret login kan ikke gennemføres |
| En anden brugers objekt anmodes om | Server-side objektautorisation | En isoleret test returnerer et afvist resultat |
| Disk opbrugt af uploads | Kontroller for størrelse, kvote og opbevaring | En grænse håndhæves, før tjenesten svigter |
| Dubleret arbejdsgangsanmodning | Idempotens og transaktionsgrænser | En gentaget anmodning skaber ét resultat |
Prioritér efter konsekvens og en troværdig vej
Registrér for hvert scenarie dets potentielle konsekvens og de betingelser, der kræves for, at det kan opstå. Undgå at foregive, at en gættet numerisk score er en præcis sandsynlighed. Du kan stadig skelne en interneteksponeret svag adgangskode fra en meget betinget lokal hændelse. Tildel en ejer og et praktisk næste skridt til de vigtige risici, så modellen skaber arbejde, som nogen faktisk kan udføre.
Overvej informationslivscyklussen såvel som kompromittering af applikationen. En diagnostisk eksport kan afsløre unødvendige data under ellers normal drift. Et opbevaret kontofelt kan skabe eksponering længe efter, at dets formål er ophørt. Gennemgang af privatliv kan derfor fjerne oplysninger eller forkorte opbevaringen, mens sikkerhedsgennemgang begrænser adgangen til det, der er tilbage. Begge ændringer hører hjemme i modellen, når de beskytter projektet.
Test kontrollerne i et autoriseret miljø
Opret et stagingmiljø med repræsentative tilladelser og konstruerede poster. Test afvist adgang, anmodningsgrænser, gentagelser af arbejdsgange og gendannelse. Brug ikke rigtige kundedata, når syntetiske data kan demonstrere adfærden. Målet er at verificere kontrollen, ikke at generere imponerende angrebstrafik. Hold dig inden for systemer, du ejer, eller som du udtrykkeligt har tilladelse til at vurdere.
Registrér, hvad der bestod, hvad der fejlede, og hvad der stadig er ukendt. Et scannersultat kan bidrage med bevis, men erstatter ikke en test af applikationens forretningsregler. På samme måde verificerer en netværksbeskyttelsesmulighed ikke objektautorisation eller håndtering af hemmelige filer. Vedhæft de nyttige resultater til scenariet, så fremtidige vedligeholdere forstår, hvorfor en bestemt kontrol findes.
Hold modellen forbundet med forandring
Gennemgå de relevante dele, når du tilføjer en integration, eksponerer et nyt endpoint, ændrer en rettighed eller flytter data til et andet destinationsmål. Du behøver ikke gentegne hele arkitekturen for en mindre tekstændring. Udløseren er en ændret antagelse om adgang, oplysninger eller systemadfærd. Opbevar modellen sammen med dokumentation for udrulning og gendannelse i stedet for at lade den ligge som output fra en engangsworkshop.
SwissOctet leverer et katalog over infrastrukturvalg, ikke en færdig trusselsmodel for applikationen. Vælg den konfiguration og de muligheder, der understøtter dine kontroller, og verificér derefter den udrulning, du bygger. En lille, vedligeholdt model med testede handlinger er mere nyttig end en stor samling sikkerhedsprodukter uden en klar forklaring på de risici, de håndterer.
Din praktiske tjekliste.
- List aktiver og konsekvenser af fejl.
- Tegn dataflows og tillidsgrænser.
- Vælg specifikke scenarier for indtrængen, fejl og arbejdsgange.
- Tildel kontroller og ejere til de vigtige risici.
- Test med syntetiske data i et autoriseret miljø.
- Gennemgå modellen, når en relevant antagelse ændres.
De detaljer, der betyder noget.
Har jeg brug for en formel ramme for at begynde?+
Nej. Et lille diagram og et dokumenteret sæt scenarier kan være nyttigt. En ramme hjælper med at sikre, at du gennemgår risici konsekvent.
Erstatte en sårbarhedsscanner trusselsmodellering?+
Nej. Scannere kan finde tekniske svagheder, mens en trusselsmodel også undersøger designantagelser, tilladelser og forretningsgange.
Hvor ofte bør jeg opdatere modellen?+
Opdatér de berørte dele, når dataflows, integrationer, rettigheder eller eksponeret funktionalitet ændres, og gennemgå uløste risici regelmæssigt.
Gå til kilden.
Disse referencer understøtter de tekniske begreber i denne guide. Følg den aktuelle dokumentation, før du ændrer et produktionssystem.
- OWASP: Cheat Sheet til trusselsmodellering cheatsheetseries.owasp.org
- OWASP: Trusselsmodellering i praksis devguide.owasp.org
- OWASP: Sikkerhed for forretningslogik cheatsheetseries.owasp.org
Redaktionel vejledning af SwissOctet. Eksempler er illustrative. Servicespecifikationer, tilgængelige valgmuligheder og kontraktvilkår skal verificeres separat.