Datalek: wat te doen in de eerste 72 uur, en hoe u het voorkomt

Maandagochtend. Iemand van support meldt dat er iets vreemds gebeurt in het systeem: verzoeken van onbekende adressen, accounts die niemand herkent, verkeer om drie uur ’s nachts. Binnen een paar uur is duidelijk dat iemand toegang heeft die hij niet zou mogen hebben.

Op dat moment vraagt niemand wie het was. Iedereen vraagt hetzelfde: wat heeft hij gezien?

De klok loopt vanaf het eerste moment

Als er persoonsgegevens van klanten of gebruikers in het spel zijn, eist de AVG dat u het datalek zonder onredelijke vertraging en uiterlijk 72 uur nadat u ervan op de hoogte bent gemeld bij de toezichthouder, in Nederland de Autoriteit Persoonsgegevens en in België de Gegevensbeschermingsautoriteit. Is het risico voor mensen hoog, dan moet u hen ook informeren.

Daarvoor hebt u het antwoord op drie vragen nodig: bij welke gegevens kon de aanvaller komen, bij welke is hij echt gekomen, en is hij er nog? Weet u dat niet, dan is het enige eerlijke uitgaan van het ergste: dat hij alles heeft gezien. En “alles” betekent al uw klanten aanschrijven.

Het verschil tussen “hij zag tien records” en “we moesten alle klanten informeren” wordt niet op de dag van de aanval beslist. Dat wordt maanden eerder beslist, in de manier waarop de applicatie is gebouwd.

De gaten die aanvallers echt gebruiken

Aanvallen op bedrijfsapplicaties zien er zelden uit als in de film. Meestal is er geen genialiteit voor nodig, alleen een deur die iemand open heeft laten staan:

• Wachtwoorden opgeslagen als gewone tekst. Wie bij de database komt, heeft alle wachtwoorden. En gebruikers gebruiken dezelfde wachtwoorden voor hun e-mail en bank, dus het lek stopt niet bij u. Wachtwoorden worden nooit opgeslagen, alleen een vingerafdruk ervan waaruit het wachtwoord niet terug te halen is.
• De applicatie stuurt meer dan het scherm toont. Het scherm toont een naam en een e-mailadres, maar op de achtergrond stuurt de applicatie het hele record mee, met velden die niemand ziet tenzij hij kijkt. Aanvallers kijken altijd.
• Andermans gegevens door een nummer te veranderen. Verander het ordernummer in het adres en u ziet de bestelling van iemand anders. Het klinkt te simpel om waar te zijn, maar gebrekkige toegangscontrole staat bovenaan de OWASP-lijst van de meest voorkomende beveiligingsrisico’s voor webapplicaties.
• Onbeperkt aantal pogingen. Zonder limiet kan een aanvaller duizenden keren per minuut wachtwoorden of nummers proberen, tot er iets lukt.
• Open zelfregistratie. Als iedereen zich kan registreren, hoeft de aanvaller niet in te breken. Hij maakt een account aan en kijkt wat een gebruiker van binnenuit allemaal kan ophalen.
• Beheer bereikbaar vanaf het hele internet. Een omgeving die vijf mensen in het bedrijf nodig hebben, en waar iedereen ter wereld bij kan.
• Logs waaruit niets blijkt. De applicatie legt fouten vast, maar niet wie wat heeft opgehaald. Op de dag van een incident is dat het verschil tussen een antwoord en een gok.

Als het gebeurt: de volgorde

1. Deur dichtToegang afsluiten, sleutels wijzigen
2. Vaststellen wat is gezienUit de logs, niet door te gokken
3. MeldenToezichthouder en, zo nodig, betrokkenen
4. Oorzaken oplossenZodat het niet opnieuw gebeurt

1. Doe de deur dicht. Sluit toegang af die niet zou mogen bestaan: blokkeer verdachte accounts, wijzig wachtwoorden, sleutels en tokens die de aanvaller gezien kan hebben. Snel, maar zonder sporen te wissen.
2. Stel vast wat er is gezien. Reconstrueer uit de logs wat de aanvaller deed, bij welke gegevens hij kwam en sinds wanneer. Deze stap bepaalt al het andere.
3. Meld het. Bij de toezichthouder binnen de termijn, en bij de betrokkenen als het risico hoog is. Duidelijk en eerlijk: wat er is gebeurd, welke gegevens zijn getroffen en wat u eraan doet.
4. Los de oorzaken op. Niet alleen het gat waardoor hij binnenkwam, maar alle vergelijkbare. Een aanvaller die één open deur vond, heeft de andere zeker ook geprobeerd.

10 vragen die u vandaag aan uw team kunt stellen

U hoeft niet te kunnen programmeren om ze te stellen. U moet alleen aandringen op een duidelijk antwoord:

1. Hoe slaan we de wachtwoorden van gebruikers op? Het goede antwoord: als vingerafdruk (hash), nooit als tekst.
2. Geeft de applicatie alleen de gegevens terug die het scherm echt nodig heeft?
3. Controleert de applicatie bij elk verzoek of deze gebruiker precies dit record mag zien?
4. Hoeveel inlogpogingen staan we toe voor een blokkade?
5. Kan iedereen zich registreren, en wat ziet hij daarna?
6. Wie kan bij het beheer, en vanaf waar?
7. Loggen beheerders in met tweestapsverificatie?
8. Als er morgen iemand binnenkomt, zouden we uit de logs weten wat hij zag? Hoe lang bewaren we logs?
9. Wanneer hebben we voor het laatst bibliotheken met bekende kwetsbaarheden bijgewerkt?
10. Wie is verantwoordelijk als er om drie uur ’s nachts een incident gebeurt, en weet die persoon wat hij moet doen?

Krijgt u op meer dan twee vragen “weet ik niet” of “zou goed moeten zitten”, dan weet u waar u moet beginnen.

Hoe wij werken

ProCoding is een .NET-studio uit Split, Kroatië. We doen beveiligingsreviews van bedrijfsapplicaties op .NET, ASP.NET Core, Blazor en SQL Server. We lopen de code, API’s, inloggen en rechten, logs en configuratie door, en u krijgt een lijst van gaten, gerangschikt naar risico, met een voorstel voor de oplossing van elk.

En als er al een incident is gebeurd, helpen we met het dringendste: de deur dichtdoen, uit de logs vaststellen wat de aanvaller zag en de oorzaken oplossen. De eerste stap is een gratis gesprek van 30 minuten.

Bronnen

• Algemene verordening gegevensbescherming (AVG), artikelen 33 en 34, EUR-Lex
• OWASP Top 10:2025, OWASP Foundation