Sikkkerhetstesting i IT-prosjekter: Fem grep for testledere

Testlederen har en viktig rolle i arbeidet med sikkerhet. Med innsikt i både krav, arkitektur og test kan testlederen bidra til å avdekke risiko før systemet settes i produksjon. Her er fem konkrete grep som kan gjøre sikkerhet til en integrert del av testarbeidet, ikke noe som kommer på toppen til slutt.

Dette er del 3 av 4 i artikkelserien om testlederens rolle i å sikre offentlige IT-systemer mot DDoS- og tjenestenektangrep. Del 1 og 2 har vist hvorfor spørsmålet om sikkerhetsrisikoanalyse er mer akutt enn mange tror, og hvilket ansvar regelverket legger på ledelsen. I denne delen går vi gjennom fem konkrete grep testledere kan ta i samarbeid med sikkerhetsressursene.

Testlederen som bindeledd mellom prosjekt og sikkerhet

Testlederen sitter i en viktig posisjon: nær nok kravene og arkitekturen til å forstå hva som faktisk skal testes, og nær nok prosjektledelsen til å påvirke hva som blir prioritert.

Det gjør testlederen til et naturlig bindeledd mellom prosjektstyring og sikkerhetsfaget – dersom rollen brukes aktivt.

Så hva kan testlederen konkret gjøre?

1. Still et mer presist spørsmål enn «er det gjort en risikoanalyse?»

I stedet for å stille et spørsmål som inviterer til et enkelt ja eller nei, bør testleder be om å se risikoanalysen og stille konkrete oppfølgingsspørsmål.

Dekker analysen tilgjengelighet like grundig som konfidensialitet? Er tjenestenekt- og DDoS-scenarier vurdert som en egen trusselkategori for dette systemet, med sannsynlighet og konsekvens beskrevet? Er analysen knyttet til det spesifikke systemet og dets grensesnitt mot internett, eller er den basert på en generisk mal?

Dersom svarene er vage, kan det være et tegn på at det som foreligger først og fremst er en funksjonell risikoanalyse – ikke en tilstrekkelig vurdering av sikkerhetsrisiko.

2. Bruk NSMs grunnprinsipper som et felles språk

NSMs grunnprinsipper for IKT-sikkerhet er strukturert i fire faser: identifisere og kartlegge, beskytte og opprettholde, oppdage, samt håndtere og gjenopprette.

Dette rammeverket er nyttig for en testleder fordi det gir konkrete sjekkpunkter å legge testplanen opp mot, uavhengig av om man selv er sikkerhetsekspert.

Har man kartlagt systemets kritiske komponenter og avhengigheter, inkludert avhengigheter til felles offentlig infrastruktur? Er beskyttelsestiltak som hastighetsbegrensning og redundans faktisk implementert og testet – ikke bare beskrevet i arkitekturdokumentasjonen?

Kan man oppdage et pågående angrep i praksis, eller oppdages det først når brukerne begynner å melde om problemer? Og finnes det et gjenopprettingsforløp som faktisk er øvd på, ikke bare skrevet ned?

3. Bygg robusthetstesting inn teststrategien fra start

Testing av motstandskraft mot tjenestenekt bør ikke komme som et tillegg rett før produksjonssetting. Det bør bygges inn i teststrategien fra start.

OWASPs anbefalinger for DoS-beskyttelse er et godt praktisk utgangspunkt for hva som bør testes: Håndterer systemet useriøse forespørsler tidlig og effektivt? Degraderer funksjonaliteten gradvis i stedet for at hele tjenesten stopper? Finnes det enkeltpunkter som kan slå ut hele tjenesten? Er det satt fornuftige tidsavbrudd og begrensninger på økter og filopplastinger? Og fungerer hastighetsbegrensning og trafikkfiltrering på nettverksnivå som forventet?

Dette kan omsettes til konkrete testtilfeller gjennom blant annet lasttesting, stresstesting mot spesifikke endepunkter, forsøk på å utløse ressurskrevende operasjoner og verifisering av at hastighetsbegrensning faktisk fungerer som spesifisert.

4. Definer tydelige krav til tilgjengelighet

En risikoanalyse uten tilhørende akseptansekriterier blir lett et dokument uten praktiske konsekvenser.

Testleder bør, i samarbeid med sikkerhetsansvarlig, sørge for at det finnes eksplisitte mål for hvor mye belastning systemet skal tåle, hvor lenge en nedetid maksimalt kan vare, og hva som er akseptabel degradert drift under et angrep.

Disse kriteriene bør inngå i test- og godkjenningskriteriene på linje med funksjonelle krav. Dette er vurderinger som bør være gjort før systemet settes i produksjon – ikke noe driftsorganisasjonen først skal måtte finne ut av når en hendelse allerede har oppstått.

5. Test beredskapen, ikke bare teknologien

Til slutt bør testleder bidra til at det gjennomføres en øvelse, for eksempel en table-top-øvelse eller en enkel simulert hendelse.

Målet er å teste om organisasjonen faktisk oppdager og responderer på et tjenestenektangrep innenfor nødvendig tid. En slik øvelse kan avdekke om varslingslinjer, roller og ansvar fungerer i praksis – eller bare på papiret.

For virksomheter som er omfattet av krav om rapportering av alvorlige hendelser, blir dette også viktig for å teste om organisasjonen er i stand til å håndtere de regulatoriske forpliktelsene når en reell hendelse oppstår.

Hva ville disse grepene betydd i praksis?

Ingen av de fem grepene kunne ha forhindret sommerens DDoS-angrep mot infrastrukturen ID-porten var avhengig av. Angrepet lå utenfor det den enkelte virksomheten eller testlederen selv kunne kontrollere.

Men grepene kunne gjort virksomhetene bedre forberedt på konsekvensene:

• Grep 1 og 2 – risikoanalyse og avhengigheter: Spørsmålet «hva skjer med vår tjeneste hvis ID-porten faller ut?» kunne synliggjort avhengigheten av ekstern infrastruktur – og konsekvensene av et bortfall – før hendelsen oppstod.
• Grep 3 – robusthetstesting: Testing kunne vist hva som faktisk skjer med egen tjeneste når innloggingsleverandøren blir utilgjengelig. Stopper tjenesten helt, eller kan den fortsette med redusert funksjonalitet?
• Grep 4 – krav til tilgjengelighet: Tydelige akseptansekriterier kunne definert hvor lenge innlogging kan være utilgjengelig, og hvilken degradert drift som kan aksepteres i mellomtiden.
• Grep 5 – beredskap: En øvelse kunne testet varslingslinjer, brukerkommunikasjon, roller og ansvar før organisasjonen måtte håndtere situasjonen i en reell hendelse.

Poenget er ikke at disse grepene gjør virksomheten immun mot angrep på infrastruktur den ikke selv kontrollerer. De gjør virksomheten bedre forberedt på at det kan skje.

Det kan være forskjellen på en kontrollert driftshendelse og en ukoordinert krise.