Een beveiligingsincident en een technische storing scheiden

De eerste regel: schrijf op wat je ziet, niet wat je denkt dat de reden is. 'De site geeft een foutpagina' is een observatie. 'De hosting ligt eruit' is een aanname. Maak een logboek met vier kolommen: tijdstip, wie het zag, wat precies zichtbaar was, en hoe zeker dat is.

Leg daarnaast apart een lijst van onbekenden vast. Voorbeelden: wanneer begon het probleem precies, is het voor iedereen zichtbaar of alleen intern, is er recent iets gewijzigd (update, plug-in, betaalmodule, DNS)? Een onbekende die je niet kunt invullen is geen reden tot paniek, maar wel een reden om niet te geruststellen.

Neem screenshots met zichtbare datum en tijd, kopieer exacte foutmeldingen en noteer welke apparaten, netwerken en accounts betrokken zijn. Pas niets aan voordat je dit hebt vastgelegd, behalve wat nodig is om directe schade te beperken.

Geen enkel signaal is op zichzelf bewijs. Het gaat om de combinatie. Gebruik de tabel als sorteerhulp, niet als oordeel.

Merk op dat een kaper ook een storing kan veroorzaken, en dat een storing ook verdacht gedrag kan nabootsen. Daarom blijft de status 'onbekend' een geldige uitkomst.

1. Leg vast: tijdstip, observaties, screenshots, foutmeldingen. Eén persoon houdt het logboek bij.
2. Bepaal het bereik: werkt de site vanaf een ander netwerk en apparaat? Geldt het voor één pagina, één functie of alles?
3. Controleer recente wijzigingen: updates, nieuwe extensies, wijzigingen bij je domein of hosting, personeelswissels met toegang.
4. Controleer accounttoegang: wie heeft beheerrechten, zijn er onbekende gebruikers, is tweestapsverificatie aan? Google beschrijft dat tweestapsverificatie een extra beveiligingslaag toevoegt voor het geval een wachtwoord wordt gestolen (Google-hulp over tweestapsverificatie). Gebruik je een werk- of schoolaccount, dan kan de beheerder bepalen wat mogelijk is.
5. Beperk schade zonder bewijs te wissen: is ongewenste toegang bekend (onbekende beheerder, verdachte sessie), trek die dan meteen in en wacht niet op een volledige inventaris. Maak een kopie of export van logs en instellingen zo snel mogelijk, maar hooguit parallel en niet als voorwaarde om de toegang te sluiten. Wijzig ook wachtwoorden van betrokken accounts.
6. Vraag de hostingpartij of ontwikkelaar om serverlogs en een statusbevestiging, schriftelijk.
7. Beslis opschaling met het beslisblad uit de volgende sectie.

Controleer in je eigen hosting- of beheeromgeving waar logs en gebruikersoverzichten staan. Schermnamen en rechten verschillen per leverancier en kunnen wijzigen.

Gebruik deze vragen als vaste checklist. Hoe meer ja-antwoorden bij de tweede groep, hoe sterker de reden om extern deskundige hulp in te schakelen.

• Groep A, waarschijnlijk technisch: viel het probleem samen met een eigen wijziging? Meldt de leverancier een storing? Verdwijnt het na terugdraaien? Zijn er geen onbekende gebruikers, bestanden of inlogmeldingen?
• Groep B, onderzoek als mogelijk incident: is er inhoud die niemand van jullie plaatste? Zijn er onbekende beheerders of gewijzigde instellingen? Kwamen er herstel- of inlogmeldingen die niemand aanvroeg? Worden klantgegevens of betalingen mogelijk geraakt?

Beslisregel: één duidelijk signaal uit groep B is genoeg om te behandelen als mogelijk incident tot het tegendeel onderbouwd is. Alleen groep A zonder onbekenden betekent 'storing waarschijnlijk', nooit 'veiligheid bewezen'.

Gaat het mogelijk om persoonsgegevens, dan kunnen er meldingsverplichtingen gelden. Dat is juridisch advies buiten deze gids; leg dit voor aan je functionaris gegevensbescherming of juridisch adviseur.

Dit is een verzonnen voorbeeld met alleen invoer en controles. Een winkel ziet op maandagochtend dat de bestelpagina een foutmelding toont. De eigenaar noteert: foutpagina zichtbaar om een bepaald tijdstip, alleen op de bestelpagina, de rest werkt. Onbekend: of er iets gewijzigd is, en of klanten ook de fout zien.

De eigenaar controleert de wijzigingsgeschiedenis en ziet dat een betaalextensie de dag ervoor is bijgewerkt. Hij draait die update terug in een testomgeving. Tegelijk loopt hij de gebruikerslijst na en kijkt of er onbekende beheerders of onverwachte herstelmails zijn.

Verwachte uitkomsten bij de controle: verdwijnt de fout na terugdraaien en zijn er geen onbekenden, dan noteer je 'waarschijnlijk technisch, oorzaak bevestigd door test'. Vind je wel een onbekende beheerder, dan trek je die toegang meteen in en wijzig je de wachtwoorden van betrokken accounts, terwijl je noteert en bewaart wat je zag (screenshots, exports), en schaal je op met het logboek als overdracht aan de externe specialist. Het logboek bevat dan: observaties, onbekenden, genomen acties met tijdstip en wie ze uitvoerde.

Communiceer naar klanten en collega's alleen wat bevestigd is. Gebruik formuleringen als 'we onderzoeken een storing en bekijken ook of er een veiligheidsoorzaak is' in plaats van 'er is niets aan de hand' of 'we zijn gehackt'. Beloof geen herstel binnen een bepaalde tijd als de oorzaak onbekend is.

Borg daarna de basis. MDN beschrijft websitebeveiliging als het beschermen van sites en gebruikers tegen schade door kwaadwillende derden, en noemt onder meer HTTPS, een Content Security Policy, beperkte cookietoegang en sterke authenticatie als kernpraktijken (MDN over webbeveiliging). Gebruik dat als checklist voor je ontwikkelaar, niet als bewijs dat je site veilig is.

Wil je ook weten welke zichtbare signalen je website publiek toont, kijk dan naar Marketing Scan. Een publieke scan meet enkel wat van buitenaf zichtbaar is en bewijst geen volledige technische beveiliging of een afgesloten incident.