De sikkerhedskrav du skal stille, også uden egen sikkerhedsekspert
Selv uden egen sikkerhedsekspert kan du stille fornuftige sikkerhedskrav til din udviklingsleverandør. Tag udgangspunkt i nogle få kravområder: adgangskontrol, kryptering, håndtering af tredjepartsafhængigheder og logning. Spørg til leverandørens egne rutiner og tidligere hændelser, og skriv ind at kravene skal følges op løbende under projektet og ikke bare stå i kontrakten og blive glemt.
Sikkerhed føles ofte som noget kun specialister kan udtale sig om, og derfor overlader mange kunder spørgsmålet helt til leverandøren. Det er en fejl. Du behøver ikke din egen sikkerhedsekspert for at stille de rigtige grundkrav. Du skal vide hvilke områder der betyder noget, og turde spørge hvordan de håndteres. En leverandør der tager sikkerhed alvorligt, kan forklare sine rutiner så du forstår dem. Kan de ikke det, har du allerede lært noget vigtigt.
De kravområder du bør dække
De fleste sikkerhedsproblemer i udviklingsprojekter handler ikke om avancerede angreb, men om grundlæggende mangler. Fire områder dækker det meste af risikoen, og du kan stille krav til dem uden dyb teknisk viden.
| Område | Hvad du skal kræve |
|---|---|
| Adgangskontrol | Kun de rigtige personer får adgang til de rigtige data, med individuelle konti og de rigtige rettigheder |
| Kryptering | Følsomme data beskyttes både når de lagres og når de overføres |
| Håndtering af afhængigheder | Tredjepartskomponenter holdes opdateret så kendte sårbarheder bliver lukket |
| Logning | Man kan bagefter se hvem der har gjort hvad og hvad der er sket ved en hændelse |
Hvert af dem svarer til en almindelig, reel risiko. Ved svag adgangskontrol lækker data via glemte eller alt for brede rettigheder. Uden kryptering ligger følsomme oplysninger ubeskyttet hvis noget kommer på afveje. Forældede afhængigheder er en af de allermest almindelige veje ind fordi kendte huller ikke er lukket. Og uden logning famler du i blinde hvis noget går galt: Du ved ikke engang hvad der skete.
Spørgsmålene om leverandørens egne rutiner
Et sikkert system bygges af et team med sikre rutiner. Derfor handler en del af kravene om leverandøren selv, ikke kun om koden. Stil spørgsmålene direkte:
- Hvordan håndterer I adgang internt? Hvem hos leverandøren har adgang til jeres kode og data, og hvordan begrænses det?
- Hvordan holder I afhængigheder opdateret? Findes der en rutine for at opdage og udbedre kendte sårbarheder i de komponenter I bruger?
- Gennemgår I jeres egen kode for sikkerhedsfejl? Sker det systematisk eller kun når nogen tilfældigvis kommer i tanke om det?
- Hvordan handler I ved en hændelse? Findes der en plan, og hvem kontakter hvem?
Spørg også om de har haft hændelser tidligere og hvad de lærte af dem. En leverandør der svarer åbent og konkret på det, er et tryggere valg end en der hævder aldrig at have haft et eneste problem, for det har alle der har været i branchen længe nok.
Et scenarie: kravet der reddede en lancering
En virksomhed skulle lancere en tjeneste der behandlede personoplysninger. Selv uden egen sikkerhedsekspert stillede den et enkelt krav: Leverandøren skulle redegøre for alle tredjepartskomponenter og deres kendte sårbarheder før lanceringen. Gennemgangen afslørede en central komponent med et kendt, alvorligt hul som aldrig var blevet lukket. Den blev skiftet ud ugen før start.
Kravet var ikke teknisk avanceret. Det var bare et spørgsmål der fremtvang en kontrol. Uden det var tjenesten gået i luften med en åben dør som ingen havde kigget efter.
Følg op på kravene i stedet for bare at skrive dem
Den mest almindelige måde at fejle med sikkerhed på er at skrive flotte krav ind i kontrakten og så aldrig kontrollere dem. Krav der ikke følges op, er virkningsløse uanset hvor velformulerede de er.
Byg derfor opfølgningen ind i selve arbejdet. Sørg for at sikkerhed indgår i leverancekriterierne så en funktion ikke regnes for færdig før den er sikker. Gennemgå kravene ved milepæle i stedet for kun til sidst. Og bed om at kendte sårbarheder i afhængigheder udbedres løbende og ikke gemmes til en fremtidig hovedrengøring. Det er opfølgningen der gør forskellen på sikkerhed på papiret og sikkerhed i praksis.
En sidste ting afgør om opfølgningen faktisk finder sted: at nogen hos jer ejer den. Udpeg en person der har ansvaret for at kravene bliver fulgt op, også selvom den person ikke selv er tekniker. Opgaven er ikke at gennemgå koden, men at sørge for at spørgsmålet bliver stillet ved hver milepæl og at svarene bliver dokumenteret. Et krav uden en ejer har det med at blive glemt netop når der er mest brug for det, og så er I tilbage ved sikkerhed på papiret.
Vil du have hjælp til at fastsætte rimelige sikkerhedskrav til netop jeres projekt uden at skulle have jeres egen ekspert, gør vi i Weapp det gerne. Kontakt os med en beskrivelse af hvad tjenesten skal håndtere.
Ofte stillede spørgsmål
Kan vi stille sikkerhedskrav uden vores egen sikkerhedsekspert?
Ja. Du behøver ikke en CISO for at stille de rigtige grundkrav. Du skal vide hvilke områder der er vigtige, og turde spørge hvordan leverandøren håndterer dem. En seriøs leverandør kan forklare sine rutiner på en forståelig måde. Kan de ikke det, er svaret i sig selv et advarselstegn. Grundkravene i denne guide rækker langt for de fleste projekter.
Hvilke sikkerhedsområder er vigtigst at stille krav til?
Fire dækker det meste: adgangskontrol så kun de rigtige personer får adgang til de rigtige data, kryptering af følsomme oplysninger både ved lagring og overførsel, styr på tredjepartsafhængigheder så kendte sårbarheder bliver lukket, og logning så man kan se hvad der er sket ved en hændelse. Dækker du dem, har du håndteret de mest almindelige risici.
Hvilke spørgsmål skal vi stille om leverandørens egne rutiner?
Hvordan de håndterer adgang internt, hvordan de holder deres afhængigheder opdateret, om de gennemgår deres egen kode for sikkerhedsfejl og hvordan de handler ved en hændelse. Spørg også om de har haft hændelser tidligere og hvad de lærte af dem. En leverandør der svarer åbent og konkret, er et tryggere valg end en der siger at de aldrig har haft problemer.
Er det nok at skrive sikkerhedskravene ind i kontrakten?
Nej, det er dér de fleste fejler. Krav der kun står på papiret, men aldrig kontrolleres, er virkningsløse. Byg løbende opfølgning ind: Bed om at sikkerhed indgår i leverancekriterierne, gennemgå kravene ved milepæle, og kræv at kendte sårbarheder i afhængigheder udbedres løbende. Det er opfølgningen der gør kravene virkelige.