NIS2 når dig gennem dine kunder, ikke gennem direktivet

Du læste anvendelsesområdet, konkluderede at din virksomhed er for lille og branchen er forkert, og gik videre. Den slutning er som regel rigtig og næsten aldrig enden på sagen — for de organisationer, der er omfattet, skal styre sikkerheden hos deres leverandører, og du er en af dem.

Det er den del af NIS2, der overrasker softwarevirksomheder. Ikke et tilsyn, ikke en bøde. Et indkøbsspørgeskema hæftet på en fornyelse, fra en kunde, der nu skal kunne gøre rede for dig.

Det følgende er en praktisk beskrivelse af, hvad der plejer at lande, og hvad der er værd at have klar. Det er ikke juridisk rådgivning, og om din egen virksomhed falder direkte ind under reglerne, er reelt et spørgsmål til en advokat — branchedefinitionerne og tærsklerne har rigtige grænsetilfælde.

Hvad NIS2 er, kort

NIS2 er et EU-direktiv, der hæver minimumsniveauet for cybersikkerhed på tværs af de brancher, der vurderes kritiske for samfundet, og som afløser et tidligere og langt smallere direktiv. Fordi det er et direktiv og ikke en forordning, får det virkning gennem hvert medlemslands egen gennemførelseslov, så detaljerne og tidsplanen er forskellige fra land til land.

To træk betyder mere end resten for en leverandør:

Det har tænder på ledelsesniveau. NIS2 placerer ansvaret hos virksomhedens ledelse udtrykkeligt, herunder godkendelsen af risikoforanstaltningerne. Hvor tidligere regler kunne delegeres nedad, indtil de fordampede, er det her bevidst sværere at overse — og det er grunden til, at de spørgeskemaer, du modtager, bliver taget alvorligt af dem, der sender dem.

Forsyningskædesikkerhed er en udtrykkelig forpligtelse. En omfattet organisation skal inddrage sikkerheden hos sine direkte leverandører og tjenesteudbydere i sin egen risikostyring. Den sætning er hele grunden til, at denne artikel findes.

Hvorfor "vi er ikke omfattet" ikke afslutter sagen

Anvendelsesområdet handler om enheden, ikke om kravene. Sælger du software til en hospitalskoncern, et energiselskab, en transport- eller postvirksomhed, en bank, et vandværk, en statslig myndighed eller en driftsleverandør, er i det mindste nogle af dine kunder omfattet. De skal styre leverandørrisiko. Det kan de ikke uden at spørge dig om ting.

Så forpligtelsen når dig som et forretningsmæssigt krav og ikke som et juridisk — hvilket i praksis er sværere at argumentere imod, ikke lettere. Med en myndighed kan du forhandle. En indkøbsproces, der har markeret din kontrakt som ikke-efterlevende, fornyer den bare ikke.

Mønsteret, du kan forvente: den første forespørgsel kommer fra din største kunde, bliver besvaret i hast, og lander så fra tre mere inden for et år, hver i sit lidt anderledes format.

Ét forbehold, for det rammer netop den læser, artiklen er skrevet til. Sælger du en hostet tjeneste og ikke software, kunden selv installerer, så læs de digitale brancher igennem, før du konkluderer, at du er udenfor: cloud computing-tjenester, datacentre, driftsleverandører og udbydere af administrerede sikkerhedstjenester er alle nævnte kategorier. En SaaS-virksomhed over tærsklen for mellemstore virksomheder kan være omfattet i egen ret og ikke kun gennem en kunde. For de fleste små leverandører er det størrelsestærsklen og ikke branchelisten, der holder dem ude — og størrelsestærskler er den slags, der flytter sig, mens man kigger den anden vej.

Hvad der faktisk står i spørgeskemaet

Det er konsekvent de her, der er svære — forstået sådan, at de fleste virksomheder ikke kan besvare dem ud fra eksisterende dokumentation:

• "Fremsend en stykliste over den software, du leverer." Hver tredjepartskomponent, med version og licens. Kan du ikke generere den, sidder du og skriver et regneark i hånden, som er forkert, inden du sender det. Hvad en SBOM er, og hvordan du laver den gennemgår det ordentligt.
• "Beskriv din proces for håndtering af sårbarheder." Ikke om du scanner. Hvordan du finder ud af det, hvor hurtigt, hvordan du beslutter, hvad der rettes først, og hvordan du fortæller kunderne det. En navngiven proces slår et imponerende værktøj her.
• "Hvor hurtigt lapper du en kritisk sårbarhed?" De vil have et tal og et grundlag for det. "Hurtigst muligt" læses som slet ingen proces.
• "Har du en kontakt til indberetning af sårbarheder i dit produkt?" En offentliggjort sikkerhedskontakt og et udmeldt svarløfte. Det er billigt at sætte op og iøjnefaldende, når det mangler.
• "Hvordan og hvornår giver du os besked ved en hændelse?" NIS2 sætter korte indberetningsfrister for de omfattede enheder: en tidlig varsling inden for 24 timer efter, at man er blevet opmærksom på en væsentlig hændelse, en fyldigere underretning inden for 72 timer og en endelig rapport inden for en måned. Din kunde kan ikke overholde sin, hvis du er en uge om at sige det, så deres tidsplan bliver et vilkår i din kontrakt.
• "Hvilke af dine egne leverandører kan nå vores data?" Kæden fortsætter forbi dig.

Hvad du bør have klar

I omtrentlig rækkefølge efter, hvad der giver mest troværdighed pr. arbejdsindsats:

En genereret softwarefortegnelse. Ikke vedligeholdt i hånden — genereret ud fra den samme opløsning, der producerer dit faktiske afhængighedstræ, i SPDX eller CycloneDX, med dato. Det ene dokument besvarer det sværeste spørgsmål i de fleste spørgeskemaer, og at besvare det godt virker uforholdsmæssigt overbevisende, netop fordi så få leverandører kan.

En skreven proces for sårbarhedshåndtering, på én side. Hvordan du får kendskab til sårbarheder, hvor ofte du tjekker, hvordan du prioriterer, hvad dit mål for svartid er, og hvordan du informerer kunder. Én side, der beskriver, hvad du faktisk gør, slår ti, der beskriver, hvad du stræber efter — og den, der læser den, kan mærke forskellen.

Dokumentation for, at den kører. Et procesdokument, ingen kan demonstrere, er en påstand. Daterede scanningsresultater, en fundhistorik, hvor fund bliver rejst og lukket, og en registrering af beslutninger — også de risici, du har accepteret, med begrundelse — laver en påstand om til noget, der kan efterprøves.

En sikkerhedskontakt og en indberetningspolitik. En mailadresse, der når frem til nogen, en udmeldt svartid og en security.txt på dit site. En eftermiddags arbejde.

Et løfte om hændelsesvarsling, du reelt kan holde. Før du skriver under på et. Deres ur starter, når de får det at vide; dit skal starte tidligere.

Et VEX-udsagn, hvis du leverer software, kunderne scanner. Det er det avancerede punkt, og det løser en bestemt tilbagevendende irritation: din kunde kører din SBOM gennem en scanner, får fyrre hits og skriver til dig om dem alle sammen. Et VEX-dokument er standardmåden at sige, hvilke af dem der reelt rammer dit produkt, og hvorfor resten ikke gør.

Hvad man ikke skal gøre

Svar ikke ud fra ambitioner. Et svar i et spørgeskema er en kontraktlig erklæring. "Vi overvåger løbende alle afhængigheder" er en dårlig sætning at have skrevet, hvis en hændelse senere viser, at du ikke gjorde. Den ærlige udgave — hvad du gør, hvor ofte, hvad du ikke dækker — er både sikrere og, når de rent faktisk bliver læst, mere overbevisende.

Køb ikke en certificering for at få det til at holde op. ISO 27001 er værdifuld og hjælper reelt i de her samtaler, men det er et stort program, og det besvarer ikke i sig selv forsyningskædespørgsmålene ovenfor. Mange virksomheder starter dér, fordi det er let at forstå, og står et år senere stadig uden at kunne fremskaffe en stykliste.

Behandl ikke det første spørgeskema som en engangsopgave. Det er det første af mange, og de kommer til at være forskellige i format, mens de spørger om de samme seks ting. Byg svarene som noget, du kan generere igen — ikke som et dokument, du skrev én gang til én kunde.

Gælder NIS2 for min virksomhed, hvis jeg bare er leverandør?

Som regel gælder NIS2 ikke direkte for en leverandør: anvendelsesområdet afhænger af branche, størrelse og den rolle, organisationen spiller. Men de organisationer, der er omfattet, skal styre sikkerheden hos deres direkte leverandører som en del af deres egen risikostyring, så kravene når dig kontraktligt gennem dine kunder og ikke gennem direktivet. I praksis er det sværere at argumentere imod end en myndighedsforpligtelse, for en indkøbsproces, der markerer din kontrakt som ikke-efterlevende, fornyer den bare ikke.

Hvad kræver NIS2 om forsyningskædesikkerhed?

NIS2 gør sikkerheden hos direkte leverandører og tjenesteudbydere til en udtrykkelig del af en omfattet organisations egen risikostyring i stedet for noget valgfrit. Derfor begynder leverandører, der ikke selv er omfattet, at modtage sikkerhedsspørgeskemaer: deres kunde kan ikke dokumentere efterlevelse uden at kunne gøre rede for den software og de tjenester, de køber. NIS2 placerer også ansvaret udtrykkeligt hos virksomhedens ledelse, og det er derfor, forespørgslerne bliver forfulgt alvorligt.

Hvad spørger NIS2-leverandørspørgeskemaer egentlig om?

NIS2-leverandørspørgeskemaer spørger konsekvent om seks ting, som de fleste virksomheder ikke kan besvare ud fra eksisterende dokumentation: en stykliste over den software, du leverer, en beskrivelse af din proces for håndtering af sårbarheder, dit mål for, hvor hurtigt en kritisk sårbarhed bliver lappet, en offentliggjort kontakt til indberetning af sårbarheder i dit produkt, hvordan og hvor hurtigt du ville varsle dem ved en hændelse, og hvilke af dine egne leverandører, der kan nå deres data. Styklisten er den, der typisk ikke kan fremskaffes med kort varsel.

Hvordan forbereder jeg mig på et NIS2-leverandørspørgeskema?

Generér en softwarestykliste i stedet for at vedligeholde en i hånden, eftersom den besvarer det sværeste spørgsmål, og få leverandører kan fremskaffe den. Skriv din proces for sårbarhedshåndtering ned på én side, og beskriv, hvad du faktisk gør, i stedet for hvad du stræber efter. Gem dokumentation for, at processen kører, herunder beslutninger om at acceptere en risiko og begrundelserne. Offentliggør en sikkerhedskontakt med en udmeldt svartid. Og aftal et løfte om hændelsesvarsling, I reelt kan holde, før I skriver under på et.

Hvor TrustCtrl passer ind

CodeControl producerer de dokumenter, spørgeskemaerne beder om, som et biprodukt af selve arbejdet. Softwarestyklisten genereres ud fra en rigtig scanning, i både SPDX og CycloneDX, med dato — og et VEX-dokument ud fra de vurderinger, dit team allerede har lavet. Fundhistorikken er dokumentationen for, at processen kører, inklusive de risici, du har accepteret, og hvorfor. VulnControl dækker det samme spørgsmål for den software, din tjeneste kører på, i stedet for den software, du leverer.

Intet af det gør nogen efterlevende i sig selv — efterlevelse er et spørgsmål om din organisation, ikke om dine værktøjer. Det, det ændrer, er, om det tager en eftermiddag eller fjorten dage at svare.