Webbeveiliging: de Basis voor het MKB

De meest gehoorde reactie van mkb-ondernemers is dat niemand de moeite zou nemen hen aan te vallen. Het is een redelijke gedachte en het begrijpt verkeerd hoe dit werkt. Bijna niets is gericht. Bots crawlen het hele internet op zoek naar bekende zwakke plekken, en die controleren niet eerst hoe groot je bedrijf is.

Dit is de korte lijst van wat er echt toe doet, op volgorde van belang.

Houd dingen bijgewerkt

Dit is verreweg de grootste oorzaak van gekraakte mkb-websites. Een kwetsbaarheid wordt bekendgemaakt, er komt een patch, en binnen dagen scannen geautomatiseerde tools naar sites die hem niet hebben toegepast. Het venster tussen bekendmaking en massale uitbuiting is vaak in uren te meten.

Draait je site op een CMS met plug-ins, dan is dit doorlopend werk, geen eenmalige klus. Iemand moet updates toepassen, en iemand moet daarna controleren of de site nog werkt. Doet niemand dat, dan heb je geen onderhouden website — je hebt een aftelklok.

Het is het vermelden waard dat dit het sterkste praktische argument is voor een kleinere technische voetafdruk. Elke plug-in is een extra leverancier wiens beveiligingspraktijk je hebt geërfd. Een site met vier plug-ins heeft een veel kleiner aanvalsoppervlak dan een met dertig, en die dertig maken hem meestal niet dertig plug-ins beter.

Doe de basis één keer goed

Overal HTTPS. Gratis certificaten zijn al tien jaar standaard. Stuur al het HTTP-verkeer door, en zet HSTS aan zodat browsers de onveilige versie niet eens proberen.

Echte wachtwoorden en tweefactorauthenticatie op elk beheeraccount, het hostingpaneel, de domeinregistrar en het e-mailaccount dat eraan hangt. Registrar en e-mail tellen zwaarder dan mensen denken: wie je e-mail beheerst, kan de rest resetten.

Zo min mogelijk rechten. Wie blogberichten schrijft heeft geen beheerdersaccount nodig. De meeste inbraken schalen op via een te ruim account van iemand die twee jaar geleden vertrok. Loop de gebruikerslijst na; je vindt mensen.

Back-ups die je echt hebt teruggezet. Een ongeteste back-up is een geloof, geen plan. Automatisch, buiten de deur, en minstens één keer teruggezet op een testomgeving zodat je weet dat het werkt en hoe lang het duurt.

Beveiligingsheaders

Een handvol HTTP-headers kost niets en sluit hele categorieën aanvallen af. Grofweg op waarde:

Content-Security-Policy — bepaalt welke scripts mogen draaien. De krachtigste van het stel en de lastigste om goed te krijgen, maar het maakt van een script-injectie een geblokkeerd verzoek in plaats van een ramp.
Strict-Transport-Security — dwingt HTTPS af.
X-Content-Type-Options: nosniff — voorkomt dat de browser bestandstypen gaat raden.
Referrer-Policy — voorkomt dat volledige URL's naar derden lekken.
X-Frame-Options of een CSP frame-ancestors-regel — voorkomt dat je site in andermans frame wordt gezet.

Je controleert die van jou in seconden met een van de gratis headerscanners. De meeste mkb-sites scoren slecht en zijn in een middag te repareren.

De applicatie zelf

Vier dingen die de meeste echte lekken in maatwerkcode veroorzaken:

Valideer invoer op de server. Validatie in de browser is voor de gebruikerservaring. Alles wat de server bereikt moet daar opnieuw gecontroleerd worden, want een aanvaller gebruikt jouw formulier niet.

Gebruik geparametriseerde database-queries. Bouw nooit SQL door strings aan elkaar te plakken. Dit is een opgelost probleem, en elk modern framework en elke ORM doet het voor je tenzij je je best doet.

Escape uitvoer. Alles wat een gebruiker heeft getypt en weer wordt getoond moet worden ge-escaped, anders heb je cross-site scripting. React en vergelijkbare frameworks doen dit standaard, en daarom klinken de gevaarlijke uitzonderingen ook gevaarlijk.

Beperk de snelheid van alles wat iets kost. Inlogpogingen, contactformulieren, wachtwoordresets, API-endpoints. Zonder limiet is je contactformulier een gratis spamdoorgeefluik en je login een gratis brute-force-doelwit.

Behandel persoonsgegevens als een risico

De veiligste data is data die je niet hebt. Elk veld dat je verzamelt is iets dat je moet beveiligen, verantwoorden en uiteindelijk verwijderen. Minder opslaan verkleint de schade van een lek en, in de EU, wat je zou moeten melden.

Daarover: in Nederland gaat een meldingsplichtig lek zonder onnodige vertraging naar de Autoriteit Persoonsgegevens, in beginsel binnen 72 uur. Bepaal vandaag wie die afweging maakt, want 72 uur is kort als je ook nog moet uitzoeken wie je moet bellen.

Wat je deze week doet

Een realistische lijst voor een klein bedrijf:

Controleer of elk beheeraccount tweefactorauthenticatie heeft. Begin bij de domeinregistrar.
Verwijder accounts van mensen die niet meer bij je werken.
Draai een gratis headerscan en repareer wat ontbreekt.
Bevestig dat iemand daadwerkelijk updates toepast, en regel het zo niet.
Zet je back-up terug op een testomgeving. Lukt dat niet, dan heb je geen back-ups.
Tel de plug-ins en koppelingen. Haal weg wat je niet gebruikt.

Realistisch blijven

Je gaat geen fort bouwen en dat hoeft ook niet. Vrijwel alle aanvallen op mkb-sites zijn opportunistisch en geautomatiseerd, en ze trekken verder zodra de makkelijke ingang dicht is. Gepatchte software, tweefactorauthenticatie, verstandige headers, echte back-ups en een klein aanvalsoppervlak brengen je langs bijna alles.

Wat bedrijven pijn doet is geen verfijning. Het is een plug-in die sinds 2023 niet is bijgewerkt en een beheerdersaccount van een oud-medewerker.