Websitebeveiliging voor WordPress: voorkomen in plaats van repareren

Veel ondernemers denken bij een hack aan een persoon die doelbewust hun website uitkiest. In de praktijk gaat het bijna nooit zo. Het overgrote deel van de aanvallen op WordPress-websites wordt uitgevoerd door geautomatiseerde programma's, zogeheten bots, die dag en nacht het internet afspeuren naar bekende zwakke plekken. Zo'n bot weet niet wie u bent en heeft geen interesse in uw bedrijf. Hij zoekt alleen een deur die openstaat. Uw website hoeft dus niet groot of bekend te zijn om doelwit te worden; het volstaat dat hij bereikbaar is.

De meest voorkomende ingang is een verouderde plugin of een verouderd thema. Zodra een beveiligingslek in een populaire plugin bekend wordt, verschijnen binnen enkele uren scripts die alle websites met die plugin proberen te misbruiken. Wie de update dan een paar weken laat liggen, loopt een reëel risico. Hetzelfde geldt voor oudere WordPress-versies en voor plugins die door de maker niet meer worden bijgehouden.

Een tweede veelvoorkomende oorzaak is een zwak wachtwoord. Bots proberen eindeloos combinaties van gebruikersnamen en wachtwoorden op de inlogpagina. Een gebruikersnaam als 'admin' in combinatie met een wachtwoord dat ook op andere websites is gebruikt, is dan binnen korte tijd geraden. Wachtwoorden die ooit zijn uitgelekt bij een ander datalek circuleren in lijsten die aanvallers gewoon kunnen downloaden.

Daarnaast zien wij regelmatig problemen met zogenoemde nulled thema's en plugins: betaalde uitbreidingen die gratis van een obscure website zijn gedownload. Die bestanden bevatten opvallend vaak verborgen code die de aanvaller op afstand toegang geeft. De 'gratis' plugin blijkt dan achteraf de duurste aankoop die u ooit deed. Tot slot speelt gedeelde hosting een rol: staan er meerdere websites in dezelfde omgeving zonder goede scheiding, dan kan een besmetting van de ene website overslaan naar de andere.

Het geruststellende is dat al deze ingangen bekend zijn en goed af te sluiten zijn. Dat is precies waar structurele websitebeveiliging over gaat: niet één keer een slot kopen, maar ervoor zorgen dat de deuren dicht blijven terwijl de wereld om uw website heen verandert.

Een hack valt lang niet altijd meteen op. Aanvallers hebben er vaak belang bij dat u niets merkt, omdat zij uw website dan langer kunnen gebruiken voor spam, phishing of het verspreiden van malware. Toch zijn er signalen die u zelf kunt herkennen. Loop onderstaande punten eens langs; herkent u er één of meer, dan is nader onderzoek verstandig.

• Onbekende gebruikers. In het overzicht van gebruikers staan beheerdersaccounts die u niet hebt aangemaakt, soms met een onschuldig ogende naam.
• Vreemde pagina's of berichten. Uw website bevat opeens pagina's over medicijnen, goksites of merkkleding, vaak in een andere taal en niet zichtbaar in uw menu.
• Doorverwijzingen. Bezoekers die uw adres intypen, komen op een andere website terecht. Soms gebeurt dit alleen op mobiel of alleen via Google, zodat u het zelf niet ziet.
• Waarschuwingen in de browser of in Google. Chrome toont een rood scherm met de melding dat de website onveilig is, of in de zoekresultaten staat 'Deze site is mogelijk gehackt'.
• E-mail komt niet meer aan. Uw domein staat op een blacklist omdat er spam vanaf uw server is verstuurd. Klanten krijgen uw mail ineens in de spammap of helemaal niet.
• Onverklaarbare traagheid of hoog verbruik. De website wordt zonder duidelijke reden traag, of uw hostingpartij meldt dat u ineens veel meer dataverkeer of rekenkracht gebruikt.
• Gewijzigde bestanden. Bestanden in uw WordPress-installatie hebben een recente wijzigingsdatum terwijl u niets hebt aangepast.
• Uitgeschakelde beveiliging. Uw beveiligingsplugin is gedeactiveerd of verwijderd zonder dat iemand dat heeft gedaan.
• Meldingen van klanten. Klanten vertellen dat zij virusmeldingen krijgen of vreemde e-mails 'namens u' ontvangen.

Sommige signalen zijn subtiel. Een klassiek voorbeeld is de zogenoemde cloaking-hack: gewone bezoekers zien uw normale website, maar de zoekmachine krijgt een versie vol spamlinks te zien. U merkt dan pas iets als uw posities in Google instorten of als iemand u wijst op de vreemde zoekresultaten. Daarom controleren wij bij een beveiligingscheck ook hoe uw website eruitziet 'door de ogen van Google'.

Wat u zelf kunt doen: zoek in Google op site:uwdomein.nl en bekijk of er pagina's tussen staan die u niet kent. Controleer daarnaast de lijst met gebruikers in uw WordPress-beheer. Twijfelt u, dan kunt u altijd een gratis websitecheck aanvragen; wij kijken dan mee zonder dat u ergens aan vastzit.

Het woord firewall roept het beeld op van een muur waar niets doorheen komt. Dat beeld klopt maar half. Een firewall voor websites, ook wel web application firewall genoemd, is eerder een portier die elk verzoek aan uw website beoordeelt voordat het binnenkomt. Verzoeken die eruitzien als een bekende aanval worden geweigerd; gewone bezoekers merken er niets van.

Wat een goede firewall doet:

• Bekende aanvalspatronen herkennen en blokkeren, bijvoorbeeld pogingen om via een formulier code in uw database te schuiven.
• Verdachte IP-adressen weren, zoals adressen die eerder bij aanvallen zijn gebruikt of die in korte tijd honderden inlogpogingen doen.
• Toegang tot gevoelige bestanden en mappen beperken, zodat een bot niet zomaar uw configuratiebestand kan opvragen.
• Een deel van de overlast van bots wegnemen, waardoor uw server rustiger blijft en uw website sneller reageert.

Wat een firewall niet doet:

• Een lek in een verouderde plugin dichten. De firewall kan een bekende misbruikpoging tegenhouden, maar de zwakke plek blijft bestaan zolang de update niet is uitgevoerd.
• Een aanvaller stoppen die al binnen is. Is uw website eerder besmet geraakt, dan houdt de firewall dat niet tegen; daarvoor is opschoning nodig.
• Een zwak wachtwoord goedmaken. Als iemand uw wachtwoord kent, loopt hij gewoon door de voordeur naar binnen.
• Uw back-ups vervangen. Ook met een perfecte firewall wilt u terug kunnen naar een schone versie.

Een vaak gehoord misverstand is dat een firewallplugin de website 'veilig maakt' en dat updates daarna minder dringend zijn. Het tegendeel is waar: de firewall is het vangnet voor de periode tussen het bekend worden van een lek en het moment dat u de update installeert. Die periode wilt u zo kort mogelijk houden.

Wij werken met een firewall op twee niveaus. Op de server wordt het grofste verkeer al geweerd, zodat aanvallen uw WordPress-installatie niet eens bereiken. Binnen WordPress draait een tweede laag die specifieke aanvallen op plugins en thema's herkent. Beide lagen worden automatisch bijgewerkt met nieuwe aanvalspatronen, en wij controleren in het maandrapport wat er is geblokkeerd. Zo ziet u ook zwart op wit hoeveel pogingen er dagelijks op uw website worden gedaan; dat aantal verrast de meeste ondernemers.

Malware is een verzamelnaam voor schadelijke code die zonder uw medeweten op uw website is geplaatst. Dat kan een klein stukje code zijn dat bezoekers doorstuurt naar een andere website, een verborgen inlogmogelijkheid voor de aanvaller, een script dat spam verstuurt, of een programma dat de rekenkracht van uw server gebruikt om cryptomunten te delven. Een malwarescan zoekt systematisch naar zulke code.

Een goede scan bekijkt drie dingen. Ten eerste worden alle bestanden van WordPress, uw thema en uw plugins vergeleken met de originele versies. Elk bestand dat afwijkt, wordt gemarkeerd; een afwijking kan onschuldig zijn, maar is vaak het spoor van een besmetting. Ten tweede wordt gezocht naar bekende kwaadaardige patronen, zoals versleutelde code die zichzelf pas bij uitvoering ontcijfert. Ten derde wordt de database gecontroleerd, want ook daar kunnen aanvallers scripts verstoppen, bijvoorbeeld in de instellingen of in de inhoud van pagina's.

Belangrijk om te weten: een scan vanaf buiten, waarbij een dienst alleen uw openbare pagina's bekijkt, geeft een beperkt beeld. Zo'n scan ziet de doorverwijzing die een bezoeker krijgt, maar niet de verborgen achterdeur in een bestand dat nooit openbaar wordt geladen. Daarom combineren wij een externe scan met een scan vanaf de server zelf, waarbij elk bestand toegankelijk is.

Hoe vaak scannen? Bij onze abonnementen loopt een automatische scan dagelijks; bij een afwijking krijgt ons team direct een melding. Daarnaast doen wij na elke update een controle, omdat een update zelf ook een moment is waarop bestanden veranderen en een afwijking anders makkelijk verborgen blijft in de ruis. Wie geen abonnement heeft, kan kiezen voor een eenmalige beveiligingsbeurt waarin de website grondig wordt doorgelicht.

Wat u zelf kunt controleren: veel hostingpartijen bieden in het beheerpaneel een eenvoudige virusscanner. Die vangt zeker niet alles, maar een melding daar is altijd reden om verder te kijken. Ook Google Search Console geeft onder 'Beveiligingsproblemen' aan of Google iets verdachts heeft gezien op uw website. Het loont om dat scherm af en toe te openen, of te laten meenemen in uw maandelijkse onderhoudsronde.

De inlogpagina van WordPress is bij elke website op dezelfde plek te vinden en werkt overal hetzelfde. Daarmee is het voor bots een dankbaar doelwit. Op een gemiddelde Nederlandse bedrijfswebsite zien wij honderden tot duizenden mislukte inlogpogingen per week, allemaal geautomatiseerd. Zolang de wachtwoorden sterk zijn, richt dat geen schade aan, maar u wilt niet afhankelijk zijn van de discipline van iedereen die ooit een account heeft gekregen.

Daarom nemen wij een aantal maatregelen die samen de inlogpagina flink minder aantrekkelijk maken:

1. Beperken van inlogpogingen. Na een handvol mislukte pogingen wordt het IP-adres tijdelijk geblokkeerd. Een bot die duizend combinaties wil proberen, komt dan niet verder dan vijf.
2. Geen gebruikersnaam 'admin'. De helft van het werk van een aanvaller is het raden van de gebruikersnaam. Standaardnamen verwijderen wij; ook zorgen wij dat de gebruikersnaam niet uit uw website is af te leiden.
3. Tweestapsverificatie (2FA). Naast het wachtwoord is een code nodig van een app op uw telefoon, of via e-mail. Zelfs een uitgelekt wachtwoord is dan niet genoeg om binnen te komen. Dit is verreweg de meest effectieve maatregel en kost u per keer inloggen een paar seconden.
4. Sterk wachtwoordbeleid. Nieuwe wachtwoorden moeten een minimale lengte hebben; wij adviseren een wachtwoordmanager, zodat niemand hetzelfde wachtwoord op meerdere plekken hoeft te gebruiken.
5. Verbergen of beschermen van de inlogpagina. Een andere inlog-URL of een extra wachtwoord op serverniveau houdt de bulk van de bots buiten de deur voordat ze WordPress zelf bereiken.
6. Automatisch uitloggen. Sessies die lang open blijven staan op een gedeelde computer zijn een risico; na een periode van inactiviteit wordt de gebruiker uitgelogd.

Een vraag die wij vaak krijgen: is tweestapsverificatie niet lastig voor medewerkers die af en toe een bericht plaatsen? In de praktijk went het binnen een week. Wij richten het zo in dat vertrouwde apparaten voor een bepaalde periode worden onthouden, zodat niet bij elke handeling een code nodig is. Voor wie geen smartphone wil gebruiken, is een code per e-mail een prima alternatief.

Vergeet ook de andere toegangen niet. Naast WordPress heeft uw website een hostingpaneel, FTP-toegang en een databasebeheer. Die inloggegevens staan soms al jaren in een oude e-mail of bij een vorige webbouwer. Bij een beveiligingsbeurt vernieuwen wij deze wachtwoorden en zetten wij toegang die niet meer nodig is uit.

Het slotje in de adresbalk kent iedereen. Dat slotje betekent dat de verbinding tussen de bezoeker en uw website versleuteld is via SSL, tegenwoordig eigenlijk TLS genoemd. Vult iemand een contactformulier in of logt een klant in, dan kan niemand onderweg meelezen. Zonder dat slotje toont Chrome een waarschuwing 'Niet beveiligd', wat bezoekers afschrikt en wat Google meeweegt in de beoordeling van uw website.

Een certificaat installeren is tegenwoordig bij de meeste hostingpartijen gratis en eenvoudig. Toch gaat het regelmatig mis, en wel op drie manieren. Het certificaat verloopt zonder dat iemand het merkt, waardoor bezoekers ineens een rood scherm zien. Of de website is wel via https bereikbaar, maar de oude http-versie werkt ook nog, zodat bezoekers en zoekmachines twee versies zien. Of er staan nog onderdelen op de pagina, zoals een afbeelding of een lettertype, die via http worden geladen; het slotje verdwijnt dan of wordt grijs. Wij controleren deze drie punten bij elke website en zetten monitoring op de vervaldatum van het certificaat.

Beveiligingsheaders zijn minder bekend, maar minstens zo nuttig. Het zijn korte instructies die uw server meestuurt met elke pagina en die de browser van de bezoeker vertellen wat wel en niet mag. Een paar voorbeelden, vertaald naar gewone taal:

• 'Gebruik altijd de beveiligde verbinding' (HSTS). De browser onthoudt dat uw website alleen via https bereikbaar hoort te zijn en probeert het nooit meer via http.
• 'Laat deze pagina niet in een frame op een andere website tonen'. Dit voorkomt dat een kwaadwillende uw inlogpagina onzichtbaar over zijn eigen website heen legt om klikken te onderscheppen.
• 'Laad alleen scripts van deze bronnen' (Content Security Policy). Zelfs als er ergens een vreemd script in uw pagina belandt, weigert de browser het uit te voeren.
• 'Raad het bestandstype niet zelf'. Een klein maar effectief slot tegen bepaalde trucs met geüploade bestanden.

Deze headers zijn bij de meeste WordPress-websites niet ingesteld, simpelweg omdat niemand er ooit naar heeft gekeken. Ze kosten niets, hebben geen invloed op de snelheid en zijn met een goede configuratie in een uur geregeld. De Content Security Policy vraagt wel zorgvuldigheid: te streng ingesteld blokkeert hij bijvoorbeeld uw statistieken of uw chatwidget. Daarom testen wij elke header eerst in de rapportagestand voordat hij daadwerkelijk blokkeert.

Bij een beveiligingscheck vragen wij altijd om de lijst met gebruikers. Bijna elke website die een paar jaar bestaat, heeft daar verrassingen in zitten: de stagiair van drie jaar geleden, de vorige webbouwer, een marketingbureau waarvan de samenwerking allang is gestopt, en een account met de naam 'test'. Allemaal met beheerdersrechten. Elk van die accounts is een mogelijke ingang, zeker als het wachtwoord ooit is hergebruikt of gedeeld.

Goed gebruikersbeheer begint met een simpel principe: iedereen krijgt precies de rechten die nodig zijn voor zijn taak, en niets meer. WordPress kent daarvoor standaardrollen:

• Beheerder kan alles, inclusief plugins installeren en gebruikers aanmaken. Dit is nodig voor hooguit één of twee personen plus uw onderhoudspartij.
• Redacteur kan alle berichten en pagina's beheren, maar geen instellingen wijzigen. Geschikt voor de collega die de website inhoudelijk bijhoudt.
• Auteur kan eigen berichten schrijven en publiceren. Prima voor wie af en toe een blog plaatst.
• Winkelmanager (bij WooCommerce) beheert bestellingen en producten zonder toegang tot de rest.

Wat wij bij een beveiligingsbeurt doen: alle accounts doornemen met u, overbodige accounts verwijderen en de inhoud ervan overdragen aan een bestaande gebruiker, rollen terugbrengen naar wat nodig is, en voor alle overgebleven beheerders tweestapsverificatie inschakelen. Daarnaast zetten wij een melding aan: wordt er een nieuwe beheerder aangemaakt, dan krijgen u en ons team daar een e-mail van. Een aanvaller die zichzelf een account geeft, valt daardoor meteen op.

Een praktisch advies voor samenwerking met externe partijen: maak voor elk bureau een eigen account met een duidelijke naam, en verwijder het zodra de samenwerking stopt. Deel nooit uw eigen inloggegevens. Loopt er iets mis, dan is altijd terug te zien wie wat heeft gedaan. Dat is niet alleen prettig voor de beveiliging, maar ook voor de samenwerking.

Tot slot: ook u als eigenaar hoeft niet dagelijks met een beheerdersaccount te werken. Voor het plaatsen van een nieuwsbericht volstaat een redacteursaccount. Bewaar het beheerdersaccount voor de momenten waarop het echt nodig is. Mocht een wachtwoord dan toch ooit uitlekken, dan is de schade een stuk kleiner.

Alle voorgaande maatregelen verkleinen de kans op een hack. Geen enkele maatregel brengt die kans naar nul. Daarom is de belangrijkste vraag niet of u een hack kunt voorkomen, maar hoe snel u er weer bovenop bent als het toch gebeurt. Het antwoord daarop hangt bijna volledig af van de kwaliteit van uw back-ups.

Een bruikbare back-up voldoet aan een paar eisen die in de praktijk vaak niet gehaald worden:

• Volledig. Zowel de bestanden (thema, plugins, uploads) als de database. Veel hostingback-ups bevatten alleen bestanden, of alleen de database.
• Elders opgeslagen. Een back-up op dezelfde server als de website is geen back-up. Wordt de server gehackt of valt hij uit, dan bent u beide kwijt. Wij slaan back-ups versleuteld op binnen de EU, los van uw hosting.
• Met historie. Een hack wordt soms pas na weken ontdekt. Hebt u alleen de back-up van gisteren, dan zit de besmetting daar al in. Wij bewaren meerdere versies, zodat u terug kunt naar een moment van vóór de hack.
• Getest. Een back-up die nooit is teruggezet, is een aanname. Wij testen periodiek of een herstel daadwerkelijk lukt.
• Frequent genoeg. Voor een informatieve website is wekelijks vaak voldoende; voor een webshop of een website met dagelijkse wijzigingen wilt u dagelijkse back-ups.

Naast de vaste back-upcyclus maken wij vóór elke wijziging een extra back-up. Gaat een update mis of blijkt een plugin een conflict te veroorzaken, dan is de website binnen enkele minuten terug in de vorige staat. Voor u betekent dat: geen lange uitval en geen zenuwachtige middag.

Bij hackherstel is de back-up vaak het startpunt. Wij vergelijken de huidige website met een schone eerdere versie om precies te zien welke bestanden zijn toegevoegd of gewijzigd. Dat maakt de opschoning sneller en grondiger dan wanneer wij alleen kunnen afgaan op wat een scanner aanwijst. Wat u zelf kunt controleren: vraag uw hostingpartij eens wat er precies in de back-up zit, hoe lang deze bewaard blijft en hoe u een herstel aanvraagt. De antwoorden op die drie vragen zeggen veel over hoe goed u er voorstaat.

Is uw website gehackt, dan wilt u vooral weten wat er nu gaat gebeuren en hoe lang het duurt. Hieronder staat de volgorde die wij bij vrijwel elk hackherstel aanhouden. Bij een gemiddelde bedrijfswebsite is de website binnen één werkdag weer schoon en bereikbaar; de nazorg, zoals de herbeoordeling door Google, loopt daarna nog enkele dagen door.

1. Website tijdelijk offline of in onderhoudsstand. Zo voorkomen wij dat bezoekers besmet raken en dat de aanvaller door blijft werken terwijl wij bezig zijn. Bezoekers zien een nette melding dat de website even in onderhoud is.
2. Back-up van de huidige toestand. Ook een besmette website leggen wij eerst vast. Daarmee kunnen wij achteraf onderzoeken hoe de aanvaller is binnengekomen, en verliezen wij niets als tijdens de opschoning iets onverwachts gebeurt.
3. Analyse en opschoning. Wij vergelijken alle bestanden met de originele versies en met een schone back-up. Kwaadaardige code wordt verwijderd, gewijzigde kernbestanden worden vervangen door originele, verdachte bestanden in de uploadmap worden opgeruimd en de database wordt doorzocht op ingevoegde scripts en vreemde gebruikers.
4. Het lek dichten. Opschonen zonder de oorzaak weg te nemen is dweilen met de kraan open. Wij achterhalen de ingang, meestal een verouderde plugin, een zwak wachtwoord of een nulled thema, en verhelpen die. Alle plugins en thema's worden bijgewerkt; onveilige plugins vervangen wij door een veilig alternatief.
5. Wachtwoorden en sleutels vernieuwen. Alle wachtwoorden van WordPress, de database, FTP en het hostingpaneel worden vervangen. Ook de zogenoemde salts, de geheime sleutels waarmee WordPress inlogsessies beveiligt, worden opnieuw gegenereerd, zodat bestaande sessies van de aanvaller ongeldig worden.
6. Beveiliging aanscherpen. Firewall, beperking van inlogpogingen, tweestapsverificatie en beveiligingsheaders worden ingesteld, zodat dezelfde aanval niet nog eens slaagt.
7. Herbeoordeling aanvragen bij Google. Toont Google een waarschuwing bij uw website, dan dienen wij via Search Console een verzoek tot herbeoordeling in, met een beschrijving van wat er is gedaan. Google beoordeelt dit meestal binnen enkele dagen.
8. Verwijdering van blacklists. Staat uw domein of IP-adres op een spamlijst, dan vragen wij bij de betreffende lijsten verwijdering aan, zodat uw e-mail weer normaal aankomt.
9. Nacontrole. Enkele dagen na het herstel scannen wij opnieuw en controleren wij de logbestanden op nieuwe pogingen. Sommige aanvallers proberen het na een opschoning meteen weer.

Hackherstel bieden wij aan vanaf € 249. U ontvangt na afloop een verslag in gewoon Nederlands: wat er is gevonden, hoe de aanvaller is binnengekomen en wat er is gedaan om herhaling te voorkomen. Wilt u zeker weten dat het daarna ook zo blijft, dan is een abonnement met doorlopende beveiliging de logische vervolgstap; de kosten daarvan zijn een fractie van een tweede herstel.

De technische opschoning is vaak het overzichtelijke deel van een hack. De schade aan uw reputatie is lastiger te meten, maar kan langer doorwerken. Klanten die een virusmelding kregen bij het bezoeken van uw website, onthouden dat. Google onthoudt het ook: een website die als onveilig is gemarkeerd, verliest posities en krijgt die niet automatisch terug zodra het rode scherm weg is.

Herstel van uw reputatie verloopt langs vier sporen:

• Google en browsers. Na de herbeoordeling verdwijnt de waarschuwing, maar het kan dagen tot weken duren voordat de zoekresultaten weer normaal ogen. Wij controleren of de spampagina's die de aanvaller heeft aangemaakt uit de index verdwijnen, en vragen waar nodig verwijdering aan. Blijven er oude spamadressen in Google staan, dan sturen wij die netjes door naar een foutpagina, zodat Google ze opruimt.
• E-mail. Is uw domein gebruikt voor spam, dan is de afleverbaarheid van uw e-mail aangetast. Naast verwijdering van blacklists controleren wij de instellingen (SPF, DKIM en DMARC) die aan ontvangende mailservers bewijzen dat uw e-mail echt van u komt. Dat verkleint de kans dat u opnieuw in de spammap belandt.
• Klanten en relaties. Openheid werkt beter dan zwijgen. Een korte, eerlijke boodschap op uw website of in een nieuwsbrief, waarin u uitlegt wat er is gebeurd, dat het is opgelost en welke maatregelen zijn genomen, wekt meer vertrouwen dan een stilzwijgen dat iedereen doorziet. Wij helpen desgewenst met de formulering.
• Uw eigen gemoedsrust. Veel ondernemers durven na een hack hun website nauwelijks meer te vertrouwen. Doorlopende monitoring en een maandrapport waarin u ziet wat er is geblokkeerd en gecontroleerd, geven dat vertrouwen stap voor stap terug.

Een praktisch punt dat vaak wordt vergeten: controleer uw bedrijfsprofiel bij Google en uw vermeldingen op sociale media. Aanvallers wijzigen soms de websitelink in zulke profielen naar hun eigen website. Ook advertenties die naar uw website verwijzen, kunnen tijdens de hack zijn afgekeurd; die moeten opnieuw worden ingediend. Wij nemen deze punten mee in de nacontrole, zodat u niet weken later ontdekt dat een deel van uw verkeer nog steeds de verkeerde kant op ging.

Een hack is niet alleen een technisch probleem; het kan ook een datalek zijn in de zin van de AVG. Van een datalek is sprake wanneer persoonsgegevens verloren zijn gegaan of wanneer onbevoegden er toegang toe hebben gehad. Op een gewone bedrijfswebsite gaat het dan bijvoorbeeld om de gegevens uit contactformulieren, nieuwsbriefinschrijvingen, reacties of, bij een webshop, om klantaccounts en bestelgegevens. Ook een e-mailadres is een persoonsgegeven.

De hoofdregel is als volgt. Constateert u een datalek waarbij een risico bestaat voor de betrokken personen, dan moet u dit binnen 72 uur na ontdekking melden bij de Autoriteit Persoonsgegevens. Is het risico hoog, bijvoorbeeld omdat wachtwoorden, financiële gegevens of medische gegevens zijn ingezien, dan moet u ook de betrokken personen zelf informeren. Blijkt het risico verwaarloosbaar, bijvoorbeeld omdat de aanvaller alleen een spampagina heeft geplaatst en aantoonbaar geen toegang had tot gegevens, dan hoeft u niet te melden, maar u moet het incident wel intern vastleggen.

Die beoordeling is in de praktijk lastig, en dat is precies waar onze technische analyse helpt. In het verslag na een hackherstel beschrijven wij zo concreet mogelijk:

• Hoe en wanneer de aanvaller is binnengekomen.
• Tot welke onderdelen hij toegang had: alleen bestanden, of ook de database met persoonsgegevens.
• Of er aanwijzingen zijn dat gegevens zijn gekopieerd of verzonden.
• Welke maatregelen zijn genomen om herhaling te voorkomen.

Met dat verslag kunt u, eventueel samen met uw jurist of functionaris gegevensbescherming, onderbouwd beslissen of een melding nodig is en de melding zelf goed invullen. Wij geven geen juridisch advies, maar zorgen wel dat u de feiten hebt die voor die beslissing nodig zijn. De termijn van 72 uur begint te lopen op het moment dat u het lek ontdekt, niet op het moment dat de hack plaatsvond; snel handelen na ontdekking is dus belangrijk.

Ook zonder incident vraagt de AVG iets van u. U moet passende technische maatregelen nemen om persoonsgegevens te beschermen; updates, beveiligde verbindingen, toegangsbeheer en back-ups horen daarbij. En werkt u met een partij die toegang heeft tot uw website en dus tot persoonsgegevens, dan hoort daar een verwerkersovereenkomst bij. Die sluiten wij standaard met elke klant. Zo ligt vast wat wij wel en niet met uw gegevens doen, en kunt u dat bij een controle laten zien.

Een fysiotherapiepraktijk met drie vestigingen merkte op een maandagochtend dat hun website in Google werd getoond met de melding 'Deze site is mogelijk gehackt'. De website zelf zag er normaal uit. Toen wij op de server keken, bleek een verouderde plugin voor een fotogalerij de ingang te zijn geweest; het lek was drie weken eerder bekend geworden, de update was nooit uitgevoerd. De aanvaller had een verborgen map met enkele duizenden pagina's over gokwebsites aangemaakt, alleen zichtbaar voor zoekmachines, plus een extra beheerdersaccount met een onopvallende naam.

Het herstel verliep volgens het stappenplan: website in onderhoudsstand, back-up, opschoning aan de hand van een schone back-up van een maand eerder, verwijdering van de plugin en vervanging door een onderhouden alternatief, nieuwe wachtwoorden en salts, firewall en tweestapsverificatie ingesteld. Dezelfde dag was de website weer online. De herbeoordeling bij Google was na vier dagen goedgekeurd. Omdat het afsprakenformulier op de website gegevens naar een extern systeem stuurde en niet in de database bewaarde, kon in het verslag worden onderbouwd dat er geen persoonsgegevens waren ingezien. De praktijk legde het incident intern vast en hoefde geen melding te doen.

Wat dit voorbeeld illustreert, komt terug in een aantal misverstanden die wij vaak horen:

• 'Mijn website is te klein om interessant te zijn.' Bots maken geen onderscheid. Een kleine website met een verouderde plugin is voor een bot precies even interessant als een grote.
• 'Mijn hostingpartij regelt de beveiliging.' Uw hostingpartij beveiligt de server, niet uw WordPress-installatie, plugins en wachtwoorden. Dat is uw verantwoordelijkheid, of die van uw onderhoudspartij.
• 'Ik heb een beveiligingsplugin, dus het zit goed.' Een plugin is een onderdeel van beveiliging, geen vervanging van updates, back-ups en goed gebruikersbeheer.
• 'De website ziet er normaal uit, dus er is niets aan de hand.' Juist de schadelijkste hacks zijn onzichtbaar voor de eigenaar.
• 'Na het opschonen is het klaar.' Zonder het lek te dichten en de wachtwoorden te vernieuwen is de aanvaller binnen een week terug.
• 'Beveiliging is duur.' Doorlopende beveiliging zit in elk van onze abonnementen; een hackherstel plus de omzet die u misloopt, kost vrijwel altijd meer dan een jaar onderhoud.

Wilt u weten hoe uw website ervoor staat? Bekijk wat een abonnement kost of neem gerust contact met ons op; wij kijken graag met u mee, ook als u alleen een tweede mening wilt.