En nyttig trusselmodell forklarer hva du beskytter, hvem eller hva som kan påvirke det, hvor tillit endres, og hvordan du vil redusere og teste de viktigste risikoene. Start med det faktiske prosjektet i stedet for en generisk verktøyliste.
Definer et omfang som er lite nok til å resonnere om
Start med én fungerende tjeneste: en kundeportal, et publiseringsnettsted eller en intern applikasjon. Skriv ned komponentene du drifter, og de eksterne systemene du er avhengig av. En trusselmodell bør gjøre antakelser synlige, ikke antyde at ethvert mulig angrep er løst. Hold den første versjonen liten nok til at de som drifter applikasjonen, kan forklare den uten en separat konsulent som tolker diagrammet.
List opp de verdifulle resultatene og verdiene. Disse kan omfatte kundedata, administrasjonstilgang, betalingsstatus, publisert innhold og evnen til å gjenopprette tjenesten. Tilgjengelighet kan være en verdi selv når informasjonen er offentlig. Bestem hvilke feil som ville være upraktiske, og hvilke som ville skade personer eller organisasjonen. Denne forskjellen hjelper deg med å prioritere kontroller i stedet for å behandle hver advarsel likt.
Tegn opp stedene der tillit endres
OWASPs veiledning for trusselmodellering bruker dataflyter og tillitsgrenser for å gjøre en utforming forståelig. For en liten driftet applikasjon: tegn nettleseren, nettprosessen, databasen, administratoren, sikkerhetskopidestinasjonen og eksterne integrasjoner. Merk informasjonen som beveger seg mellom dem. En forespørsel som krysser fra en ikke-klarert klient til en privilegert serveroperasjon, fortjener eksplisitt validering og autorisasjon.
Ikke anta at det å være inne i samme maskin gjør hver komponent like klarert. En offentlig opplastingsprosess bør ikke ha samme rettigheter som databaseadministrasjon. En sikkerhetskopijobb kan trenge lesetilgang uten evnen til å endre aktive applikasjonsposter. Å skille disse rollene gjør effekten av en kompromittert komponent lettere å begrense, og de nødvendige rettighetene lettere å gjennomgå.
Velg konkrete feilscenarioer
Bruk en håndfull plausible hendelser til å utfordre utformingen. En angriper stjeler et administratorpassord; en bruker ber om en annen brukers post; en opplasting fyller disken; en utrulling eksponerer en konfigurasjonsfil; en gjenopprettingskopi kan ikke gjenopprettes. Beskriv starttilstanden, den berørte komponenten og konsekvensen. Et spesifikt scenario er lettere å teste enn en bred instruksjon om å forbedre sikkerheten.
Inkluder feil og misbruk av legitim arbeidsflyt, så vel som ekstern inntrenging. Et nytt forsøk kan skape to verdifulle operasjoner, eller to forespørsler kan kappes om å endre det samme objektet. OWASPs veiledning for forretningslogikk fremhever disse prosessantakelsene. Sjekk hvem som har lov til å flytte en arbeidsflyt til neste tilstand, og om gjentakelse eller omorganisering av en forespørsel endrer resultatet uventet.
| Scenario | Kontroll som skal undersøkes | Bevis som skal samles inn |
|---|---|---|
| Stjålet administrasjonspåloggingsdata | Begrenset tilgang og en andre faktor der det støttes | En uautorisert pålogging kan ikke fullføres |
| En annen brukers objekt forespurt | Server-side objektautorisasjon | En isolert test returnerer et avvist resultat |
| Disk fylt opp av opplastinger | Størrelses-, kvote- og oppbevaringskontroller | En grense håndheves før tjenestesvikt |
| Duplisert arbeidsflytforespørsel | Idempotens og transaksjonsgrenser | En gjentatt forespørsel skaper ett resultat |
Prioriter etter konsekvens og en troverdig vei
For hvert scenario: registrer potensiell konsekvens og betingelsene som kreves for at det skal inntreffe. Unngå å late som en gjettet numerisk poengsum er en presis sannsynlighet. Du kan fortsatt skille et internett-eksponert svakt passord fra en svært betinget lokal hendelse. Tildel en eier og et praktisk neste steg til de viktige risikoene, slik at modellen skaper arbeid noen faktisk kan fullføre.
Vurder informasjonslivssyklusen så vel som applikasjonskompromittering. En diagnostisk eksport kan avsløre unødvendige data under ellers normal drift. Et oppbevart kontofelt kan skape eksponering lenge etter at formålet er avsluttet. Personvernvurdering kan derfor fjerne informasjon eller forkorte oppbevaringen, mens sikkerhetsvurdering begrenser tilgangen til det som gjenstår. Begge endringene hører hjemme i modellen når de beskytter prosjektet.
Test kontrollene i et autorisert miljø
Opprett et testmiljø med representative tillatelser og konstruerte poster. Test avvist tilgang, forespørselsgrenser, arbeidsflytomkjøringer og gjenoppretting. Ikke bruk reelle kundedata når syntetiske data kan demonstrere atferden. Målet er å verifisere kontrollen, ikke å generere imponerende angrepstrafikk. Hold deg innenfor systemer du eier eller er eksplisitt autorisert til å vurdere.
Registrer hva som bestod, hva som feilet og hva som fortsatt er ukjent. Et skannerresultat kan bidra med bevis, men erstatter ikke en test av applikasjonens forretningsregler. På samme måte verifiserer ikke et nettverksbeskyttelsesalternativ objektautorisasjon eller håndtering av hemmelige filer. Legg de nyttige resultatene ved scenariet slik at fremtidige vedlikeholdere forstår hvorfor en bestemt kontroll finnes.
Hold modellen koblet til endring
Gjennomgå de relevante delene når du legger til en integrasjon, eksponerer et nytt endepunkt, endrer en rettighet eller flytter data til et annet mål. Du trenger ikke tegne hele arkitekturen på nytt for en mindre tekstendring. Utløseren er en endret antakelse om tilgang, informasjon eller systematferd. Oppbevar modellen sammen med distribusjons- og gjenopprettingsdokumentasjon i stedet for å la den ligge som et engangsresultat fra en workshop.
SwissOctet leverer en katalog over infrastrukturvalg, ikke en ferdig trusselmodell for applikasjonen. Velg konfigurasjonen og alternativene som støtter kontrollene dine, og verifiser deretter distribusjonen du bygger. En liten, vedlikeholdt modell med testede handlinger er mer nyttig enn en stor samling sikkerhetsprodukter uten en klar forklaring på hvilke risikoer de håndterer.
Din praktiske sjekkliste.
- List opp ressurser og konsekvenser av feil.
- Tegn dataflyter og tillitsgrenser.
- Velg spesifikke scenarier for inntrenging, feil og arbeidsflyt.
- Tildel kontroller og eiere til de viktige risikoene.
- Test med syntetiske data i et autorisert miljø.
- Gjennomgå modellen når en relevant antakelse endres.
Detaljene som betyr noe.
Trenger jeg et formelt rammeverk for å komme i gang?+
Nei. Et lite diagram og et dokumentert sett med scenarier kan være nyttig. Et rammeverk hjelper deg med å gjennomgå risikoer konsekvent.
Erstatte en sårbarhetsskanner trusselmodellering?+
Nei. Skannere kan finne tekniske svakheter, mens en trusselmodell også undersøker designantakelser, tillatelser og forretningsarbeidsflyter.
Hvor ofte bør jeg oppdatere modellen?+
Oppdater de berørte delene når dataflyter, integrasjoner, rettigheter eller eksponert funksjonalitet endres, og gjennomgå uløste risikoer regelmessig.
Gå til kilden.
Disse referansene støtter de tekniske konseptene i denne veiledningen. Følg gjeldende dokumentasjon før du endrer et produksjonssystem.
- OWASP: Jukseark for trusselmodellering cheatsheetseries.owasp.org
- OWASP: Trusselmodellering i praksis devguide.owasp.org
- OWASP: Sikkerhet for forretningslogikk cheatsheetseries.owasp.org
Redaksjonell veiledning av SwissOctet. Eksempler er illustrerende. Tjenestespesifikasjoner, tilgjengelige alternativer og kontraktsvilkår må verifiseres separat.