Kort sagt: En it-nødplan til webservere fastlægger på forhånd, hvem der beslutter i et alvorligt tilfælde, hvem man kan få fat i, hvilke systemer der kan være berørt, og hvilke trin der følger i hvilken rækkefølge. Den, der vil oprette en it-nødplan, har ikke brug for en tyk håndbog, men for få, aktuelle sider, som også er tilgængelige uden fungerende it. Situationen omkring PHP2Shell er en god anledning til at gøre det nu.
Hvorfor en nødplan sparer tid og skade
I et alvorligt tilfælde går de første timer ofte tabt med at lede: Hvem har adgang til hostingudbyderen? Hvor ligger sikkerhedskopierne? Hvem beslutter, om shoppen går offline? Hvem skal informeres? En nødplan besvarer disse spørgsmål på forhånd, i ro og mag.
PHP2Shell har vist, hvor kort tiden kan være. Den 20.10.2026 varslede php.net patchene, den 21.10. kl. 16 tysk tid blev de offentliggjort, og BSI (det tyske forbundsagentur for informationssikkerhed) anbefalede øjeblikkelig opdatering eller midlertidig nedlukning. Virksomheder med en plan vidste, hvem de skulle ringe til, og hvilke servere de skulle kontrollere. Andre måtte først finde ud af, hvor PHP overhovedet kører.
Opret en it-nødplan: byggestenene
En praktisk anvendelig plan til webservere omfatter disse dele:
1. Roller og beslutninger. Hvem leder i nødstilfælde, hvem er stedfortræder, hvem må lukke systemer ned, hvem taler udadtil? Notér navne og stedfortrædere.
2. Kontaktliste. Interne kontaktpersoner, hostingudbyder, bureau, it-tjenesteudbyder, databeskyttelsesrådgiver, juridisk rådgivning, cyberforsikring med forsikringsnummer, den kompetente tilsynsmyndighed for databeskyttelse, Zentrale Ansprechstelle Cybercrime (centralt kontaktpunkt for it-kriminalitet ved politiet) i jeres delstat. Denne liste skal foreligge udskrevet.
3. Systemfortegnelse. Hvert website, hver shop og hver portal med server, hostingudbyder, driftsform, PHP-version, applikation, ansvarlig og arten af de behandlede data.
4. Beslutningsregler. Under hvilke betingelser tager vi et system af nettet? Hvem må beslutte det? Hvad gælder om natten og i weekenden?
5. Forløb. Korte trinfølger for typiske tilfælde: kritisk sårbarhed kendt, mistanke om indbrud, website forvansket, data udstrømmet, afpresning.
6. Indberetningsveje. Hvem vurderer en anmeldelsespligt efter art. 33 GDPR, om muligt inden for 72 timer fra kendskabet? Hvem indberetter til BSI ved NIS2-pligt? Hvem informerer forsikringsselskabet?
7. Genopretning. Hvor ligger sikkerhedskopierne, hvem kan spille dem tilbage, hvor længe tager det, hvornår blev det sidst afprøvet?
Eksempel: forløbet „kritisk PHP-sårbarhed“
Sådan kan et forløb se ud, som det var brug for ved PHP2Shell:
| Trin | Hvem | Resultat |
|---|---|---|
| Vurdér meddelelsen (php.net, BSI) | It-ansvarlige | berørte systemer ifølge fortegnelsen |
| Indspil opdatering, genstart alle workere | Administrator eller tjenesteudbyder | Dokumentation med pakkestatus og proces-tidspunkt |
| Hvor opdatering ikke er mulig: midlertidige foranstaltninger eller af nettet | Ledelsen beslutter | dokumenteret beslutning |
| Sikr logs, undersøg spor | Administrator eller forensik | fund eller ingen fund |
| Ved fund: start hændelsesforløb | Nødledelse | kontrollér indberetningsveje |
Vigtigt her: En patch lukker sårbarheden, men fjerner ikke skadelig software, der er smuglet ind tidligere. Derfor hører sporsøgningen fast med i forløbet.
Fastlæg, hvor længe webserverlogs opbevares, og hvor de ligger uden for serveren. Ved PHP2Shell anbefalede fagpressen at gemme logs fra og med 20.10.2026. Den, der kun beholder logs i få dage, kan ikke gennemføre sådanne anbefalinger.
Forebyggelse, der først gør planen virksom
En plan er kun så god som forudsætningerne bag den. Kontrollér, om der findes sikkerhedskopier efter 3-2-1-reglen, og om de er afprøvet, se Sikkerhedskopier efter 3-2-1-reglen. Afklar skriftligt med hostingudbyder og bureau, hvem der overtager hvad ved kritiske sårbarheder. Hold adgangsdata til nødstilfælde sikkert, men tilgængeligt, f.eks. i en beskyttet adgangskodeboks med nødadgang.
Forbered desuden tekstskabeloner: intern information, kundemeddelelse, henvisning på en statisk vedligeholdelsesside. Henvisninger hertil står under Krisekommunikation efter et angreb.
Øv og hold aktuel
En plan, der aldrig er øvet, indeholder næsten altid huller. Gennemspil én gang om året et scenarie, f.eks. „kritisk PHP-sårbarhed fredag eftermiddag“, og notér, hvor det hakker. En enkel test er nok til at begynde med: Kan en anden person uden hjælp fra den første nå hostingudbyderen, spille en sikkerhedskopi tilbage og sætte websitet i vedligeholdelsestilstand? Hvis ikke, mangler der noget i planen, oftest en adgang, et telefonnummer eller en beskrivelse. Netop sådanne huller skal øvelser gøre synlige, før det bliver alvor. Opdatér planen efter hver øvelse og hver væsentlig ændring. Som metodisk ramme egner IT-Grundschutz fra BSI og BSI-Standard 200-4 om Business Continuity Management sig.
Juridiske spørgsmål, f.eks. om anmeldelsespligter, afklarer planen ikke endeligt. Den sørger for, at de rette personer inddrages i tide. Denne side er generel information og ingen juridisk rådgivning.
Hvordan hjælper PHP SOS konkret?
- Vi opretter sammen med jer systemfortegnelsen over jeres webservere, inklusive driftsform og PHP-version.
- Vi skriver de tekniske forløb for typiske scenarier og afstemmer dem med hostingudbyder og bureau.
- Vi gennemfører en øvelse og indarbejder erkendelserne i planen.
- I et alvorligt tilfælde overtager vi den tekniske side via incident response, på ønske understøttet af en sikkerhedsvedligeholdelsesaftale.
Ofte stillede spørgsmål
Hvor omfattende skal en it-nødplan være?
Så kort som muligt, så udførlig som nødvendigt. Til webservere er få sider med kontakter, systemliste, beslutningsregler og forløb ofte nok. Vigtigere end omfanget er, at den er aktuel og kan findes i et alvorligt tilfælde.
Hvor opbevarer jeg nødplanen?
Mindst ét sted, som også er tilgængeligt uden fungerende it, f.eks. udskrevet eller på en adskilt enhed. En plan, der kun ligger på den berørte server eller i det spærrede virksomhedsnet, hjælper ikke i et alvorligt tilfælde.
Hvor ofte bør planen kontrolleres?
Mindst én gang om året og efter hver væsentlig ændring, f.eks. skift af hostingudbyder eller ny software. Fornuftig er en kort øvelse, hvor et scenarie gennemspilles.
Findes der skabeloner fra BSI?
BSI behandler nødstyring inden for rammerne af IT-Grundschutz og i BSI-Standard 200-4 om Business Continuity Management. Disse egner sig som ramme; til webservere kan det betale sig med en knap, praksisnær udgave.