Cybersikkerhet for bedrifter: slik sikrer du nettstedet
NSM hevet cyberrisikoen til «høyt» 27. oktober 2026. Slik sikrer du nettstedet mot angrep, og slik oversetter du NSMs 21 tiltak til praksis.
- Publisert
- Lesetid
- 6 min
Kort fortalt
- NSM hevet det nasjonale cyberrisikonivået fra «moderat» til «høyt» 27. oktober 2026, det nest øverste trinnet, og ber norske virksomheter sette i verk tiltak nå.
- Nettstedet er det mest utsatte punktet. Oppdatert serverprogramvare er det viktigste du gjør, og på sårbarheter som php2shell hjelper ikke sikkerheten inne i selve nettsiden.
- NSMs 21 tiltak koker ned til fem ting: oppdater, tofaktor, backup du har testet, logging og en plan. Vit hvem som drifter nettstedet, og at ansvaret er ditt selv om andre gjør jobben.
Nasjonal sikkerhetsmyndighet (NSM) hevet 27. oktober 2026 det nasjonale cyberrisikonivået fra «moderat» til «høyt». Det er det nest øverste trinnet på skalaen, og første gang NSM offentliggjør nivået i stedet for å gradere det. Beskjeden til norske virksomheter er kort: sett i verk tiltak nå. For de fleste virksomheter starter cybersikkerheten med nettstedet. Det er det første en angriper ser, og det som oftest kjører programvare ingen har oppdatert.
Denne artikkelen forklarer hva varselet betyr, og hva du bør gjøre med nettstedet ditt denne uka.
Hva NSM varslet 27. oktober
NSMs skala har fem trinn: svært lavt, lavt, moderat, høyt og ekstremt høyt. «Moderat» regnes som normaltilstanden i det digitale rommet, der angrep mot norske virksomheter skjer hele tiden. Nå er nivået altså ett hakk over det normale.
NSM oppgir tre grunner. Antall vellykkede cyberoperasjoner mot norske virksomheter er tredoblet det siste året. Kunstig intelligens gjør det enklere og raskere å finne og utnytte sårbarheter. Angriperne har også et ferskt eksempel å øve på: den kritiske PHP-sårbarheten php2shell, som ble rettet uka før.
Direktøren i NSM sier virksomhetene nå har timer, ikke dager eller uker, på å tette kjente sikkerhetshull. Kravet er at tiltakene settes i verk umiddelbart.
NKOM fulgte opp samme dag, men bare for sin egen sektor. De regulerer ekomtilbyderne og datasenteroperatørene, og tar tiltakene inn i sikkerhetsdialogen med dem. For alle andre virksomheter er NSMs tiltak anbefalinger, ikke pålegg. Mobil- og bredbåndsnettene er ikke rammet. Et hevet risikonivå betyr at du bør være forberedt. Det er ikke et varsel om at noe allerede har skjedd.
Hvorfor nettstedet er mest utsatt
Nettstedet svarer på forespørsler fra hele internett, hele døgnet. Det gjør det til den enkleste veien inn. En angriper slipper å lure til seg et passord eller ta seg inn på det interne nettet først, siden nettstedet allerede står åpent mot alle. Automatiske skannere leter kontinuerlig etter servere som kjører programvare med kjente sikkerhetshull.
php2shell er et godt eksempel på hvorfor dette haster. På en server satt opp med Apache og mod_php kan angrepet kjøre kode før nettsiden i det hele tatt laster. Da hjelper det ikke hvor godt koden er skrevet eller hvor godt CMSet ditt faktisk er sikret.
Når vi overtar drift av norske nettsteder, ser vi en gjenganger gang på gang: PHP som ikke er oppdatert på flere år, utvidelser og bibliotek med kjente sårbarheter, og en server ingen har ansvaret for. Det kan være en VPS et tidligere byrå satte opp i 2019, et Docker-image som står fast på en gammel PHP-versjon, eller en kampanjeside på et underdomene alle har glemt. Det er her innbruddene starter.
NSMs 21 tiltak, oversatt til praksis
NSM lener seg på sine egne grunnprinsipper for IKT-sikkerhet og peker på 21 tiltak som gjelder alle virksomheter. De fleste handler om grunnleggende hygiene. Tabellen under samler dem i det de betyr for deg som har et nettsted.
| NSM-tiltak | Hva det betyr for nettstedet |
|---|---|
| Sentralstyrt sikkerhetsoppdatering (2.3.1), moderne programvare (2.1.2) | Hold PHP, CMS, utvidelser og bibliotek oppdatert, og få oppdateringene installert automatisk, ikke når noen husker det |
| Flerfaktorautentisering (2.6.7) | Slå på tofaktor på innlogging til CMS, hosting, SSH og domenekontoen |
| Minimer rettigheter (2.6.4, 2.6.5), bytt standardpassord (2.3.7) | Gi hver bruker bare det de trenger, og fjern administratorkontoer ingen bruker |
| Kartlegg enheter og programvare (1.2.3, 1.2.4) | Vit hvilke nettsteder du har, hvor de driftes og hva de kjører |
| Del opp nettverket (2.2.3), styr dataflyt (2.5.1) | Hold produksjon, testmiljø og database adskilt, og la databasen aldri være åpen mot internett |
| Sikkerhetskopiering (2.9.1) og testing av den (2.9.3) | Ta backup som ligger utenfor serveren, og test at du får gjenopprettet fra den |
| Overvåking (3.2.3, 3.2.4) | Samle logger, og få varsel når noe uvanlig skjer |
| Planverk for hendelseshåndtering (4.1.1) | Ha en plan for hva du gjør, og hvem du ringer, når noe først skjer |
| Ansvar ved tjenesteutsetting (2.1.9) | Ansvaret er fortsatt ditt selv om noen andre drifter. Få det inn i driftsavtalen |
Det siste punktet er det mange bommer på. Et webhotell eller en driftsleverandør gjør mye av jobben, men bare det du har avtalt at de skal gjøre. Spør hva avtalen dekker.
Slik sikrer du nettstedet
Rekkefølgen under er den vi selv følger. Punkt to er det som haster denne uka.
- Finn ut hvem som drifter nettstedet. Har du et webhotell, er det hostingleverandøren som oppdaterer serveren. Vet du ikke hvem som drifter nettstedet, viser vi i kunnskapsbasen hvordan du finner det ut.
- Oppdater serverprogramvaren nå. Sjekk at PHP har fått sikkerhetsoppdateringen mot php2shell, og at CMS, utvidelser og bibliotek er oppdatert. Slik sjekker du PHP-versjonen, og her er hele gjennomgangen av php2shell.
- Slå på tofaktor overalt. Start med det som gir en angriper mest: innlogging til CMS, hostingkontoen, SSH og kontoen som styrer domenet og DNS.
- Ta backup du har testet å gjenopprette. En backup du aldri har prøvd å hente tilbake, er en antakelse. Ved et løsepengeangrep er en testet kopi som ligger utenfor serveren forskjellen på å gjenopprette og å betale. Les mer om løsepengevirus.
- Fjern det du ikke bruker. Gamle temaer, utvidelser du har slått av, glemte underdomener og brukerkontoer som ikke er i bruk. Alt som kjører, kan angripes.
- Slå på logging og varsling. Du kan ikke rydde opp etter noe du ikke oppdaget. Samle logger utenfor serveren, så de ikke forsvinner ved neste deploy.
- Ha en plan for innbrudd. Hvem kobler nettstedet fra nettet, hvem varsler kundene, og hvor ligger backupen? Vet du ikke hvor du skal se, viser vi tegnene på at nettstedet er hacket.
Timer, ikke dager
Forventningen er rimelig, men bare hvis driften er satt opp for det på forhånd.
Da php2shell ble rettet 21. oktober, oppdaterte vi alle våre egne servere samme kveld, klokka 18.57. Det går fort fordi serverne driftes likt og fra ett sted, ikke fordi noen jobbet raskt den kvelden. En sikkerhetsoppdatering går gjennom en CI/CD-pipeline og er i produksjon i løpet av minutter. Ingen logger seg inn på hver enkelt server og laster opp filer med FTP.
Det som skiller en server som tettes samme kveld fra en som står åpen i ukevis, er at oppdatering, overvåking og backup var på plass før varselet kom. Vi drifter i EU/EØS med det oppsettet, og ser etter spor av innbrudd når noe først har skjedd. Du finner mer på siden om IT-sikkerhet.
Reglene strammes til
Dette gjelder utover denne uka. Kravene til sikkerhet øker uansett risikonivå. Digitalsikkerhetsloven, som gjennomfører EUs NIS2-direktiv i Norge, utvider hvilke virksomheter som må ha orden på nettopp det NSM nå ber om. Samtidig spør stadig flere kunder om sikkerhetsrutinene dine i anbud. Jo før dette er på plass, jo billigere blir det enn å ordne det under press senere.
Oppsummering
- NSM hevet det nasjonale cyberrisikonivået til «høyt» 27. oktober 2026, det nest øverste trinnet. Tiltak haster.
- Nettstedet er det mest utsatte punktet. Oppdatert serverprogramvare er det viktigste du gjør, og på sårbarheter som php2shell hjelper ikke sikkerheten inne i selve nettsiden.
- NSMs 21 tiltak koker ned til fem ting: oppdater, tofaktor, backup du har testet, logging og en plan.
- Vit hvem som drifter nettstedet. Ansvaret er fortsatt ditt, selv om noen andre gjør jobben.
