WordPress-hendelsesrespons under NIS2: 24-timers playbook for tidlig varsel
Artikkel 23 i direktiv 2022/2555 presser den første fasen av hendelseshåndteringen inn i tre frister: 24 timer, 72 timer og en måned. 24-timersfristen overrasker WordPress-driftere, fordi den starter når man får kjennskap til hendelsen, ikke når den er utbedret. Og på et typisk WordPress-nettsted kommer den kjennskapen oftere fra en Slack-melding enn fra et SOC-dashbord.
Dette er en støtteartikkel til søylen om NIS2 og DORA for WordPress.
TL;DR
- 24 timer fra kjennskap: tidlig varsel til CSIRT.
- 72 timer fra kjennskap: hendelsesmelding med første vurdering.
- 1 måned etter 72-timersmeldingen: sluttrapport med årsak og utbedring.
- “Kjennskap” er utløseren, ikke et SIEM-varsel.
- Seks WordPress-signaler som for meg betyr “klokken går”.
- Maler på nasjonale språk i denne playbooken.
Hva NIS2 artikkel 23 krever
Artikkel 23 nr. 1 fastsetter plikten: enhver hendelse med vesentlig innvirkning på tjenesteytingen skal meldes til CSIRT eller kompetent myndighet. Artikkel 23 nr. 3 definerer “vesentlig”: en hendelse som kan forårsake alvorlig driftsforstyrrelse i tjenestene eller økonomisk tap for enheten, eller materiell eller immateriell skade for andre fysiske eller juridiske personer.
Artikkel 23 nr. 4 deler opp tidslinjen:
- (a) Uten unødig opphold, og i alle tilfeller innen 24 timer etter at man fikk kjennskap til den vesentlige hendelsen: et tidlig varsel som angir om hendelsen mistenkes å ha en ulovlig eller ondsinnet årsak, og om den kan ha grenseoverskridende virkning.
- (b) Uten unødig opphold, og i alle tilfeller innen 72 timer: en hendelsesmelding som oppdaterer det tidlige varselet og inneholder en første vurdering av alvorlighetsgrad, virkning og tegn på kompromittering.
- (c) På anmodning fra CSIRT eller kompetent myndighet: en mellomrapport om status.
- (d) Senest en måned etter meldingen under bokstav b: en sluttrapport med detaljert beskrivelse, trusseltype eller grunnårsak, iverksatte utbedringstiltak og eventuell grenseoverskridende virkning.
Klokken starter når man får kjennskap til en vesentlig hendelse. Direktivet definerer ikke dette tidspunktet, og fortalepunkt 102 gjentar bare fristene. Denne playbooken registrerer kjennskap når en kyndig person i enheten med tilstrekkelig sikkerhet slår fast at en vesentlig hendelse har skjedd, og noterer hvem som slo det fast og på hvilket grunnlag. Det betyr mye for WordPress, fordi kjennskapen vanligvis kommer fra en kunde-e-post, en ekstern overvåkingstjeneste eller en sårbarhetsskanner, ikke fra et internt SOC.
Når en hendelse er vesentlig etter gjennomføringsforordning 2024/2690
Artikkel 23 nr. 3 i direktivet gir den generelle testen. For enkelte typer enheter har Kommisjonen gjort den konkret. Gjennomføringsforordning (EU) 2024/2690 gjelder DNS-tjenesteytere, TLD-navneregistre, leverandører av skytjenester, leverandører av datasentertjenester, leverandører av innholdsleveringsnettverk, leverandører av administrerte tjenester, leverandører av administrerte sikkerhetstjenester, leverandører av nettbaserte markedsplasser, nettbaserte søkemotorer og plattformer for sosiale nettverkstjenester, og tilbydere av tillitstjenester (artikkel 1). Det finnes ingen offisiell norsk tekst; betegnelsene her er oversatt fra den engelske versjonen. Et WordPress-byrå som driver hosting, vedlikehold og overvåking for kunder, kan falle inn under leverandører av administrerte tjenester. Om det gjør det, avgjøres av klassifiseringen etter direktivets vedlegg og nasjonal rett, ikke av denne playbooken.
For disse enhetene regner artikkel 3 nr. 1 i forordningen en hendelse som vesentlig når minst ett av disse kriteriene er oppfylt:
- direkte økonomisk tap over 500 000 euro eller 5 % av enhetens samlede årsomsetning i foregående regnskapsår, avhengig av hvilket beløp som er lavest;
- eksfiltrering av forretningshemmeligheter slik de er definert i direktiv (EU) 2016/943;
- dødsfall for en fysisk person, eller betydelig skade på en persons helse;
- vellykket, mistenkt ondsinnet og uautorisert tilgang til nettverks- og informasjonssystemer som kan forårsake alvorlig driftsforstyrrelse;
- de enhetsspesifikke tersklene i artikkel 5 til 14.
For leverandører av administrerte tjenester og administrerte sikkerhetstjenester fastsetter artikkel 10 disse tersklene: tjenesten er helt utilgjengelig i mer enn 30 minutter; tilgjengeligheten er begrenset for mer enn 5 % av brukerne i Unionen, eller mer enn 1 million brukere, avhengig av hvilket tall som er lavest, i mer enn én time; eller integriteten, konfidensialiteten eller autentisiteten til data knyttet til tjenesten er kompromittert som følge av en mistenkt ondsinnet handling, eller med virkning for mer enn 5 % av brukerne eller 1 million brukere, avhengig av hvilket tall som er lavest.
To regler endrer vurderingen i en WordPress-portefølje. Artikkel 3 nr. 2 holder planlagte driftsavbrudd og planlagte følger av planlagt vedlikehold utenfor, så et varslet vedlikeholdsvindu er ikke en vesentlig hendelse etter denne testen. Artikkel 4 legger til gjentakende hendelser: hendelser som hver for seg ikke er vesentlige, regnes samlet som én vesentlig hendelse når de har skjedd minst to ganger i løpet av seks måneder, har samme tilsynelatende grunnårsak og samlet oppfyller kriteriet om økonomisk tap. Punkt 3.4.2 bokstav b i vedlegget krever en kvartalsvis kontroll av slike hendelser. I WordPress er gjentatt reinfeksjon gjennom den samme upatchede pluginen mønsteret kontrollen skal fange.
Enheter utenfor listen i artikkel 1 bruker fortsatt testen i artikkel 23 nr. 3 slik den er gjennomført i nasjonal rett.
Slik gjenkjenner du et innbrudd på et WordPress-nettsted
Disse funnene krever at man åpner en sak og vurderer vesentlighet med en gang. De starter ikke NIS2-fristen automatisk. Artikkel 23 gjelder når en regulert enhet får kjennskap til at hendelsen er vesentlig etter gjeldende regler.
1. Defacement på en kundevendt side. Indekserte defacements, byttet forside, byttede produktsider. Synligheten gjør det lettere å vurdere alvorlighetsgraden: skaden på kundetilliten er et faktum.
2. Kompromittert admin-konto med bekreftet innlogging. En ny admin-konto, en eksisterende admin-konto med innlogginger fra et uvanlig IP-område eller land, en admin-konto som endrer andre kontoer. Oppdages av audit log-plugins (WP Activity Log, Stream, Wordfence audit log).
3. Installasjon av ondsinnet plugin eller opplasting av tema. En plugin-fil i wp-content/plugins/ som har kommet utenom den vanlige oppdateringskanalen, eller med PHP som kaller eval, base64_decode, gzinflate eller assert på brukerdata. Oppdages av filintegritetsovervåking eller en Wordfence-skanning.
4. Injeksjon i databasen med bekreftet skriving. SQL-injeksjon som har klart å sette inn eller endre rader. Bekreftet av en diff i audit loggen eller manipulering i wp_users eller wp_options. Klassisk signal: alternativet siteurl peker plutselig mot et fremmed domene.
5. Uautorisert eksport av personopplysninger. En WordPress-eksport, et REST API-kall som returnerer brukerlisten, et stort svar fra wp-json/wp/v2/users fra en uventet IP. GDPR artikkel 33 kan slå inn parallelt med NIS2 artikkel 23.
6. Ransomware eller kryptering av filsystemet i produksjon eller i sikkerhetskopiene. Filer med nye filendelser, .html med løsepengekrav i opplastingsmappene, krypterte backup-arkiver. Dette er et signal med høy alvorlighetsgrad, men omfang og vesentlighet krever fortsatt en dokumentert beslutning.
For hvert av disse funnene sier byråets runbook: tidsstempel øyeblikket for kjennskap i IR-saken, navngi den ansvarlige, start 24-timersklokken, varsle enhetens CISO eller tilsvarende innen den første timen. Byrået sender ikke meldingen til CSIRT; det gjør enheten. Byrået leverer det tekniske innholdet.
Mal for tidlig NIS2-varsel innen 24 timer
Det tidlige varselet er kort med vilje. Malen jeg leverer til enhetens compliance-team:
Enhet: [juridisk navn]
Sektor: [klassifisering etter vedlegg I eller II]
Nasjonal identifikator: [organisasjonsnummer eller registernummer]
Sammendrag av hendelsen
Dato og tidspunkt for kjennskap: [ISO-8601 med tidssone]
Kilde til oppdagelsen: [audit log / kundemelding / ekstern skanner / varsel fra hostingleverandør]
Berørt tjeneste: [offentlig WordPress-nettsted på https://example.com, kundeportal osv.]
Første klassifisering
Antatt årsak: [ondsinnet / utilsiktet / under avklaring]
Grenseoverskridende virkning: [ja / nei / under avklaring]
Tegn på grenseoverskridende virkning: [hvis ja, hva som peker mot det]
Første vurdering av virkning
Tjenestens tilgjengelighet: [i drift / redusert / utilgjengelig]
Bekreftet tilgang til data: [ingen / mistanke / bekreftet]
Antall personer som kan være berørt: [antall hvis kjent, ellers "under avklaring"]
Første respons
Begrensningstiltak: [rotering av legitimasjon, fjerning av plugin, IP-blokkering osv.]
Pågående forensisk undersøkelse: [ja / nei, med navn på leverandør hvis ekstern]
Neste oppdatering: [tidspunkt for 72-timersmeldingen eller en tidligere mellomrapport]
Kontakt
Navn og rolle: [CISO, IT-sjef osv.]
E-post og telefon: [direktenummer]Dette er det tidlige varselet, ikke hendelsesmeldingen. 72-timersmeldingen utvider det med vurdering av alvorlighetsgrad, tegn på kompromittering og en klarere vurdering av grenseoverskridende virkning.
Hva NIS2-hendelsesmeldingen etter 72 timer inneholder
Innen 72 timer fra kjennskap legger hendelsesmeldingen til:
- Vurdering av alvorlighetsgrad. Antall berørte brukere, geografisk fordeling, anslag over økonomisk tap, anslått tid til gjenoppretting.
- Tegn på kompromittering. IP-adresser, filhasher, URL-er, ondsinnede User-Agent-strenger, angrepssignaturer. Artikkel 23 nr. 4 bokstav b krever dem der de er tilgjengelige.
- Vurdering av grenseoverskridende virkning. Bekreftet eller utelukket, med begrunnelse.
- Status for begrensning. Hva som er under kontroll, og hva som fortsatt er åpent.
- Behov for samarbeid. Om enheten trenger støtte fra CSIRT eller andre myndigheter.
I WordPress inneholder indikatorblokken vanligvis: angripernes IP-adresser fra access-loggene, stier til ondsinnede filer i wp-content/, hasher av de ondsinnede filene, User-Agent-strenger observert under utnyttelsen og HTTP request body tatt vare på av WAF-en.
Hvilke elementer NIS2-sluttrapporten etter en hendelse må inneholde
Artikkel 23 nr. 4 bokstav d: sluttrapport senest en måned etter hendelsesmeldingen. Innhold:
- Detaljert beskrivelse av hendelsen.
- Trusseltype eller grunnårsak.
- Iverksatte og pågående utbedringstiltak.
- Grenseoverskridende virkning der det er relevant.
For WordPress-hendelser ender årsaksdelen vanligvis på en av disse: en utdatert plugin med kjent CVE, svake admin-legitimasjoner uten MFA, en eksponert wp-config.php fra en backup-fil, RCE gjennom en temafunksjon, kompromittering av forsyningskjeden i oppdateringskanalen, feilkonfigurasjon på serveren. Utbedringsdelen kobler årsaken til tiltaket i artikkel 21 nr. 2 som burde ha forhindret den, og oppdaterer enhetens risikoregister.
Hva NIS2 artikkel 23 krever i tillegg til de tre rapportene
Fristene på 24 timer, 72 timer og en måned er det alle husker. Den samme artikkelen inneholder flere plikter og ett vern:
- Pågående hendelser. Etter artikkel 23 nr. 4 bokstav e skal enheten, hvis hendelsen fortsatt pågår når sluttrapporten forfaller, levere en fremdriftsrapport på det tidspunktet og sluttrapporten innen en måned etter at håndteringen av hendelsen er avsluttet.
- Svar fra CSIRT. Artikkel 23 nr. 5 pålegger CSIRT eller kompetent myndighet å svare uten unødig opphold og om mulig innen 24 timer etter mottatt tidlig varsel, med en første tilbakemelding og, på anmodning, veiledning om tiltak. Mistenkes hendelsen å være straffbar, gis det også veiledning om anmeldelse til politiet.
- Mottakere av tjenesten. Der det er hensiktsmessig, varsler enheten uten unødig opphold mottakerne av tjenestene sine om vesentlige hendelser som kan svekke leveransen av tjenestene (artikkel 23 nr. 1). Etter artikkel 23 nr. 2 får mottakere som kan bli berørt av en vesentlig cybertrussel, vite hvilke tiltak de selv kan iverksette. For en WordPress-nettbutikk eller en kundeportal er dette kundemeldingen som er skrevet på forhånd.
- Tilbydere av tillitstjenester. Som unntak fra bokstav b melder en tilbyder av tillitstjenester vesentlige hendelser som berører tillitstjenestene, innen 24 timer etter kjennskap, ikke innen 72.
- Ansvar. Artikkel 23 nr. 1 fastslår at selve meldingen ikke gir den meldende enheten økt ansvar.
- Informasjon til allmennheten. Etter artikkel 23 nr. 7 kan CSIRT eller kompetent myndighet, etter å ha rådført seg med enheten, informere allmennheten eller pålegge enheten å gjøre det, når det trengs for å forebygge eller håndtere hendelsen, eller når offentliggjøring ellers er i allmennhetens interesse.
- Nestenhendelser. Artikkel 6 nr. 5 definerer en nestenhendelse som en hendelse som kunne ha kompromittert tilgjengeligheten, autentisiteten, integriteten eller konfidensialiteten til data eller tjenester, men som ble forhindret eller ikke inntraff. Artikkel 30 lar vesentlige og viktige enheter melde hendelser, cybertrusler og nestenhendelser frivillig. Et blokkert utnyttelsesforsøk mot en WordPress-plugin er ingen pliktig melding, men kan sendes via denne kanalen.
Hvor du melder en NIS2-hendelse i Norge og EU
Hver medlemsstat utpeker minst én CSIRT og én kompetent myndighet. Den oppdaterte listen føres i ENISA-portalen. De vanligste mottakerne for enhetene jeg jobber med:
- Norge. Ikke en medlemsstat i EU, og NIS2 er ennå ikke tatt inn i EØS-avtalen. Direktivet er rettet til medlemsstatene (artikkel 46), så meldeplikten følger av digitalsikkerhetsloven §§ 8 og 11 og digitalsikkerhetsforskriften § 17: varsel til tilsynsmyndigheten med kopi til Nasjonalt kontaktpunkt innen 24 timer, oppdatering innen 72 timer og hendelsesrapport innen en måned. NSM er nasjonalt kontaktpunkt.
- Tyskland. Bundesamt für Sicherheit in der Informationstechnik (BSI) og CERT-Bund.
- Spania. INCIBE-CERT for privat sektor og innbyggere, CCN-CERT for offentlig forvaltning.
- Portugal. CERT.PT under CNCS (Centro Nacional de Cibersegurança).
For enheter som opererer i flere jurisdiksjoner fører ENISA en liste over felles kontaktpunkter (SPOC) for grenseoverskridende koordinering.
Oppdatering, . Når et angrep rammer mer enn ditt eget nettsted, finnes det én adresse til. Wordfence startet 26. oktober 2026 et Threat Response Team som har ansvaret fra første signal om en ny trussel til situasjonen er stabil, normalt de første 72 timene (kunngjøringen fra Wordfence). Teamet tar imot meldinger på [email protected] i tre tilfeller: en utvidelse eller et tema som utnyttes aktivt, et angrep på leverandørkjeden som en manipulert oppdatering, eller en kampanje mot mange WordPress-nettsteder samtidig. Wordfence ber om hva du ser og når det startet, berørt utvidelse eller tema med versjon, indikatorer (mistenkelige filer, ukjente administratorkontoer, IP-adresser, loggoppføringer) og kontaktinformasjon. Det er de samme dataene du samler til det tidlige varselet etter malen over, så én bevispakke dekker begge meldingene. IP-adresser i logger er personopplysninger etter GDPR: send angripernes adresser, ikke besøksloggene til kundene dine. Meldingen erstatter ikke meldeplikten etter norsk rett, og varselet til NSM sendes uansett hva sikkerhetsleverandøren gjør.
Slik lager du en plan for hendelsesrespons i WordPress
24-timersfristen er nådeløs for enheter som først begynner å forberede seg etter at de har fått kjennskap til hendelsen. Før noen hendelse inntreffer:
- Navngitt vaktrotasjon. To personer, primær og reserve, med telefonnumre i IR-runbooken.
- Eskaleringstre til enhetens CISO. Byrået sender ikke det tidlige varselet; det gjør enheten. Derfor må veien fra “byrået ser” til “enheten bestemmer” være under en time.
- Kommunikasjonsmaler laget på forhånd. Varsel til kunder, internt varsel, varsel til tilsynsmyndighet. Alle tre på de relevante språkene.
- Mulighet for snapshot av produksjonsinstansen av WordPress. Før ethvert begrensningstiltak tar du vare på filsystemet og databasen for forensisk analyse.
- Avtale med en forensisk leverandør, inngått på forhånd. Forensikk under artikkel 23 innen 72 timer krever en leverandør som tar telefonen, ikke en anbudsforespørsel.
- Ekstern backup i immutable-modus. Uten den kan ransomware gjøre sluttrapporten umulig ved å ødelegge bevisene.
Pris for å bygge denne beredskapen er individuell og avhenger av hvor stor WordPress-porteføljen er; det er ikke en post på hostingfakturaen.
Krav til hendelseshåndtering i gjennomføringsforordning 2024/2690
Del 3 av vedlegget til gjennomføringsforordning 2024/2690 fastsetter kravene til hendelseshåndtering etter artikkel 21 nr. 2 bokstav b i direktivet for enhetene i forordningens artikkel 1. Overført til en WordPress-portefølje endrer disse punktene det daglige arbeidet:
- Retningslinjer for hendelseshåndtering (3.1). Roller, ansvar og prosedyrer for å oppdage, analysere, begrense, gjenopprette, dokumentere og rapportere hendelser, med et kategoriseringssystem, kommunikasjonsplaner for eskalering og rapportering og dokumentene som brukes i responsen: håndbøker, eskaleringsdiagrammer, kontaktlister og maler (3.1.2). Malen for tidlig varsel ovenfor er ett av disse dokumentene. Retningslinjene testes og gjennomgås med planlagte mellomrom og etter vesentlige hendelser (3.1.3).
- Logging (3.2.3). Der det er hensiktsmessig, dekker loggene oppretting, endring eller sletting av brukere og utvidelse av tillatelser, autentiseringshendelser, all privilegert tilgang og aktivitet fra administrative kontoer, samt tilgang til eller endring av kritiske konfigurasjons- og sikkerhetskopifiler. I WordPress betyr det: endringer i brukere og roller, administratorinnlogginger og endringer i
wp-config.php,.htaccessog backup-arkiver. - Beskyttede logger (3.2.5). Logger oppbevares i en forhåndsdefinert periode og beskyttes mot uautorisert tilgang eller endring. En logg som bare ligger på den kompromitterte WordPress-serveren, kan angriperen endre, så den er vanskelig å regne som beskyttet.
- Synkronisert tid (3.2.6). Systemene bruker synkroniserte tidskilder slik at logger kan korreleres. Uten det kan tidsstempelet for kjennskap i det tidlige varselet ikke sammenholdes med logger fra webserver, WAF og database.
- Melding om hendelser (3.3). En enkel mekanisme lar ansatte, leverandører og kunder melde mistenkelige hendelser, og leverandører og kunder får der det er hensiktsmessig vite om den.
- Respons (3.5). Begrensning, fjerning og gjenoppretting; kommunikasjonsplaner med CSIRT eller kompetent myndighet; logging av responsaktiviteter med registrerte bevis; testing av prosedyrene med planlagte mellomrom.
- Gjennomgang etter hendelsen (3.6). Der det er hensiktsmessig, finner en gjennomgang etter gjenoppretting grunnårsaken og ender i dokumenterte erfaringer. Sluttrapporten etter artikkel 23 nr. 4 bokstav d og denne gjennomgangen bygger på de samme bevisene.
Slik vurderer du en WordPress-hendelse og sikrer bevis
Etter et troverdig signal åpner teamet én hovedsak for hendelsen. Den registrerer den opprinnelige observasjonen, tidspunkt med tidssone, kilde, miljø og hvem som leder arbeidet. Teamet vurderer ektheten, virkningen på konfidensialitet, integritet og tilgjengelighet, og først deretter om kriteriene for en vesentlig hendelse kan være oppfylt. Operative nivåer som hendelse, alvorlig hendelse og krise organiserer ressursene, men erstatter verken artikkel 23 eller nasjonal lov. Bekreftet tilgang, kontoer, komponenter, kundeflyter, tidspunkt, omfang, leverandører og sikkerhetsnivå oppdateres løpende. Det som er ukjent, forblir merket som ukjent.
Begrensning og sikring av bevis går parallelt. Før man bygger opp igjen eller fjerner mistenkelig kode, tas det, hvis det er trygt, et snapshot eller en kopi av filene, databasens tilstand, deploy-ID, sesjoner, administratorer og logger. Originalene bevares, filene får sjekksummer, og arbeidskopier holdes adskilt. Hver endring, inkludert rotering av tilgangsdata, WAF-regler, fjerning av plugins, gjenoppretting og DNS, føres inn i tidslinjen. Sikkerhet går foran når det å bevare bevis forlenger skaden; et manglende bevis må begrunnes.
Ved siden av den tekniske tidslinjen føres en kronologisk beslutningslogg med fakta, antakelser, alternativer, eier og tidspunkt for gjennomgang. Teknikk, ledelse, juss og personvern samt kommunikasjon til kunder har egne spor som koordinatoren samordner. Byrået leverer komponenter, tidspunkt for oppdagelse, referanser til bevis, status for begrensning, mistenkt tilgang og anslag for gjenoppretting. Enheten tar beslutningen og sender meldingen, med mindre en uttrykkelig fullmakt sier noe annet.
Slik tester du planen for hendelsesrespons
Øvelsen bør samle hostingleverandøren, byrået, hendelseslederen, personvern og kommunikasjon. Den går fra varsel via bevis og vurdering av vesentlighet til overlevering til tilsynsmyndigheten, godkjenning av gjenoppretting og meldinger til kunder. For å bli godkjent kreves respons fra vakten, en korrekt sak, innsamling av bevis uten improvisert tilgang, overlevering til beslutningstakeren, oppdaterte maler, et rent gjenopprettingspunkt og en eier og frist for hver forbedring.
Etter gjenopprettingen står man igjen med tidslinjen, beslutningsloggen, bevisindeksen, kopier av meldingene, listen over eiendeler, årsaksanalysen, bevis på restore, kommunikasjonen og verifisering av utbedringene. Et midlertidig tiltak erstattes av en varig kontroll eller en formell beslutning om restrisiko.
For forberedelse eller en øvelse kan du sende en skriftlig beskrivelse via EU-samsvarsrevisjonen for WordPress. Oppgi enheten, jurisdiksjoner, WordPress-miljøer, hosting, kritiske flyter, logging, backup, kontakter, tidligere øvelser og hull. Ikke send tilgangsdata, personopplysninger eller rå bevis på kompromittering i første omgang. Arbeidet forbedrer beredskapen og bevisene, men er ikke juridisk rådgivning, en garanti eller en automatisk konklusjon om at meldeplikt foreligger.
