Kritiske fund skal afhjælpes: hvad forordningen siger, og hvad kunden spørger om

Når en test finder noget alvorligt i jeres leverance, vil en NIS2-kunde ikke kun vide, at fundet findes. Kunden vil vide, hvad I gør ved det, hvornår, og hvem der har besluttet det. Grundlaget er to punkter i bilaget til gennemførelsesforordning (EU) 2024/2690. Punkt 6.5.2, litra d, siger, at der anvendes afbødende foranstaltninger i tilfælde af alvorlige konstateringer. Punkt 6.10.2, litra c, siger, at sårbarheder, som enheden har konstateret som værende af kritisk betydning for sin drift, afhjælpes uden unødig forsinkelse.

Ingen af punkterne sætter en frist i dage. Det er kundens vurdering af, hvad der er kritisk, og jeres aftale, der afgør tempoet. Teksten er ikke juridisk rådgivning.

Hvad de to punkter siger, og hvem de gælder for

Forordningen gælder direkte for bestemte digitale udbydere, blandt andre cloud, datacentre og administrerede tjenester. Er I selv en af dem, gælder punkterne for jeres egne systemer. Er kunden en af dem, gælder de for kundens systemer, og kunden vil forvente, at I bidrager, når fundet ligger i jeres leverance.

Andre kunder kender ordene fra SAMSIK’s vejledning om foranstaltninger. Den anbefaler, at sårbarheder, der anses for kritiske, håndteres uden unødige forsinkelser, og at enheden dokumenterer begrundelsen, hvis en sårbarhed ikke kræver udbedring. Om testresultater skriver vejledningen, at restrisiko skal accepteres af risikoejere med passende rapportering til relevant ledelse. → Gennemførelsesforordning 2024/2690

“Uden unødig forsinkelse” er ikke en frist

Udtrykket betyder, at der ikke må gå længere tid end nødvendigt, men det siger ikke hvor lang tid. Hvad der er nødvendigt, afhænger af fundet, af hvor svært det er at rette, og af hvad der kan gøres i mellemtiden. Forordningens punkt 6.10.3 tilføjer, at enheden skal lave og gennemføre en plan for at afhjælpe sårbarheden, når den potentielle indvirkning berettiger det, og ellers dokumentere og begrunde, hvorfor den ikke kræver afhjælpning.

For jer betyder det, at kunden kan forvente en plan, ikke nødvendigvis en rettelse dagen efter. Planen bør være konkret nok til, at kunden kan følge op på den, og den bør opdateres, hvis forudsætningerne ændrer sig undervejs. Står der en konkret frist i jeres aftale, er det den, der gælder mellem jer. → Kundens frister for rettelser

Hvem afgør, hvad der er kritisk?

Punkt 6.10.2, litra c, taler om sårbarheder, som enheden har konstateret som værende af kritisk betydning for sin drift. Det er altså kundens drift, der er målestokken, når kunden er den omfattede enhed. Et fund, testeren vurderer som middel, kan være kritisk for en kunde, hvis netop den del af løsningen bærer kundens vigtigste proces.

ENISA’s vejledning til forordningen, som ikke er bindende, anbefaler at bruge en ramme som CVSS til at vurdere alvoren og som minimum at håndtere sårbarheder i de højeste klasser uden unødig forsinkelse. Den skriver også, at det så vidt muligt ikke er tilrådeligt at acceptere risikoen ved sådanne sårbarheder uden at håndtere dem. Kunden kan derfor have en lavere tærskel for accept end I. Spørg kunden, hvilken skala og hvilke grænser kunden bruger, og angiv både testerens vurdering og jeres egen i dokumentationen. Så kan kunden selv lægge sin driftsmæssige vurdering ovenpå uden at skulle gætte på, hvordan jeres tal er fremkommet. → CVSS i kundens krav

Det, kunden vil spørge om

Når et alvorligt fund berører kunden, kan I forvente spørgsmål som disse:

Hvad er fundet, og hvad kan det føre til? · på et niveau, kunden kan bruge i sin egen vurdering.
Hvad er gjort med det samme? · afbødende foranstaltninger, der mindsker risikoen, før den egentlige rettelse er på plads.
Hvornår er det rettet? · en plan med dato, og hvem der er ansvarlig.
Hvordan ved I, at rettelsen virker? · efterprøvning, fx ved en ny test af det konkrete fund.
Hvem har accepteret en eventuel restrisiko? · navn eller rolle, og på hvilket grundlag.

Om og hvornår kunden skal have besked om fundet, afhænger af aftalen. → Kritisk fund, der berører kunden

Afbødning først, rettelse bagefter

Forordningen bruger ordet afbødende foranstaltninger i punkt 6.5.2, litra d. Det er bredere end rettelse. En afbødende foranstaltning kan være at begrænse adgangen til en funktion, at slå en del fra, at øge overvågningen eller at ændre en procedure, indtil den egentlige rettelse er klar. For kunden kan det være det vigtigste svar i de første dage, fordi det viser, at risikoen er mindsket, selv om fejlen ikke er væk. Beskriv også, hvad den midlertidige løsning koster kunden i funktionalitet. → Midlertidige tiltag, når en rettelse tager tid

Et tænkt eksempel

En leverandør af et system til ordrestyring hos en producent af elektronik får ved en test et fund, der kan give en bruger hos én kunde adgang til en anden kundes ordrer. Testeren vurderer det som alvorligt. Leverandøren slår den berørte funktion fra samme dag og sender kunderne en kort besked med fundets art, den midlertidige foranstaltning og en plan for rettelsen. Rettelsen kommer i næste udgivelse, og testeren efterprøver den. Kunderne får en opdateret status med dato for efterprøvningen.

Leverandøren har hverken lovet en frist, der ikke kunne holdes, eller ladet kunderne vente på en færdig rettelse uden besked. Bagefter undersøger leverandøren, om samme type fejl kan findes i andre funktioner, og skriver resultatet i statussen.

Det skal I lade være med

At love en fast frist, loven ikke kræver · aftal en plan, I kan holde.
At bruge testerens vurdering som kundens · det er kundens drift, der afgør, hvad der er kritisk for kunden.
At acceptere en alvorlig risiko i stilhed · kunden skal kunne se, hvem der har accepteret den.
At vente med besked, til rettelsen er klar · aftalen kan kræve besked tidligere.
At melde et fund rettet uden efterprøvning · kunden vil spørge, hvordan I ved det.

Hvad kan og ikke kan konkluderes

Teksterne viser, at alvorlige fund skal mødes med afbødende foranstaltninger og en plan, og at en beslutning om ikke at rette skal begrundes. De viser ikke en bestemt frist, og de afgør ikke, hvilke fund der er kritiske for netop jeres kunde. En rettet og efterprøvet sårbarhed dokumenterer, at det konkrete fund er håndteret, ikke at løsningen er fri for lignende fejl. → Retest som dokumentation over for kunden