Hvorfor har offentlige it-systemer så mange sikkerhedshuller?

Annonce – sponsoreret indhold.

Sikkerhedshuller i offentlige systemer skyldes sjældent ét enkelt svigt. De opstår, fordi sikkerhed i udbud og udvikling behandles som noget, der kan kontrolleres til sidst, i stedet for noget, der skal bygges ind fra første krav. Pres på tid og budget, uklart ansvar mellem myndighed og leverandør og test, der kommer for sent, giver tilsammen systemer med svagheder, som kunne være fanget langt tidligere. Derfor ligner it-skandalerne hinanden: de er symptomer på manglende processer, ikke uheld.

Når sikkerhedshuller i offentlige systemer rammer borgerne, bliver det politik

Offentlige it-systemer adskiller sig fra private ved, at borgeren sjældent kan fravælge dem. Man kan skifte webshop, men ikke skatteforvaltning, sygehus eller kommunal sagsbehandling. Systemerne rummer desuden følsomme oplysninger om helbred, økonomi, familieforhold og sociale sager. Når de lækker, er konsekvenserne personlige og svære at gøre ugjort.

Det gør sagerne politiske. Ministre skal svare i Folketinget, kommunalbestyrelser skal forklare sig, og Datatilsynet kan vurdere, om den dataansvarlige har levet op til GDPR’s krav om passende tekniske og organisatoriske sikkerhedsforanstaltninger. Debatten ender dog ofte ved spørgsmålet om, hvem der har skylden: leverandøren, it-chefen eller direktionen. Det forklarer ikke, hvordan sårbarheden slap igennem, og derfor gentager mønstret sig.

Hvad mangler der typisk i udviklingen af offentlige it-løsninger?

Mange sårbarheder opdages først efter ibrugtagning, fordi der aldrig er foretaget en grundig code review af sikkerhed undervejs i udviklingen. Koden er blevet gennemgået for funktion og fejl, men ikke med øje for misbrug: Kan en bruger se andres sager ved at ændre et id i en adresse? Bliver input kontrolleret, før det rammer databasen? Ligger der adgangsnøgler i kodearkivet? Spørgsmålene er ikke avancerede, men de bliver kun stillet, hvis nogen har fået til opgave at stille dem.

Code review er dog kun ét led. Typiske mangler i offentlige udviklingsforløb er:

• Sikkerhedskrav, der er for vage. Kravspecifikationen siger “systemet skal være sikkert” eller henviser til en standard, uden at krav til adgangsstyring, logging og kryptering er konkrete og målbare.
• Ingen trusselsmodellering. Ingen har systematisk spurgt, hvem der kunne have interesse i at misbruge systemet, og hvordan. Typiske risici er misbrug af brugerrettigheder, utilstrækkelig adskillelse mellem kommuner eller kunder og sårbare integrationer til andre systemer.
• Sikkerhedstest til sidst. En penetrationstest lige før åbning finder fejl på et tidspunkt, hvor tidsplanen er presset og rettelser er dyre. Fund bliver let nedprioriteret eller skubbet til en senere version.
• Uklare kriterier for godkendelse. Ingen har på forhånd defineret, hvilke fund der blokerer en release, eller hvem der kan acceptere en undtagelse.
• Svag opfølgning i drift. Åbne biblioteker og tredjepartskomponenter forældes, og nye sårbarheder bliver ikke fulgt systematisk, når projektet er afsluttet og teamet opløst.

Hvorfor ender sikkerhed så ofte nederst på listen?

Offentlige it-projekter er ofte store, flerårige og bundet af udbudsregler. Kravene fastlægges tidligt, og leverandøren vælges på pris og funktionalitet, som er lette at sammenligne. Sikkerhed er sværere at måle og bliver let en skjult omkostning, som konkurrenten kan skære væk for at give et lavere tilbud. Hvis udbuddet ikke stiller klare krav, er der ingen økonomisk gevinst ved at gøre mere end minimum.

Dertil kommer en ansvarsglidning. Myndigheden er dataansvarlig og bærer det juridiske ansvar, men leverandøren skriver koden. Hvis ingen har kompetence til at stille de rigtige spørgsmål i udbudsfasen, bliver sikkerheden reelt overladt til leverandørens egne prioriteter.

Hvorfor løser en struktureret Secure SDLC problemet?

Secure SDLC (sikker softwareudviklingslivscyklus) betyder, at sikkerhedsaktiviteter er faste dele af hver fase i udviklingen i stedet for et eftersyn til sidst. Antallet og navnene på faserne varierer, men processen bør som minimum dække disse områder:

1. Planlægning og sikkerhedskrav: klassifikation af information, vurdering af systemets kritikalitet, identifikation af lov- og kontraktkrav samt konkrete krav til logging, adgangsstyring, kryptering og backup.
2. Risiko- og trusselsmodellering: en analyse af, hvordan løsningen kan kompromitteres, og hvad konsekvenserne er.
3. Sikkert design og arkitektur: risici omsættes til valg af adgangsmodeller, dataflow, netværksopdeling og sikker fejlhåndtering, og designet gennemgås, før det bliver fast.
4. Sikker udvikling: retningslinjer for sikker kodning, peer review og code review, scanning af kode og af eksponerede secrets samt kontrol med open source-komponenter.
5. Test og sikkerhedskontrol: blandt andet SAST, DAST, Software Composition Analysis, test af brugerrettigheder og API’er samt penetrationstest.
6. Release og deployment: klare kriterier for, hvilke fund der skal være håndteret, og hvem der godkender undtagelser.
7. Drift, vedligeholdelse og sårbarhedshåndtering: løbende overvågning og håndtering af nye sårbarheder i egen kode og i tredjepartskomponenter.

Fordelen er, at fejl findes, mens de er billige at rette. En svaghed i arkitekturen er langt dyrere at ændre efter lancering end på tegnebrættet. Processen gør desuden sikkerhed til en dokumenteret del af projektet, så en myndighed kan se, hvad der er gjort, og hvilke risici der er accepteret. Det styrker også den dokumentation, myndigheden skal kunne fremlægge over for Datatilsynet.

Hvad bør offentlige indkøbere og beslutningstagere kræve af leverandører?

Krav til sikkerhed skal stå i udbudsmaterialet og kontrakten, ikke kun i leverandørens salgsbrochure. Konkret bør indkøbere overveje at kræve:

• Dokumenteret udviklingsproces. Leverandøren skal kunne beskrive, hvordan sikkerhed indgår i hver fase, og hvem der er ansvarlig.
• Trusselsmodel og risikovurdering for den konkrete løsning, opdateret ved væsentlige ændringer.
• Sikkerhedsreview af kode og automatiseret scanning som fast del af leverancen, med dokumentation for fund og udbedring.
• Uafhængig test. Penetrationstest foretaget af andre end dem, der har bygget løsningen, og med aftalt frist for udbedring af kritiske fund.
• Styr på komponenter. En oversigt over anvendte open source-biblioteker og tredjepartskomponenter samt en plan for opdatering.
• Frigivelseskriterier. Klare regler for, hvilke fund der blokerer ibrugtagning, og at undtagelser skal risikovurderes og godkendes af myndigheden.
• Driftsansvar. Aftaler om sårbarhedshåndtering, logning og hændelsesregistrering efter aflevering, herunder samarbejde ved sikkerhedsbrud, så anmeldelse til Datatilsynet kan ske inden for GDPR’s frist på 72 timer.
• Ret til audit. Mulighed for at få verificeret, at processerne faktisk følges.

Myndigheden bør også selv have kompetence til at vurdere svarene. Her kan Center for Cybersikkerhed, Digitaliseringsstyrelsen og internationalt anerkendte rammer som ISO 27001 og OWASP’s vejledninger være et fælles referencepunkt. For organisationer omfattet af NIS2-reglerne er krav til leverandørkæden desuden en del af det, de selv skal kunne stå til ansvar for. Konkrete krav bør tilpasses systemets kritikalitet og afklares med juridisk og teknisk rådgivning.

Hvad betyder det for den politiske debat?

Så længe debatten stopper ved skyldsspørgsmålet, får den kun begrænset effekt. Mere nyttigt er det at spørge, om der var stillet krav til sikkerhed, før en løsning blev bestilt, om nogen har gennemgået koden og designet med øje for misbrug, og om der var klare kriterier for, hvornår systemet var klar til at gå i luften. Svarene viser, om sagen var et uheld eller et symptom. Hvis kravene ikke var der, er næste skandale kun et tidsspørgsmål, uanset hvem der sidder på ministerposten.