Sikkerhetskravene du må stille, også uten egen sikkerhetsekspert
Selv uten egen sikkerhetsekspert kan du stille fornuftige sikkerhetskrav til utviklingsleverandøren din. Ta utgangspunkt i noen kravområder: tilgangskontroll, kryptering, håndtering av tredjepartsavhengigheter og logging. Spør om leverandørens egne rutiner og hendelseshistorikk, og skriv inn at kravene skal følges opp løpende i prosjektet, ikke bare stå i avtalen og bli glemt.
Sikkerhet føles ofte som noe bare spesialister kan uttale seg om, og derfor overlater mange kunder spørsmålet helt til leverandøren. Det er en feil. Du trenger ingen egen sikkerhetsekspert for å stille de riktige grunnkravene. Du må vite hvilke områder som betyr noe, og tørre å spørre hvordan de håndteres. En leverandør som tar sikkerhet på alvor, kan forklare rutinene sine slik at du forstår dem. Kan de ikke det, har du allerede lært noe viktig.
Kravområdene du bør dekke
De fleste sikkerhetsproblemer i utviklingsprosjekter handler ikke om avanserte angrep, men om grunnleggende svakheter. Fire områder dekker det meste av risikoen, og du kan kreve dem uten dyp teknisk kunnskap.
| Område | Hva du skal kreve |
|---|---|
| Tilgangskontroll | Bare de riktige personene får tilgang til de riktige dataene, med individuelle kontoer og riktige rettigheter |
| Kryptering | Sensitive data beskyttes både når de lagres og når de overføres |
| Håndtering av avhengigheter | Tredjepartskomponenter holdes oppdatert slik at kjente sårbarheter tettes |
| Logging | Det er mulig å se i etterkant hvem som har gjort hva, og hva som har skjedd ved en hendelse |
Hver av disse svarer til en vanlig, reell risiko. Det er gjennom svak tilgangskontroll at data lekker ut, via glemte eller altfor brede tilganger. Uten kryptering ligger sensitiv informasjon ubeskyttet hvis noe kommer på avveie. Utdaterte avhengigheter er en av de aller vanligste veiene inn fordi kjente hull ikke er tettet. Og uten logging er du blind hvis noe går galt: Du vet ikke engang hva som skjedde.
Spørsmålene om leverandørens egne rutiner
Et sikkert system bygges av et team med sikre rutiner. Derfor handler en del av kravene om leverandøren selv, ikke bare om koden. Still spørsmålene rett ut:
- Hvordan håndterer dere tilgang internt? Hvem hos leverandøren har tilgang til koden og dataene dine, og hvordan begrenses det?
- Hvordan holder dere avhengighetene oppdatert? Finnes det en rutine for å oppdage og utbedre kjente sårbarheter i komponentene dere bruker?
- Sjekker dere egen kode for sikkerhetshull? Skjer det systematisk eller bare når noen tilfeldigvis kommer på det?
- Hva gjør dere ved en hendelse? Finnes det en plan, og hvem kontakter hvem?
Spør også om de har hatt hendelser tidligere, og hva de lærte av dem. En leverandør som svarer åpent og konkret på det, er tryggere enn en som hevder at de aldri har hatt et eneste problem. Alle som har holdt på lenge nok, har nemlig hatt det.
Et scenario: kravet som reddet en lansering
En virksomhet skulle lansere en tjeneste som behandlet personopplysninger. Den hadde ingen egen sikkerhetsekspert, men stilte et enkelt krav: Leverandøren skulle gjøre rede for alle tredjepartskomponenter og de kjente sårbarhetene i dem før lansering. Gjennomgangen avslørte en sentral komponent med et kjent, alvorlig hull som aldri var blitt tettet. Den ble byttet ut uken før lanseringen.
Kravet var ikke teknisk avansert. Det var bare et spørsmål som tvang frem en kontroll. Uten det ville tjenesten ha blitt lansert med en åpen dør som ingen hadde sett etter.
Følg opp kravene, ikke bare skriv dem
Den vanligste måten å mislykkes med sikkerhet på er å skrive fine krav inn i avtalen og så aldri kontrollere dem. Krav som ikke følges opp, er virkningsløse, uansett hvor godt formulert de er.
Bygg derfor oppfølgingen inn i selve arbeidet. Sørg for at sikkerhet er med i leveransekriteriene slik at en funksjon ikke regnes som ferdig før den er sikker. Gå gjennom kravene ved milepæler i stedet for bare ved slutten. Og be om at kjente sårbarheter i avhengigheter utbedres fortløpende, ikke spares til en fremtidig storrengjøring. Det er oppfølgingen som skiller sikkerhet på papiret fra sikkerhet i praksis.
En siste ting avgjør om oppfølgingen faktisk skjer: at noen hos dere eier den. Pek ut en person som har ansvaret for at kravene følges opp, selv om den personen ikke selv er tekniker. Oppgaven er ikke å gå gjennom koden, men å sørge for at spørsmålet stilles ved hver milepæl, og at svarene dokumenteres. Et krav uten en eier har en tendens til å bli glemt akkurat når det trengs som mest, og da er dere tilbake til sikkerhet på papiret.
Vil dere ha hjelp til å sette fornuftige sikkerhetskrav for akkurat prosjektet deres, uten å trenge en egen ekspert, gjør vi i Weapp det gjerne. Ta kontakt med en beskrivelse av hva tjenesten skal håndtere.
Ofte stilte spørsmål
Kan vi stille sikkerhetskrav uten en egen sikkerhetsekspert?
Ja. Du trenger ingen CISO for å stille de riktige grunnkravene. Du må vite hvilke områder som er viktige, og tørre å spørre hvordan leverandøren håndterer dem. En seriøs leverandør kan forklare rutinene sine på en forståelig måte. Kan de ikke det, er svaret i seg selv et varselsignal. Med grunnkravene i denne guiden kommer du langt i de fleste prosjekter.
Hvilke sikkerhetsområder er viktigst å stille krav til?
Fire områder dekker det meste: tilgangskontroll slik at bare de riktige personene får tilgang til de riktige dataene; kryptering av sensitiv informasjon både ved lagring og overføring; kontroll på tredjepartsavhengigheter slik at kjente sårbarheter tettes; og logging slik at det er mulig å se hva som har skjedd ved en hendelse. Dekker du disse, har du håndtert de vanligste risikoene.
Hva bør vi spørre om leverandørens egne rutiner?
Hvordan de håndterer tilgang internt, hvordan de holder avhengighetene sine oppdatert, om de sjekker sin egen kode for sikkerhetshull, og hva de gjør ved en hendelse. Spør også om de har hatt hendelser tidligere, og hva de lærte av dem. En leverandør som svarer åpent og konkret, er tryggere enn en som sier at de aldri har hatt problemer.
Holder det å skrive sikkerhetskravene inn i avtalen?
Nei, og det er nettopp der de fleste mislykkes. Krav som bare står på papiret, men aldri kontrolleres, er virkningsløse. Bygg inn løpende oppfølging: Be om at sikkerhet er med i leveransekriteriene, gå gjennom kravene ved milepæler, og krev at kjente sårbarheter i avhengigheter utbedres fortløpende. Det er oppfølgingen som gjør kravene reelle.