WordPress Sikkerhetsrevisjon i Oslo

#Nettstedet ingen har sett på siden lanseringen

De fleste norske WordPress-nettsteder blir ikke kompromittert av avanserte angripere. De blir kompromittert av tid. Et nettsted lanseres, byrået leverer, fakturaen betales, og så går det tre år der ingen har ansvar for annet enn at siden svarer. Utvidelser blir stående på versjonen de hadde ved lansering. En integrasjon mot regnskapssystemet får admin-rettigheter fordi det var raskest. Utvikleren som bygde løsningen bytter jobb, men kontoen hans lever videre. Ingenting av dette er dramatisk hver for seg. Sammen er det nøyaktig den flaten automatiserte angrep leter etter, og automatiserte angrep bryr seg ikke om at virksomheten din er liten eller at nettstedet bare er et visittkort.

En sikkerhetsrevisjon er den systematiske måten å ta igjen de tapte årene på. Ikke en skanner som spytter ut to hundre linjer med rødt, men en manuell gjennomgang av installasjon, utvidelser, kontoer, server-oppsett og leverandørkjede, der hvert funn er verifisert, vurdert mot din faktiske drift og prioritert etter reell risiko. For virksomheter i Oslo og resten av Norge legger vi to norske referanserammer i bunn: NSMs grunnprinsipper for IKT-sikkerhet på styringssiden og Datatilsynets praksis på personvernsiden. Det gjør rapporten brukbar ikke bare for utvikleren som skal rette, men for ledelsen som skal svare når styret, revisor eller en kunde spør hvordan sikkerheten egentlig står til.

#NSMs grunnprinsipper som målestokk

Norske virksomheter trenger ikke lete utenlands etter et rammeverk. Nasjonal sikkerhetsmyndighet har publisert grunnprinsipper for IKT-sikkerhet som er blitt den naturlige referansen i norske anskaffelser, styredokumenter og tilsyn. Prinsippene er ordnet i fire kategorier: identifisere og kartlegge, beskytte og opprettholde, oppdage, og håndtere og gjenopprette. Det fine med dem er at de er skrevet for virkeligheten, ikke for revisjonsbransjen: de spør om du vet hva du har, om det er beskyttet, om du merker når noe går galt, og om du kommer deg på beina etterpå.

En WordPress-revisjon lar seg overraskende presist mappe mot disse kategoriene. Identifisere og kartlegge: fullstendig inventar over utvidelser, temaer, integrasjoner, kontoer og hvem som faktisk har tilgang, inkludert FTP-kontoer og databasebrukere ingen husker. Beskytte og opprettholde: oppdateringsrutiner, tilgangsstyring, tofaktor, herding av innloggingsflaten og server-konfigurasjon. Oppdage: finnes det logger som ville vist et innbrudd, og ser noen på dem. Håndtere og gjenopprette: finnes det sikkerhetskopier som er testet, og vet noen hvem som gjør hva den dagen det smeller. På applikasjonslaget supplerer vi med OWASP-metodikk, som er standarden for webapplikasjonstesting, men rapportens struktur følger grunnprinsippene, fordi det er det språket norske beslutningstakere allerede snakker.

Den ærlige observasjonen fra revisjoner vi har gjort: de fleste norske WordPress-miljøer scorer brukbart på beskyttelse og elendig på oppdage. Det finnes en brannmur og et sikkerhetsprogramtillegg, men ingen vet om noen har logget inn fra en uvanlig adresse i natt, for ingen logger er samlet noe sted og ingen har fått i oppgave å se.

#Personvern: 72 timer er kort tid når du ikke vet hva som skjedde

Et kompromittert WordPress-nettsted er sjelden bare et teknisk problem. Har nettstedet et kontaktskjema, et nyhetsbrev, en kundeportal eller en nettbutikk, behandler det personopplysninger, og da er et innbrudd et avvik etter GDPR. Avvik som medfører risiko for de registrerte skal meldes Datatilsynet innen 72 timer etter at virksomheten ble klar over det. Fristen er ikke problemet. Problemet er innholdet i meldingen: hvilke opplysninger var berørt, hvor mange personer, hva var årsaken, hva er gjort for å begrense skaden. En virksomhet uten logger og uten oversikt over egen installasjon kan ikke svare på noe av dette, og må i praksis melde “vi vet ikke” fire ganger på rad.

Derfor har revisjonene våre et eget personvernspor. For hvert funn vurderer vi ikke bare teknisk alvorlighet, men også personvernkonsekvensen: berører dette opplysninger om identifiserbare personer, og ville en utnyttelse utløst meldeplikt. En åpen xmlrpc-fil og en SQL-injeksjon i et skjema kan score likt i en skanner, men de er vidt forskjellige saker overfor Datatilsynet. Rapporten sier hvilke funn som er personvernkritiske, slik at behandlingsansvarlig kan prioritere deretter og dokumentere vurderingen i behandlingsprotokollen. Den dokumentasjonen er gull verdt den dagen noe faktisk skjer, for da viser den at virksomheten kjente sin egen risiko og handlet på den.

#NIS2 og digitalsikkerhetsloven: kravene flytter nedover

Sikkerhetsregulering var lenge noe som gjaldt banker og kraftverk. Det er i endring. Digitalsikkerhetsloven gjennomfører EUs NIS-regelverk i norsk rett og pålegger virksomheter som leverer samfunnsviktige og digitale tjenester krav til risikostyring, sikkerhetstiltak og varsling av hendelser. Med NIS2-direktivet utvides kretsen i EU betydelig, og norske myndigheter har varslet at regelverket skal videreutvikles i samme retning. For en mellomstor norsk virksomhet er den praktiske konsekvensen ikke at WordPress-nettstedet plutselig blir kritisk infrastruktur, men at kundene og partnerne deres begynner å stille krav nedover i kjeden.

Det er allerede synlig i norske anbud og leverandøravtaler: spørreskjemaer om sikkerhetsrutiner, krav om dokumentert risikovurdering, spørsmål om hendelseshåndtering. Den som svarer “vi har et sikkerhetsprogramtillegg” taper mot den som kan legge ved en revisjonsrapport med funnliste og lukkedatoer. En revisjon er med andre ord ikke bare risikoreduksjon, den er salgsdokumentasjon i et marked der digital sikkerhet er i ferd med å bli et tildelingskriterium.

#Hva vi faktisk finner i norske installasjoner

Etter mange revisjoner av norske WordPress-miljøer er funnbildet gjenkjennelig. Utdaterte utvidelser på delt webhotell topper listen: installasjonen deler server med hundrevis av andre nettsteder, og en sårbar utvidelse ett sted blir et springbrett videre. Nummer to er kontoer som aldri skulle eksistert: admin-tilganger til byråfolk som sluttet for to år siden, en “test”-konto med passord fra lanseringen, en FTP-bruker opprettet for en enkeltjobb i 2019. Nummer tre er manglende tofaktorautentisering på nettopp de kontoene som betyr noe, gjerne kombinert med at innloggingssiden ligger åpen på standardadressen og tar imot ubegrensede forsøk.

Så kommer de tekniske klassikerne: xmlrpc.php åpen mot internett, som lar angripere teste tusenvis av passordkombinasjoner i en eneste forespørsel via multicall, REST-API-endepunkter som lister ut brukernavn, databaseprefiks og filrettigheter fra standardoppsettet, og sikkerhetskopier som enten ikke finnes, ligger på samme server som nettstedet eller aldri er testet gjenopprettet. Ingenting av dette krever en avansert angriper å utnytte. Alt sammen er ting en automatisert kampanje finner på minutter.

Det viktige er ikke listen i seg selv, men prioriteringen. En skanner gir alle disse funnene samme røde farge. En revisjon skiller mellom sårbarheten som er reelt utnyttbar i din konfigurasjon og den som er teoretisk, mellom funnet som berører kundedata og det som i verste fall gir en angriper tilgang til en tom testside.

#Byrå-arv: leverandørkjeden som ingen kartla

Det mest oversette risikoområdet i norske WordPress-miljøer er ikke teknisk, det er organisatorisk. Et typisk nettsted har vært gjennom to eller tre leverandører: byrået som bygde det, frilanseren som overtok vedlikeholdet, og det nye byrået som “bare skulle fikse designet”. Hver overgang etterlater tilganger, og nesten ingen rydder. Vi kaller det byrå-arv: summen av kontoer, API-nøkler, lisenser registrert på andres e-post og udokumenterte spesialtilpasninger som tidligere leverandører har etterlatt seg.

Revisjonen kartlegger denne kjeden eksplisitt. Hvem har admin-tilgang i WordPress, hvem har tilgang til webhotellets kontrollpanel, hvem eier domenet og DNS, hvor peker lisensene for betalte utvidelser, og hvem kan i praksis låse virksomheten ute av sitt eget nettsted. Svaret overrasker nesten alltid. I en revisjon fant vi at det eneste mennesket med tilgang til DNS var en frilanser ingen hadde snakket med på fire år. Det er ikke et hypotetisk problem: mister du kontakten, mister du kontrollen, og står du midt i en hendelse, er responstiden din avhengig av en person uten avtale og uten forpliktelser.

#Tre mønstre fra norske revisjoner

Tre anonymiserte mønstre som går igjen, gjenfortalt uten detaljer som kan identifisere noen.

Nettbutikken med skimming-forsøket: en norsk nettbutikk på WooCommerce meldte om “rare utslag” i kassen. Revisjonen fant fremmed JavaScript lastet inn på betalingssiden fra en gammel, sårbar utvidelse, et klassisk kortskimming-oppsett der skriptet forsøkte å lese kortfelter før betalingsleverandøren tok over. Forsøket var klønete og hadde trolig ikke lykkes med å hente reelle kortdata, men funnet utløste likevel en avviksvurdering: hvilke kunder kunne vært berørt, og hva skulle eventuelt meldes. Butikken hadde flaks. Med en revisjon to år tidligere hadde den ikke trengt flaks.

Medlemsorganisasjonen med spam-injeksjonen: en organisasjon med noen tusen medlemmer oppdaget at Google viste apotekreklame i søketreffene deres. Installasjonen var infisert med injisert spam-innhold, synlig bare for søkemotorer, via et tema som ikke var oppdatert siden 2020. Selve opprydningen var håndverk, men det interessante funnet var medlemsregisteret: samme database, samme kompromitterte installasjon, fulle navn og kontaktinfo. Ingen data var beviselig hentet ut, men organisasjonen kunne ikke dokumentere det motsatte, og læringen ble at medlemsdata ikke skal bo i samme installasjon som et utstillingsvindu ingen vedlikeholder.

B2B-selskapet med den gamle byråtilgangen: under kartleggingen av kontoer fant vi en aktiv admin-bruker knyttet til et byrå kunden avsluttet samarbeidet med tre år tidligere. Ingen ondsinnet aktivitet, men kontoen hadde vært brukt til innlogging så sent som samme kvartal, trolig av en automatisert vedlikeholdsrutine byrået aldri hadde skrudd av. Tre års stille tilgang til et system med kundedata, uten avtale, uten databehandleravtale og uten at noen visste. Det funnet kostet ti minutter å rette og var alene verdt revisjonen.

#Hva revisjonen leverer, og hva den ikke er

Leveransen er en rapport med prioritert funnliste, og prioritert betyr noe presist: hvert funn er manuelt verifisert, plassert etter reell utnyttbarhet og konsekvens i akkurat ditt miljø, og følges av et konkret anbefalt tiltak med anslått innsats. Kritiske funn varsles umiddelbart, ikke i rapporten tre uker senere. Personvernkonsekvensen vurderes per funn, slik at rapporten kan brukes rett inn i behandlingsprotokollen og som grunnlag hvis noe må meldes. Til slutt går vi gjennom rapporten i et møte der både teknisk ansvarlig og ledelse kan stille spørsmål, for en rapport ingen forstår er en rapport ingen handler på.

Like viktig er hva revisjonen ikke er. Den er ikke en skannerdump: verktøy som WPScan inngår i arbeidet, men rådataene deres er råstoff, ikke leveranse. Den er ikke en skremselsøvelse: vi teller ikke opp teoretiske sårbarheter for å blåse opp funnlisten. Og den er ikke et salgsdokument forkledd som analyse: rapporten er uavhengig av om vi får oppfølgingsarbeidet, og skrives slik at en hvilken som helst kompetent leverandør, inkludert den du allerede har, kan utføre tiltakene. Trenger installasjonen varig oppfølging etterpå, er vedlikehold og support for Oslo-virksomheter den naturlige fortsettelsen, og krever funnene større ombygginger, står WordPress-utvikling for Oslo-markedet klar under samme tak.

#Når du ikke trenger en full revisjon

Avsnittet som mangler på de fleste tjenestesider. En fersk installasjon bygget av et kompetent byrå for under et år siden, med oppdateringsavtale, tofaktor og testet sikkerhetskopi, trenger ingen full revisjon ennå. Da holder en times gjennomgang av tilganger og rutiner. Det samme gjelder en ren brosjyreside uten skjemaer, uten innlogging og uten personopplysninger: der er en herdet konfigurasjon og automatiske oppdateringer viktigere enn en rapport. Og står du midt i en aktiv hendelse, er revisjon feil verktøy, da trenger du hendelseshåndtering først og revisjon etterpå, når det igjen finnes et normalnivå å revidere mot.

Full revisjon er riktig når minst ett av punktene treffer: nettstedet behandler kundedata eller betalinger, installasjonen har historikk med flere leverandører, ingen kan svare på hvem som har tilgang til hva, det er mer enn to år siden noen så systematisk på sikkerheten, eller en kunde, revisor eller anbudsprosess krever dokumentasjon. En kort forsamtale avklarer hvilken kategori du er i, og havner du i den første, sier vi det og fakturerer deretter.

#Samarbeidsmodell for norske B2B-kunder

En sikkerhetsrevisjon krever tillit, for du gir en ekstern part innsyn i det mest sårbare du har. Derfor er rammene formelle fra første dag: skriftlig avtale om omfang, taushetsplikt, databehandleravtale der det er relevant, og egne tidsbegrensede revisjonskontoer som opprettes ved start og slettes ved levering. Alt vi gjør i miljøet ditt logges og dokumenteres, ingen endringer gjøres uten avtale, og destruktive tester kjøres aldri mot produksjon. Norge og Polen deler tidssone, så dialogen går uten forsinkelse, og rapporten leveres på norsk med teknisk vedlegg på engelsk, slik at både ledelsen og en eventuell utenlandsk driftspartner kan bruke den.

Prisingen er individuell og settes som en fast ramme etter forsamtalen, ikke som løpende timer. Etter revisjonen velger du fritt: utbedre med egen leverandør, med oss, eller i kombinasjon. For virksomheter som også vil redusere angrepsflaten arkitektonisk, ved å legge et filtrerende lag foran installasjonen, er Cloudflare Workers og edge-utvikling for Oslo-markedet en naturlig neste samtale, men det er en egen beslutning, ikke en del av revisjonen. Inngangen er uforpliktende: en forsamtale om omfang og en tydelig anbefaling, også når anbefalingen er at du ikke trenger oss ennå.

Sist oppdatert: 10. juli 2026