Kritisk fund, der berører kunden: hvornår og hvordan kunden skal have besked

Midt i en test ringer testeren og fortæller om en alvorlig svaghed i den del af leverancen, en NIS2-kunde bruger. Spørgsmålet er nu, om kunden skal have besked med det samme, efter rettelsen eller først med rapporten. Svaret hviler først og fremmest på jeres aftale med kunden. Reglerne skelner mellem hændelser og sårbarheder, og et testfund er som udgangspunkt en sårbarhed, ikke en hændelse. Men kunden kan have brug for at vide det tidligt, fordi kunden selv skal kunne handle.

Er der ingen frist i aftalen, er en tidlig og kort besked til den aftalte kontakt det sikreste udgangspunkt. Teksten er ikke juridisk rådgivning.

Sårbarhed eller hændelse

NIS 2-loven definerer i § 3, nr. 29, en sårbarhed som en svaghed, modtagelighed eller fejl, der kan udnyttes af en cybertrussel. En hændelse er efter § 3, nr. 12, en begivenhed, der bringer data eller tjenester i fare. Et fund i en test er en sårbarhed, som testeren har påvist. Det bliver ikke en hændelse, fordi testeren har kunnet udnytte den under testen.

Det ændrer sig, hvis testeren støder på tegn på, at andre allerede har udnyttet svagheden, eller at data er blevet tilgået af uvedkommende. Så kan der være tale om en hændelse, og kunden kan have pligter efter lovens §§ 12 og 13. Stop op, og vurder det sammen med testeren, før testen fortsætter. → Fund eller hændelse?

Hvad aftalen kan sige

Bilaget til forordning (EU) 2024/2690 gælder direkte for bestemte digitale udbydere og bruges som model af andre kunder. Punkt 5.1.4 nævner to aftalepunkter, der er relevante her:

Litra d · en pligt for leverandøren til uden unødig forsinkelse at underrette kunden om hændelser, der udgør en risiko for sikkerheden i kundens net- og informationssystemer.
Litra f · en pligt for leverandøren til at håndtere sårbarheder, der udgør en risiko for sikkerheden i kundens systemer.

Litra f taler om at håndtere sårbarheder, ikke om at give besked om dem. Om og hvornår kunden skal orienteres om et fund, afhænger derfor af, hvad jeres aftale konkret siger. Nogle aftaler kræver besked om alle alvorlige sårbarheder inden for en bestemt frist. Andre nævner kun hændelser. Læs aftalen, før I skal bruge den. → Pligt til at håndtere sårbarheder i aftalen

Når aftalen er tavs

Står der intet om sårbarheder, er det jeres egen vurdering. To forhold taler for at give kunden besked tidligt. Kunden kan have mulighed for selv at begrænse risikoen, fx ved at begrænse en adgang eller slå en funktion fra hos sig. Og kunden skal efter forordningens punkt 6.10.2, litra c, eller tilsvarende anbefalinger i SAMSIK’s vejledning om foranstaltninger, afsnit 5.b, håndtere sårbarheder, der er kritiske for kundens drift, uden unødig forsinkelse. Det kan kunden kun, hvis kunden kender dem.

Til gengæld er der grund til at vente med detaljer, til der er en plan. En besked uden plan skaber uro, og en besked med tekniske detaljer kan i sig selv være en risiko, hvis den når de forkerte. → Kritiske fund skal afhjælpes

Det, beskeden skal indeholde

En første besked til kunden kan være kort:

Hvad der er berørt · hvilken del af leverancen, og om kundens data eller adgange kan være i spil.
Alvor · hvor alvorligt testeren vurderer fundet, og om I ser det anderledes.
Hvad der er gjort · midlertidige tiltag, der allerede er sat i værk.
Hvad kunden selv kan gøre · hvis der er noget, fx at begrænse en adgang.
Hvornår kunden hører igen · en dato for næste opdatering.

Udelad den tekniske fremgangsmåde. Kunden har brug for betydningen og planen, ikke en beskrivelse af, hvordan svagheden kan udnyttes. → Midlertidige tiltag, når en rettelse tager tid

Til hvem, hvordan og aftalt på forhånd

Beskeden skal gå til den kontakt, kunden har udpeget, ikke til den, I plejer at tale med om fakturaer. Forordningens punkt 5.2 beder enheden føre et register over leverandører med kontaktpunkter, og ENISA’s ikke bindende vejledning til punkt 6.10.2 anbefaler et fast kontaktpunkt og faste kanaler til kommunikation med leverandører om sikkerhedsforhold. Er der ingen aftalt kontakt, så find den, før I har brug for den.

Brug en kanal, der passer til oplysningernes følsomhed, og bekræft, at beskeden er modtaget. Et telefonopkald efterfulgt af en kort skriftlig besked kan være bedre end en mail, der ligger ulæst. → Sikker aflevering af testresultater

Den letteste måde at undgå tvivl på er at aftale med testeren, før testen begynder, hvad der sker ved et kritisk fund: hvem testeren ringer til, om testen pauses, og hvordan fundet dokumenteres, før rapporten er klar. Aftal samtidig internt, hvem der beslutter, om kunden skal have besked, og hvem der sender den.

Rammer fundet flere kunder, skal I også beslutte rækkefølgen, så ingen kunde får besked via en anden. → Fund, der også rammer andre kunder

Et tænkt eksempel

En leverandør af et dokumenthåndteringssystem til en kommune får besked fra testeren på testens anden dag: en fejl i adgangskontrollen gør det muligt for en bruger hos én kunde at se dokumenter fra en anden. Testeren har ikke set tegn på, at fejlen er udnyttet.

Leverandøren slår den berørte funktion fra samme dag. Aftalen med kommunen kræver besked om alvorlige sårbarheder i den del, kommunen bruger. Leverandøren ringer til kommunens udpegede sikkerhedskontakt og sender bagefter en kort skriftlig besked med de fem punkter og en dato for næste opdatering. Kommunen vurderer, at der ikke er tale om en hændelse, og noterer fundet i sin leverandøropfølgning. Rettelsen efterprøves ugen efter, og kommunen får en opdatering med resultatet.

Det skal I lade være med

At vente på den endelige rapport, hvis aftalen kræver tidligere besked · rapporten kan tage uger.
At sende tekniske detaljer i første besked · de hjælper ikke kunden og kan skade.
At kalde fundet en hændelse uden grundlag · det kan sætte kundens underretningspligter i gang unødigt.
At overse tegn på, at svagheden er udnyttet · så er det ikke længere kun et fund.
At skrive til den forkerte kontakt · brug den, kunden har udpeget.

Hvad kan og ikke kan konkluderes

En tidlig og præcis besked giver kunden mulighed for at handle og viser, at I tager kundens afhængighed alvorligt. Den afgør ikke, om kunden har pligter over for myndighederne; det vurderer kunden selv. Hvornår besked er påkrævet, afgøres af jeres aftale, og reglerne giver ingen fast frist for besked om sårbarheder. → Kundens 24 timer