Nettverksinventar for underleverandører: NIS2-kravene kommer via kundens leverandørskjema

Det meste som skrives om NIS2, retter seg mot virksomheter som omfattes av direktivet. Denne teksten gjelder de som faller utenfor loven: det lille verkstedet, produsenten med tolv ansatte, underleverandøren. De får kravene likevel, gjennom kundene sine.

Status i norsk rett per august 2026

Digitalsikkerhetsloven ble vedtatt 12. desember 2023 og trådte i kraft 1. oktober 2025. Den gjennomfører det første NIS-direktivet og er en rammelov. Det materielle innholdet ligger i forskrift.

NIS2 er ikke gjennomført i norsk rett. Direktivet er ikke tatt inn i EØS-avtalen, og det finnes ingen bekreftet dato. Lovarbeidet pågår. EU-fristen for medlemsstatene var 17. oktober 2024, så Norge har ligget bak siden da.

Terskelverdiene følger EUs SMB-definisjon. Mellomstor virksomhet er 50 til 249 ansatte og 10 til 50 millioner euro i omsetning, eller 10 til 43 millioner euro i balanse. Stor virksomhet er 250 ansatte eller mer. Under det faller du som hovedregel utenfor, uansett sektor. Unntakene er få: enerådende leverandører av en kritisk tjeneste, DNS-tjenester, toppdomeneregistre, tillitstjenester og offentlige ekomnett.

Et verksted på Jæren med tjue ansatte omfattes ikke, selv om mye av markedsføringen rundt NIS2 antyder det.

Kravene kommer gjennom kundens leverandørvurdering

NIS2 stiller krav til sikkerhet i leverandørkjeden. En virksomhet som omfattes, må vurdere og dokumentere risikoen ved leverandørene sine. Vurderingen er pålagt, og virksomheten kan ikke svare på leverandørens vegne.

I praksis lander spørreskjemaet hos underleverandøren. Det har skjedd i årevis med personvern og kvalitetsstyring: den store aktøren skyver dokumentasjonskravet nedover i kjeden. Det er slik regelverket treffer små bedrifter i Norge.

Spørsmålene i et slikt skjema er nesten alltid de samme fire:

1. Hvilke enheter finnes i nettverket deres?
2. Hvem eier dem, og hvilke er kritiske for produksjonen?
3. Hvordan oppdager dere at noe ukjent kobler seg til?
4. Hvor lang tid tar det før dere ser at noe kritisk har forsvunnet?

Ingen av dem kan besvares fra hukommelsen eller med et policy-dokument. De krever et inventar som oppdaterer seg selv.

Et inventar i regneark holder i omtrent tre måneder

Årsakene er tekniske. IP-adressen identifiserer ikke enheten. DHCP gjenbruker adresser, så en enhet som ble kastet i fjor, står fortsatt oppført, mens den nye maskinen som fikk adressen, ser ut som den gamle. Vertsnavn er nesten like ustabilt. MAC-adressen er eneste brukbare nøkkel, og selv den svikter når klienter randomiserer, eller når maskinen sitter i en dokkingstasjon som eier MAC-en. Jeg har skrevet mer om nøkkelproblemet og produsentoppslaget tidligere.

Mitt eget nett har 36 enheter. Et middels stort verksted jeg skanner regelmessig, har 57. Det er for mange til å holde oversikt over manuelt og for få til å forsvare et enterprise-produkt.

Skanningen skriver bare observerte felter

Dette er den viktigste designbeslutningen i modulen, og den avgjør om noen fortsatt bruker systemet etter måned to. Hver enhet har to sett felter, og skanningen har ingen kodevei inn i det andre settet.

const OBSERVED_FIELDS = [
'ip', 'mac', 'hostname', 'vendor', 'open_ports',
'mdns_services', 'dhcp_fingerprint', 'last_seen_at',
'uplink_switch', 'uplink_port',
];

const CURATED_FIELDS = [
'name', 'owner', 'location', 'is_critical',
'type_locked', 'notes',
];
Ingest skriver bare det første settet. Navn, eier, plassering, kritisk-flagg og notater settes av et menneske, og en skanning kan ikke endre dem. Regelen har en egen test, fordi den er lett å bryte ved et uhell og umulig å oppdage etterpå.

Samme regel gjelder berikelse fra andre kilder. Har kunden en managed kontroller, kan den gi svitsj og portnummer per enhet, altså et faktisk kabelkart. Den kilden får likevel bare berike enheter som allerede finnes. To kilder som begge kan opprette enheter, gir duplikater fra dag én.

Første skann er grunnlinje

Første kartlegging hos en kunde er grunnlinje og gir null varsler. Før den regelen fikk jeg 34 varsler første dag da modulen ble satt i drift hjemme. Alle var «ny ukjent enhet», og alle var feil, fordi systemet ikke hadde noe å sammenligne med. Hos verkstedet står det nå 7 åpne varsler, og alle 7 er ekte enheter som kom til etter kartleggingen.

Samme feil dukket opp i dødmannsknappen. En nyregistrert skannekilde uten rapporter ble regnet som «stille» og varslet umiddelbart. Fristen måles nå fra tidspunktet kilden ble opprettet.

Terskler for fraværsvarsling

Det er ved fraværsvarsling slike systemer vanligvis mister tilliten. Fire regler har holdt:

• Skill tilstedeværelse observert av maskinen fra status satt av et menneske. Slås de sammen, kan du ikke skille «printeren er avslått i helgen» fra «printeren er fjernet». Det er den vanligste modelleringsfeilen.
• Savnet krever tre sammenhengende tapte skann. Med 15-minutters intervall gir det rundt 45 minutter, borte etter et døgn, savnet etter en uke og arkivert etter en til to måneder. Enheter slettes aldri automatisk.
• Andre enheter på samme lokasjon må ha blitt sett i de samme skannene. Uten denne betingelsen varsler hele nettet hver gang skanneren mister strømmen.
• Bare enheter merket kritiske varsler ved fravær. Mobiler, bærbare og alt med randomisert MAC varsler aldri. Bedre er å lære oppetidsandelen per enhet over 30 dager og bare varsle når historisk tilgjengelighet ligger over 95 prosent. Da klassifiserer systemet en laptop som sporadisk uten at noen må merke den.

Til sammenligning bruker Home Assistant 180 sekunder som standard for consider_home, og praktisk anbefaling der ligger på 10 til 15 minutter. NetAlertX bruker 30 minutters sovetid. Tersklene må avhenge av enhetsklassen.

Skanning uten å installere noe

Hos kunder er det sjelden mulig å installere en agent, og på en del bokser kan man ikke engang legge igjen en fil. Det som virker, er at boksen som allerede står der, henter skanneren ved behov, kjører den og sender resultatet ut. Et parallelt ping-sveip av et /24 med etterfølgende lesing av nabotabellen tok 4,7 sekunder og fant 41 verter, godt innenfor en timeout på 120 sekunder.

# sveip, så les det kjernen allerede har lært
for i in $(seq 1 254); do ping -c1 -W1 192.168.2.$i &>/dev/null & done; wait
ip neigh show | grep -v FAILED
Kjører boksen BusyBox, støtter ikke ip flagget -j, og en skanner som forutsetter JSON-utdata, feiler helt. Tekstparsing må ligge der som fallback. Et vanlig discovery-skann henter heller ingen porter, så klassifiseringen må klare seg med produsent, vertsnavn og mDNS.

Adresseplan for et /24

Et inventar blir mye lettere å lese når adressene er delt i blokker. Dette er planen jeg bruker på et /24 i produksjonsmiljø:

Adressene settes som DHCP-reservasjoner, ikke som statisk adresse på enheten. Alt ligger samlet i kontrolleren, adressen kan endres uten å røre maskinen, og gateway og DNS distribueres automatisk. Det siste sparer mye arbeid på skjæreplottere og fresemaskiner med tungvinte menyer.

Ulempen er at en maskin som starter mens DHCP-serveren er nede, ikke får adresse. I praksis betyr det lite, siden den da uansett ikke har noen å snakke med. Unntaket er maskiner som bare snakker med en PC på samme switch og aldri trenger gateway. Der er ekte statisk adresse tryggere.

Å renummerere et eksisterende nett gir mer risiko enn gevinst. IP-adresser er hardkodet i RIP-programvare, i skjæreoppsett, i skannemapper mot NAS og i jobbfiler. Planen bør gjelde alt nytt utstyr, og eksisterende maskiner flyttes bare når de likevel er nede. Rekkefølgen med lavest risiko først er nettverksutstyr, printere, NAS og til slutt produksjonsmaskiner.

Hva som bør gjøres nå

Kartlegg nettet én gang og bruk resultatet som grunnlinje, merk det som er kritisk, og la resten oppdatere seg selv. Det tar en ettermiddag. Policy-dokumentet kan skrives når noen spør etter det.