Kort gezegd: Een IT-noodplan voor webservers legt vooraf vast wie in een noodgeval beslist, wie bereikbaar is, welke systemen getroffen kunnen zijn en welke stappen in welke volgorde volgen. Wie een IT-noodplan wil opstellen, heeft geen dik handboek nodig, maar enkele actuele pagina's die ook zonder werkende IT bereikbaar zijn. De situatie rond PHP2Shell is een goede aanleiding dat nu te doen.
Waarom een noodplan tijd en schade bespaart
In een noodgeval gaan de eerste uren vaak verloren met zoeken: wie heeft toegang tot de hostingprovider? Waar staan de back-ups? Wie besluit of de webwinkel offline gaat? Wie moet worden geïnformeerd? Een noodplan beantwoordt deze vragen vooraf, in alle rust.
PHP2Shell heeft laten zien hoe kort de tijd kan zijn. Op 20-10-2026 kondigde php.net de patches aan, op 21-10 om 16.00 uur Duitse tijd werden ze gepubliceerd, en het BSI adviseerde onmiddellijk updaten of tijdelijk uitschakelen. Bedrijven met een plan wisten wie ze moesten bellen en welke servers ze moesten controleren. Anderen moesten eerst uitzoeken waar PHP überhaupt draait.
IT-noodplan opstellen: de bouwstenen
Een praktisch bruikbaar plan voor webservers omvat deze onderdelen:
1. Rollen en besluiten. Wie leidt in een noodgeval, wie vervangt, wie mag systemen uitschakelen, wie spreekt naar buiten? Leg namen en vervangers vast.
2. Contactlijst. Interne aanspreekpunten, hostingprovider, bureau, IT-dienstverlener, functionaris voor gegevensbescherming, juridisch adviseur, cyberverzekering met polisnummer, bevoegde toezichthouder voor gegevensbescherming, de Zentrale Ansprechstelle Cybercrime (centraal contactpunt cybercriminaliteit van de politie) van uw deelstaat. Deze lijst moet uitgeprint beschikbaar zijn.
3. Systeeminventaris. Elke website, webwinkel en elk portaal met server, hostingprovider, uitvoeringsmodus, PHP-versie, toepassing, verantwoordelijke en soort verwerkte gegevens.
4. Beslisregels. Onder welke voorwaarden halen we een systeem van het net? Wie mag dat beslissen? Wat geldt 's nachts en in het weekend?
5. Procedures. Korte stappenreeksen voor typische gevallen: kritieke kwetsbaarheid bekend, vermoeden van inbraak, website geschonden, gegevens uitgestroomd, afpersing.
6. Meldkanalen. Wie toetst een meldplicht volgens art. 33 AVG, zo mogelijk binnen 72 uur na kennisname? Wie meldt bij een NIS2-plicht aan het BSI? Wie informeert de verzekeraar?
7. Herstel. Waar staan back-ups, wie kan ze terugzetten, hoe lang duurt dat, wanneer is dat voor het laatst getest?
Voorbeeld: procedure „kritieke PHP-kwetsbaarheid”
Zo kan een procedure eruitzien zoals die bij PHP2Shell nodig was:
| Stap | Wie | Resultaat |
|---|---|---|
| Melding beoordelen (php.net, BSI) | IT-verantwoordelijken | getroffen systemen volgens inventaris |
| Update doorvoeren, alle workers herstarten | Beheerder of dienstverlener | bewijs met pakketstatus en procestijd |
| Waar geen update mogelijk is: overbruggingsmaatregelen of van het net | Leiding besluit | gedocumenteerd besluit |
| Logs veiligstellen, sporen controleren | Beheerder of forensisch deskundige | bevinding of geen bevinding |
| Bij bevinding: incidentprocedure starten | Noodleiding | meldkanalen toetsen |
Belangrijk daarbij: een patch sluit de kwetsbaarheid, maar verwijdert geen eerder ingebrachte schadelijke software. Daarom hoort het zoeken naar sporen vast in de procedure.
Bepaal hoe lang logs van de webserver worden bewaard en waar ze buiten de server staan. Bij PHP2Shell adviseerde de vakpers logs vanaf 20-10-2026 te bewaren. Wie logs maar enkele dagen bewaart, kan zulke aanbevelingen niet opvolgen.
Voorzorg die het plan pas effectief maakt
Een plan is zo goed als de randvoorwaarden erachter. Controleer of er back-ups volgens de 3-2-1-regel zijn en of ze zijn getest, zie Back-ups volgens de 3-2-1-regel. Leg met hostingprovider en bureau schriftelijk vast wie bij kritieke kwetsbaarheden wat overneemt. Bewaar toegangsgegevens voor noodgevallen veilig maar bereikbaar, bijvoorbeeld in een beschermde wachtwoordkluis met noodtoegang.
Bereid bovendien tekstsjablonen voor: interne informatie, klantbericht, mededeling op een statische onderhoudspagina. Aanwijzingen daarvoor staan onder Crisiscommunicatie na een aanval.
Oefenen en actueel houden
Een plan dat nooit is geoefend, bevat bijna altijd hiaten. Speel eenmaal per jaar een scenario door, bijvoorbeeld „kritieke PHP-kwetsbaarheid op vrijdagmiddag”, en noteer waar het hapert. Een eenvoudige test volstaat om te beginnen: kan een tweede persoon zonder hulp van de eerste de hostingprovider bereiken, een back-up terugzetten en de website in onderhoudsmodus zetten? Zo niet, dan ontbreekt iets in het plan, meestal een toegang, een telefoonnummer of een beschrijving. Juist zulke hiaten moeten oefeningen zichtbaar maken voordat het menens wordt. Werk het plan bij na elke oefening en elke ingrijpende wijziging. Als methodisch kader zijn de IT-Grundschutz van het BSI en BSI-Standard 200-4 over business continuity management geschikt.
Juridische vragen, bijvoorbeeld over meldplichten, beantwoordt het plan niet afdoende. Het zorgt ervoor dat de juiste personen tijdig worden betrokken. Deze pagina is algemene informatie en geen juridisch advies.
Hoe helpt PHP SOS concreet?
- Wij stellen samen met u de systeeminventaris van uw webservers op, inclusief uitvoeringsmodus en PHP-versie.
- Wij schrijven de technische procedures voor typische scenario's en stemmen ze af met hostingprovider en bureau.
- Wij voeren een oefening uit en verwerken de bevindingen in het plan.
- In een noodgeval nemen we de technische kant over via Incident Response, op verzoek geborgd door een beveiligingsonderhoudscontract.
Veelgestelde vragen
Hoe uitgebreid moet een IT-noodplan zijn?
Zo kort mogelijk, zo uitgebreid als nodig. Voor webservers volstaan vaak enkele pagina's met contacten, systeemlijst, beslisregels en procedures. Belangrijker dan de omvang is dat het actueel is en in een noodgeval wordt gevonden.
Waar bewaar ik het noodplan?
Op minstens één plek die ook zonder werkende IT bereikbaar is, bijvoorbeeld uitgeprint of op een apart apparaat. Een plan dat alleen op de getroffen server of in het geblokkeerde bedrijfsnetwerk staat, helpt in een noodgeval niet.
Hoe vaak moet het plan worden gecontroleerd?
Minstens eenmaal per jaar en na elke ingrijpende wijziging, zoals een wisseling van hostingprovider of nieuwe software. Zinvol is een korte oefening waarin een scenario wordt doorgespeeld.
Zijn er sjablonen van het BSI?
Het BSI (de Duitse federale dienst voor informatiebeveiliging) behandelt noodbeheer in het kader van de IT-Grundschutz en in BSI-Standard 200-4 over business continuity management. Die zijn geschikt als kader; voor webservers loont een beknopte, praktijkgerichte versie.