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 fra kjennskap: 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 krever NIS2 artikkel 23?
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. ENISAs veiledning leser “kjennskap” som øyeblikket da en kyndig person i enheten med tilstrekkelig sikkerhet slår fast at en vesentlig hendelse har skjedd. 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.
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. ENISA anbefaler et skjema; CSIRT-ene godtar STIX 2.1 eller en fri liste.
- 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 må NIS2-sluttrapporten etter en hendelse 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.
Hvor du melder en NIS2-hendelse i Polen 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:
- Polen. CSIRT NASK for sivile sektorer, CSIRT GOV for offentlig forvaltning, CSIRT MON for forsvarsområdet. Kompetent nasjonal myndighet avhenger av sektoren.
- Tyskland. Bundesamt für Sicherheit in der Informationstechnik (BSI) og CERT-Bund. Sektorvise CSIRT-er for finans (CSIRT BaFin), energi og telekommunikasjon.
- Spania. INCIBE-CERT for privat sektor og innbyggere, CCN-CERT for offentlig forvaltning.
- Norge. Ikke medlem av EU, men tilknyttet gjennom EØS; NSM NCSC tar imot meldinger fra sektorer som frivillig har harmonisert seg.
- 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.
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.
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.
