Het PHP-lek van 21 oktober: het belang van veilig platformbeheer

Van eerste melding tot livegang in één dag

De dag begon met de aankondiging dat PHP om 16.00 uur een belangrijke beveiligingsupdate zou uitbrengen. De details over de lekken waren alleen al eerder naar buiten gekomen. Daardoor was het probleem bekend, terwijl de oplossing nog niet beschikbaar was. Rond het middaguur verscheen het nieuws ook bij de NOS. We begonnen direct met het informeren van klanten, terwijl ook onze telefoons al gingen. Klanten wilden weten wat dit voor hun platform betekende. Het eerlijke antwoord? Dat wist op dat moment nog niemand . Onze hostingpartij Upsun liet gelukkig snel weten dat ze de beveiligingsupdates automatisch zouden uitvoeren zodra deze beschikbaar waren. Tot die tijd lieten we klanten zelf kiezen of ze hun platform uit voorzorg wilden pauzeren. Om kwart voor drie stonden 29 productieplatforms op pauze. Vijftien platforms bleven bewust online, omdat klanten daar zelf voor kozen. Vanaf het begin van de avond voerde Upsun de updates uit, versie voor versie. Ons DevOps-team controleerde vervolgens ieder platform, zette het weer online en gaf het team een seintje. Dat team bracht daarna de klant op de hoogte. Rond tien uur 's avonds stonden de laatste platforms weer online.

Welke conclusies trekken we hieruit?

We gaven klanten zelf de keuze. Halverwege de dag konden we nog geen goed onderbouwd advies geven, omdat de technische details ontbraken. Dat hebben we dan ook eerlijk verteld. Iedere klant kreeg hetzelfde bericht, met daarin: “Omdat de technische details nog ontbreken, kunnen we op dit moment niet goed inschatten welk risico de kwetsbaarheden vormen.” Vervolgens vroegen we of ze hun platform uit voorzorg wilden pauzeren. Bij platforms met veel impact namen we ook direct telefonisch contact op.

Pauzeren werkt, maar heeft ook gevolgen. Een gepauzeerd platform is veilig, maar ook tijdelijk onbereikbaar. Voor een webshop of klantportaal kan dat direct omzetverlies betekenen. Een tijdelijke login voor het platform plaatsen was voor sommige klanten niet voldoende. Daarom kijken we nu per platform naar andere mogelijkheden, zoals een onderhoudspagina.

Verouderde PHP-versies vormen het grootste risico. Platforms met een actuele PHP-versie konden binnen een paar uur worden bijgewerkt. Voor oudere versies duurde dat langer. Draait je platform op PHP 7.3 of ouder? Dan kwam er helemaal geen beveiligingsupdate beschikbaar.

Waarom we PHP blijven gebruiken

PHP draait achter een groot deel van het internet. Daarom is het belangrijk dat beveiligingslekken goed worden onderzocht en opgelost. De twee kritieke lekken waren bij het PHP-team al maanden bekend. In die periode werd er gewerkt aan beveiligingsupdates. Toen de lekken op 21 oktober naar buiten kwamen, konden de updates worden uitgebracht voor alle actuele PHP-versies en drie oudere versies. De oplossingen waren dus niet in één dag gemaakt, maar al langer in voorbereiding. Dat laat zien wat de kracht is van een programmeertaal met een grote, actieve gemeenschap.

We bouwen onze platforms volgens strikte ontwikkelrichtlijnen. Maar een veilig platform bouwen is één ding. Het veilig houden vraagt om regelmatig onderhoud. Daarom adviseren we iedere klant om vier zaken goed te regelen:

• Een BIV-classificatie. Hoe belangrijk zijn beschikbaarheid, integriteit en vertrouwelijkheid voor jouw platform? Daarmee breng je in kaart hoe belangrijk het is dat je platform bereikbaar is, gegevens juist blijven en informatie goed beschermd wordt.

• Een passende SLA. Maak duidelijke afspraken over wie wat doet als er iets misgaat en hoe snel er gehandeld moet worden.

• Een vast onderhoudsinterval. Zorg dat je PHP-versie en andere softwareonderdelen (dependencies) regelmatig worden bijgewerkt.

• Periodieke securitychecks. Controleer je platform regelmatig op beveiligingsrisico's, zodat je zwakke plekken ontdekt voordat iemand anders dat doet.

Op 21 oktober zagen we hoe belangrijk dit is. Platforms die goed werden onderhouden, stonden dezelfde avond weer veilig online. Bij platforms met achterstallig onderhoud was extra werk nodig en bleef het risico langer bestaan.

Goed voorbereid als het erop aankomt

Een kritiek beveiligingslek is geen kwestie van of het gebeurt, maar wanneer. Het verschil zit niet in de programmeertaal, maar in hoe goed je bent voorbereid. Met actuele software, duidelijke afspraken en een team dat snel kan schakelen, kun je veel problemen voorkomen of beperken.

Benieuwd hoe jouw platform ervoor staat? Neem contact met ons op, dan kijken we samen naar je BIV-classificatie en het onderhoud van je platform.

Meer lezen? Digitale soevereiniteit en composable architecture: waarom flexibiliteit belangrijker wordt