Koordineret offentliggørelse af sårbarheder: hvad NIS2 siger, og hvad det betyder for jer

En sikkerhedsforsker skriver til jer om en fejl i jeres produkt, eller kundens egen test finder noget, der også rammer andre kunder. Spørgsmålet er så, hvem der skal have besked, hvornår, og hvem der bestemmer, hvornår fejlen bliver kendt offentligt. Svaret hviler på NIS2-direktivets artikel 12, som indfører koordineret offentliggørelse af sårbarheder med en national CSIRT som formidler, på NIS 2-lovens § 18 om anonym rapportering og på forordning 2024/2690, som for bestemte digitale udbydere kræver en procedure for offentliggørelse i overensstemmelse med den nationale politik.

For en leverandør, der ikke selv er omfattet, er reglerne ikke en direkte pligt. Men kunderne kan have en, og derfor kan de spørge, hvordan I tager imod og håndterer meldinger om sårbarheder i det, I leverer. Teksten er ikke juridisk rådgivning.

Hvad direktivet og loven siger

Artikel 12, stk. 1, pålægger hver medlemsstat at udpege en CSIRT som koordinator. Koordinatoren fungerer som betroet formidler mellem den, der melder en sårbarhed, og producenten eller udbyderen af det berørte produkt eller den berørte tjeneste, når en af parterne beder om det. Opgaverne omfatter at finde og kontakte de berørte, hjælpe den, der melder, og forhandle tidsfrister for offentliggørelse, når en sårbarhed berører flere enheder. Den, der melder, skal kunne gøre det anonymt, hvis vedkommende ønsker det.

Artikel 12, stk. 2, lader ENISA oprette en europæisk sårbarhedsdatabase, hvor enheder og deres leverandører frivilligt kan registrere offentligt kendte sårbarheder.

I den danske lov siger § 18, at CSIRT’en sikrer, at fysiske og juridiske personer i anonymiseret form kan rapportere om sårbarheder. Samme sted kan ministeren fastsætte nærmere regler. SAMSIK oplyser, at Forsvarets Efterretningstjeneste varetager opgaven som national CSIRT. For en leverandør er det nyttigt at vide, at en forsker, der ikke kan få kontakt med jer, kan gå den vej, og at I derfor kan blive kontaktet om en fejl af en myndighed frem for af den, der fandt den. → NIS 2-loven i Danmark

Hvad kunden selv skal kunne

For de digitale udbydere, forordning 2024/2690 gælder for, siger bilagets punkt 6.10.2, litra e, at de skal fastlægge en procedure for offentliggørelse af sårbarheder i overensstemmelse med den gældende nationale politik for koordineret offentliggørelse. Litra c kræver, at sårbarheder af kritisk betydning for driften afhjælpes uden unødig forsinkelse.

SAMSIK’s vejledning om foranstaltninger, afsnit 5.b, siger, at en enhed kan have en politik for koordineret offentliggørelse, der dækker egne net- og informationssystemer, og at sårbarheder, der endnu ikke er offentligt kendte, bør videregives til den udpegede CSIRT, hvor det er relevant. Det er formuleret som anbefalinger, ikke som en pligt for alle. Kunder uden for forordningen kan derfor have meget forskellige forventninger, fra en enkel aftale om besked til en detaljeret politik.

Hvorfor det angår jer som leverandør

Kundens arbejde med sårbarheder afhænger af jer, når fejlen sidder i noget, I leverer. Forordningens punkt 5.1.4, litra f, nævner en forpligtelse for leverandører til at håndtere sårbarheder, der udgør en risiko for kundens systemer, som et muligt kontraktpunkt. ENISA’s ikke-bindende vejledning til punkt 6.10 anbefaler, at kunden har et fast kontaktpunkt og kanaler til at kommunikere med leverandører om sikkerhed.

Derfor kan I møde spørgsmål som:

Hvordan melder man en sårbarhed til jer? · kunden vil vide, at der er en indgang.
Hvem hos jer håndterer meldingen? · en navngiven funktion frem for en generel postkasse.
Hvornår får kunden besked? · især når fejlen kan ramme kundens drift.
Hvordan koordinerer I med andre berørte kunder? · hvis fejlen sidder i en fælles platform.

→ Pligt til at håndtere sårbarheder i leverandøraftalen

Testfund og offentliggørelse

En penetrationstest af jeres løsning kan finde fejl, som ikke kun angår den kunde, der bestilte testen. Det kan være en fejl i en fælles platform eller i en komponent fra en tredjepart. Så opstår et spørgsmål om, hvem der må fortælle hvem hvad. Den kunde, der har betalt for testen, kan eje rapporten, men fejlen sidder i jeres produkt, og andre kunder kan være lige så udsatte. Uden en aftale kan I ende i en situation, hvor I kender til en fejl hos andre kunder, men ikke ved, om I må sige det.

Aftalen om testen bør derfor sige, hvordan fund behandles fortroligt, hvem der giver besked til andre berørte, og hvad der sker, hvis fejlen sidder i en komponent, I ikke selv har lavet. ENISA skriver i sin vejledning til punkt 6.5, at fund i open source-komponenter skal deles med det pågældende projekt. Når fejlen sidder i en kommerciel komponent, er det producenten, der skal have besked, og her kan den nationale CSIRT formidle, hvis det er nødvendigt. → Fund, der også rammer andre kunder

En synlig indgang for meldinger

Nogle organisationer har en offentlig side eller en fast adresse, hvor sårbarheder kan meldes. Standarden RFC 9116 beskriver et filformat, security.txt, som gør det lettere for forskere at finde kontaktoplysninger og en politik for offentliggørelse. Det er ikke et krav i NIS2, men et eksempel på, hvordan en indgang kan gøres synlig. Det vigtige er, at meldinger når frem til en, der kan handle på dem, og at kunden ved, hvordan processen ser ud. → Sårbarheder, som andre melder til jer

Det skal I lade være med

At love kunden, at fejl aldrig bliver offentligt kendt · tidspunktet kan blive koordineret af andre.
At ignorere meldinger fra forskere uden for kundeforholdet · de kan dreje sig om det, kunden bruger.
At dele testfund med andre kunder uden aftale · fortrolighed og besked skal være aftalt.
At gå ud fra, at CSIRT’en overtager jeres ansvar · den formidler, men retter ikke fejlen.
At skrive en politik, ingen hos jer kender · den skal kunne bruges, når meldingen kommer.

Hvad kan og ikke kan konkluderes

Reglerne viser, at der findes en national ramme for koordineret offentliggørelse, og at kunder under forordning 2024/2690 skal have en procedure for det. De viser også, at kunder kan aftale med leverandører, at sårbarheder håndteres. De pålægger ikke en leverandør, der ikke selv er omfattet, at have en bestemt politik. En test hos jer kan finde fejl, men den afgør ikke, hvordan og hvornår de bliver kendt. Det afhænger af aftaler og af den nationale koordinering.