Komplett pensumoversikt for programvaresikkerhet ved NTNU — med forklaringer, sentrale begreper, eksamenstips og vanlige fallgruver. Eksamensoptimalisert basert på tidligere eksamener.
Slik prioriterer du: Eksamensanalyse av 2015, 2018, 2020 og 2023 viser et klart, gjentagende mønster — bruk det til å styre leserekkefølgen. 1. Les først Sikker koding (kodegjennomgang — «finn og fiks sårbarheten» i PHP/Python/Java, 20–30 poeng, fast hvert år), Webapplikasjonssikkerhet (samme kodesnutter tester ofte CSRF/session-svakheter) og Sikkerhetsstyring og modenhetsmodeller (RMF-caset er hovedoppgave i 3 av 4 leste eksamener). 2. Les deretter Trusselmodellering, Kryptografi (inkludert de klassiske regneoppgavene Vigenère og One Time Pad) og Autorisasjon (Bell-LaPadula/Biba-tilgangsmodeller er en tilbakevendende teoribolk). 3. Les til slutt resten av temaene (Autentisering, Sårbarheter, Risikohåndtering, Personvern og menneskelige faktorer) — viktige for helhetsforståelsen, men sjeldnere egne hovedoppgaver. Øv spesielt på kodegjennomgang: last ned ukjent kode og tren på å spore datastrømmen fra input til bruk — det er denne ferdigheten, ikke bare begrepskunnskap, som gir flest poeng på eksamen.
TDT4237 Programvaresikkerhet handler om hvordan man bygger programvare som tåler at noen prøver å misbruke den. Faget tar et gjennomgående defensivt perspektiv: målet er ikke å lære angrepsteknikker for deres egen skyld, men å forstå hvilke svakheter som typisk oppstår i programvare, hvorfor de oppstår, og hvordan utviklere og team kan bygge inn sikkerhet gjennom hele utviklingsløpet — fra kravspesifikasjon og design, via koding og testing, til drift og vedlikehold.
Denne studieguiden er bygget opp rundt åtte temaer som til sammen dekker et typisk sikker programvareutviklingsløp: trusselmodellering (identifisere hva som kan gå galt før koden skrives), sikker koding (unngå vanlige implementasjonsfeil), autentisering og autorisasjon (verifisere hvem brukeren er og hva de har lov til), sårbarheter (kjenne igjen og klassifisere svakhetstyper, blant annet via OWASP Top 10), kryptografi (bruke kryptografiske byggeklosser riktig, ikke oppfinne dem selv), webapplikasjonssikkerhet (spesifikke trusler og mottiltak for webteknologi) og risikohåndtering (prioritere hvilke svakheter som faktisk må fikses først).
Hvert tema har en fagtekst med forklaringer og eksempler, en kort oppsummering, konkrete eksamensråd, en liste med nøkkelbegreper/rammeverk du bør kunne gjengi, og vanlige feil studenter gjør. Bruk oppslagsarket (formelsiden) som repetisjon rett før eksamen, og bruk eksamensstrategien til å forstå hva slags spørsmål som stilles og hvordan du bør disponere tiden. Les gjennom alle temaene i rekkefølge først for helhetsforståelse, gå deretter tilbake til temaer du er usikker på og øv på å forklare begrepene med egne ord og eksempler.
Trusselmodellering er den systematiske, tidlige gjennomgangen som finner designsvakheter ingen verktøy ser. I TDT4237 testes den som misbrukstilfeller, angrepstrær, dataflytdiagram med tillitsgrenser og trusselaktør-rangering — alltid som del av RMF-caset, og alltid med krav om at tekniske risikoer spores tilbake til modellen.
📌 Eksamenshistorikk: Trusselmodellering forekommer på alle åtte leste eksamenssett (2015, 2016, 2018, 2019, 2020, 2021, 2022, 2023), alltid som del av RMF-hovedcaset. Teknikkene som faktisk etterspørres er misbrukstilfeller (misuse cases) og angrepstrær (2016, 2018, 2019, 2020, 2021, 2022 — ofte med krav om «minst to misuse cases og tre attack trees»), dataflytdiagram (DFD) med angrepspunkter (2023), samt angrepsflateanalyse og trusselaktør-rangering (2015, 2022, 2023). Merk: STRIDE og DREAD er ikke nevnt i noe av eksamenssettene eller sensorveiledningene — de er nyttige som støttestruktur når du skal være systematisk, men de er ikke det du blir bedt om å bruke. Øv i stedet på å produsere et misbrukstilfellediagram, et angrepstre og en DFD-beskrivelse under tidspress, og på å utlede minst ti tekniske risikoer fra dem.
Trusselmodellering er en systematisk gjennomgang av et system for å finne ut hva som kan gå galt, gjort tidlig nok til at svaret kan påvirke designet. Det avgjørende poenget — og det argumentet du bør ha klart hvis eksamen spør «hvorfor i det hele tatt trusselmodellere?» — er at de fleste funnene fra en god trusselmodell er designsvakheter, ikke kodefeil: manglende autorisasjon på objektnivå, forutsigbare identifikatorer, usignerte tokens, manglende ratebegrensning, data som returneres til en klient som ikke skulle sett dem. Ingen statisk analysator og ingen sårbarhetsskanner finner disse, fordi det ikke er noe syntaktisk galt med koden. Verktøy finner implementasjonsfeil; trusselmodellering finner designfeil. Erfaringsmessig utgjør de to klassene omtrent halvparten hver av alle sikkerhetsproblemer i programvare.
Et misbrukstilfelle beskrives på nøyaktig samme strukturerte form som et vanlig use case, men aktøren er en misbruker og målet er å skade, svindle eller utnytte systemet. Verdien ligger ikke i listen over misbruk, men i de to relasjonene som binder diagrammet sammen: hvert misbrukstilfelle truer et bestemt legitimt use case, og hvert mottiltak (security use case) demper ett eller flere misbrukstilfeller. Uten disse relasjonene er diagrammet bare to lister, og det er nettopp relasjonene som gjør at man kan utlede sikkerhetskrav direkte fra modellen.
En praktisk fremgangsmåte under eksamen: sett opp de legitime aktørene og deres use cases i venstre kolonne. For hver aktør, spør «hvem kunne ønske å utgi seg for denne?» og «hva kan misbrukes hvis noen har tilgangen denne aktøren har?». Legg til én misbruksaktør per trusselaktørtype du har identifisert. Skriv så mottiltakene i høyre kolonne. Fem til sju misbrukstilfeller er nok til full uttelling i en typisk oppgave; å bruke tid på nummer tolv gir ingenting.
Et angrepstre har angriperens mål i rotnoden — ikke en sårbarhet, ikke en aktør. Under roten forgrener treet seg i alternative veier til målet (ELLER-noder) og i delmål som alle må oppfylles (OG-noder). Nodene annoteres gjerne med anslått kostnad, nødvendig ferdighetsnivå eller oppdagelsessannsynlighet.
Hele nytten ligger i at man deretter kan lese ut den billigste veien til målet. Det er den som må stenges først: å bruke ressurser på å tette en dyr angrepsvei mens en billig står åpen er bortkastet. I praksis viser slike analyser overraskende ofte at den billigste veien ikke krever noen programmeringsfeil i det hele tatt — den utnytter en designbeslutning, en delt innlogging, eller et menneske.
MÅL: Få tak i opplysninger om en bestemt bruker +-- (ELLER) 1. Slå opp direkte i API-et | +-- (OG) 1.1 Skaff gyldig sesjon [lav ferdighet] | +-- (OG) 1.2 Kjenn brukerens id [gratis hvis id er tellbar] +-- (ELLER) 2. Utnytt injeksjon i søkefeltet [middels ferdighet] +-- (ELLER) 3. Kompromitter en administrator | +-- (ELLER) 3.1 Nettfiske [billig] | +-- (OG) 3.2 Omgå flerfaktor [dyrt] +-- (ELLER) 4. Press eller rekrutter en innsider
En DFD har fem elementtyper: eksterne entiteter (aktører og systemer utenfor vår kontroll), prosesser (der data behandles), datalagre, dataflyter (pilene mellom dem) og tillitsgrenser (stiplede linjer som krysser flytene). Kjerneidéen er enkel og verdt å lære utenat: truslene sitter der dataflytene krysser en tillitsgrense. Når grensene er tegnet riktig, faller angrepspunktene nesten ut av seg selv.
En vanlig feil er å tro at en tillitsgrense må følge en maskin- eller nettverksgrense. Den kan like gjerne være logisk: mellom en vanlig brukerrolle og en administratorrolle inne i samme prosess, eller mellom to leietakere i en flerleietakerapplikasjon. En slik grense må håndheves på tjenersiden — å skjule felter i klienten er ikke å håndheve en tillitsgrense.
Typiske grenser i en webapplikasjon: internett↔lastbalanserer, applikasjon↔database, applikasjon↔tredjepartstjeneste (betaling, identitetsleverandør), applikasjon↔skyplattformens driftsplan (den delte ansvarsmodellen), og rolle↔rolle internt.
Eksamen ber gjentatte ganger om at trusselaktørene identifiseres og rangeres etter egne kriterier. De vanlige kriteriene er ferdighet, ressurser, motivasjon og tilgang; noen legger til konsekvens hvis aktøren lykkes. Poengene gis for at kriteriene er eksplisitte og at hver aktør er begrunnet — to kandidater kan rangere ulikt og begge få full uttelling.
| Aktør | Kjennetegn |
|---|---|
| Script kiddie | Lav evne, små ressurser, opportunistisk. Treffer det som tilfeldigvis er sårbart. Avverges av alminnelig hygiene. |
| Insider | Trenger ingen sårbarhet — tilgangen er allerede legitim, og handlingene ser normale ut. Ofte den høyest rangerte i praksis. Forsvar: revisjonslogg, minste privilegium, oppdeling av oppgaver. |
| Organisert kriminalitet | Høy evne, betydelige ressurser, økonomisk motiv. Går etter volum: masseuttrekk, løsepenger, svindel. |
| Hacktivist | Middels evne, ideologisk motiv, ønsker synlighet — defacement, lekkasje, tjenestenekt. |
| Statlig aktør | Svært høy evne, nærmest ubegrensede ressurser, tålmodig. Etterretning og forberedelse. |
| Leiehacker | Høy evne koblet til andres motivasjon. Farlig kombinasjon. |
| Personlig motivert aktør | Lav teknisk evne, men svært høy motivasjon rettet mot én bestemt person. Ofte den med alvorligst konsekvens i systemer med persondata. |
Dette siste steget er der flest poeng går tapt. Eksamensteksten sier eksplisitt at tekniske risikoer må vises å være utledet fra misbrukstilfellene og angrepstrærne, og at de må kobles til forretningsrisikoene — ellers trekkes det poeng selv om risikoene i seg selv er riktige. Skriv derfor alltid en tabell med kolonnene: teknisk risiko | teknologiantakelse | hvilket misbrukstilfelle/angrepstre den kommer fra | hvilken forretningsrisiko den påvirker. Ti tekniske risikoer i en slik tabell er langt mer verdt enn tjue i en usporet punktliste.
Fra hver teknisk risiko utledes så ett sikkerhetskrav, formulert som hva som skal oppnås, ikke hvordan. «Systemet skal bruke signerte tokens» er et løsningsvalg; «Et reisebevis skal bare godtas dersom det er utstedt av oss og ikke er utløpt» er et krav — det er etterprøvbart, og det låser ikke designet.
Nøkkelformler
Vanlige feil
Eksamenstips
Laster...