Ved indberetning af hændelser i softwareudvikling er der tale om to forskellige forhold, som ofte blandes sammen: en sårbarhed eller fejl i den software, som du udvikler og leverer, og en hændelse i dine egne udviklingsfaciliteter – det miljø, hvor du producerer denne software. Det, du dokumenterer, hvem der skal være informeret, og hvilket opfølgende skridt der er relevant, afhænger af hændelsestypen. Hvis man ikke foretager denne skelnen, overses ofte den hændelse, der betyder mest: en kontaminering i build-pipelinen, som spreder sig via koden til alle kunder, der implementerer den.
En sårbarhed i leveret kode påvirker kunden direkte: denne køre softwaren, og påtager sig derfor risikoen. En hændelse i udviklingsfaciliteterne – en stjålen adgangsnøgle, en kompromitteret build-konto, et datalæk i kodelageret – påvirker først og fremmest dig selv, men kan påvirke enhver kunde, der arbejder med denne kode. For begge tilfælde gælder det, at et spørgeskema om sikkerhed eller en revisor ikke spørger, om noget nogensinde er gået galt, men derimod om du kan dokumentere, hvad du har registreret herom, og hvad du har lært.
Hvad du dokumenterer ved en hændelse i koden
Ved en sårbarhed eller fejl i leveret software dokumenteres: hvornår det blev opdaget, af hvem eller hvad (intern test, kundemelding, scan, ekstern forsker), hvilken del af softwaren det vedrører, hvad den mulige konsekvens er, hvilken handling der blev iværksat og på hvilken dato, og hvem i din organisation der ejer opfølgningen. En ordentlig dokumentation viser også, om en rettelse er blevet udrullet til alle kunder, der anvender den pågældende version, eller kun til den, der rapporterede problemet. Sidstnævnte er netop det, som en kunde spørger om i et spørgeskema: ikke om du nogensinde havde en sårbarhed, men om din proces garanterer, at alle, der påvirkes af den, også bliver underrettet.
Hvad du dokumenterer ved en hændelse i udviklingsfaciliteterne
En hændelse i dine egne udviklingsfaciliteter – en kompromitteret konto med adgang til kodelageret, en build-server, som opfører sig uventet, en afhængighed, som senere viser sig at være ondsindet – kræver en lidt anderledes dokumentation. Her handler det om: hvilket system eller hvilken konto det drejer sig om, hvem der havde adgang i den periode, hvor det fandt sted, om der er tegn på, at kode er blevet ændret eller læst, og hvilke kunder der eventuelt anvender software, som blev bygget eller leveret i denne periode. Dette er den type hændelse, hvor adgangskontrol i udviklingsfaciliteterne spiller direkte ind: uden et aktuelt oversigt over, hvem der må have adgang til hvad, bliver dette undersøgelsesspørgsmål betydeligt vanskeligere at besvare ved en hændelse.
Hvem du informerer, og hvem du ikke gør
Hvorvidt du selv falder under pligten til håndtering af cybersikkerhed efter den nationale lov, bestemmer, hvem du skal informere om en hændelse. Enheder, der selv klassificeres som væsentlige eller vigtige, har en indberetningspligt over for deres tilsynsmyndighed; hvad der præcist skal indberettes, og inden for hvilken tidsramme, er beskrevet i direktivet og den nationale lov, og varierer alt efter situation. En softwarevirksomhed, som påvirkes gennem leverandørkæden – altså ikke selv er omfattet af pligten, men leverer til en kunde, som er – har ikke denne indberetningspligt over for tilsynsmyndigheden, men har typisk en kontraktlig aftale om at informere kunden. Det gør egen dokumentation ikke mindre vigtig: en kunde, der spørger, om du nogensinde har haft en hændelse, ønsker et konkret svar, ikke et estimat i efterhand.
En løbende journal, ikke et arkiv
Incidentregistrering fungerer bedst som levende dokument: en liste, hvor status, bevis og ansvarlig person for hvert incident kan findes, i stedet for en løs rapport, der forsvinder i en mappe efter afslutning. Det stemmer overens med, hvordan den bredere sikkerhedspligt er opbygget, med ti foranstaltninger, der hver især kræver en status og en ansvarlig person. Den, der gerne vil se, hvordan incidentregistrering forholder sig til de øvrige ni foranstaltninger, finder det overblik tilbage på siden med alle emner pr. situation.
Om din organisation selv er omfattet af sikkerhedspligten, påvirkes via leverandørkæden, eller ingen af delene, kan ses med et par spørgsmål via NIS2-checken, som giver en indikation med et par spørgsmål. Den, der præcis vil vide, hvor informationen på secria.eu kommer fra, og hvordan den vedligeholdes, læser det på siden om hvordan det fungerer. Og den, der efter læsningen vil vide, hvad et abonnement tilføjer til det, der er gratis her, finder det overskueligt tilbage hos oversigten over hvad der er inkluderet.
Denne tekst er en generel forklaring og ikke juridisk rådgivning om din egen situation. For at få en vurdering af din specifikke incidentproces eller meldepligt kan du henvende dig til en jurist eller til den tilsynsmyndighed, der er kompetent for din sektor.