In gesprekken over beveiliging komen steeds dezelfde zinnen terug. Ze zijn niet dom of naïef; ze klinken logisch, en dat is precies waarom ze standhouden. Het probleem is dat ze de aandacht wegtrekken van de maatregelen die er wél toe doen.
Hieronder vijf mythes over website beveiliging die wij regelmatig tegenkomen, met per stuk waarom de redenering plausibel is en waar hij misgaat. Dit is een opiniestuk, geen technisch handboek. U mag het er oneens mee zijn, maar toets het dan wel aan uw eigen situatie.
Mythe 1: “Onze site is te klein om interessant te zijn”
Dit is verreweg de meest gehoorde. De redenering: wij zijn een installatiebedrijf met acht man, er staat niets waardevols op onze site, waarom zou iemand de moeite nemen?
De aanname klopt alleen als een mens u zou uitkiezen. Dat gebeurt zelden. Het overgrote deel van de aanvallen komt van scripts die miljoenen adressen aflopen en per site één vraag stellen: draait hier een versie met een bekend lek? Uw bedrijfsgrootte, uw omzet en uw sector komen in die vraag niet voor.
En het idee dat er “niets waardevols” op staat, klopt bijna nooit. Uw site is waardevol als middel: om spam te versturen vanaf een schoon domein, om links te plaatsen naar goksites, om bezoekers door te sturen, om andere sites aan te vallen, of simpelweg om rekenkracht te gebruiken. De waarde zit in het draaien, niet in de inhoud.
Wat wél waar is aan deze mythe: kleine sites zijn zelden doelwit van gerichte aanvallen. U hoeft zich geen zorgen te maken over iemand die dagen besteedt aan het kraken van juist uw site. U moet zich zorgen maken over de geautomatiseerde onderkant, en die is met basale hygiëne grotendeels af te weren.
Mythe 2: “Wij hebben SSL, dus de site is beveiligd”
Het slotje in de adresbalk heeft veel verwarring gesticht. Voor veel ondernemers is dat hét symbool van beveiliging geworden, mede doordat browsers sites zonder certificaat als “niet veilig” bestempelen.
Wat SSL doet, is het verkeer tussen de browser en de server versleutelen. Iemand die het netwerkverkeer onderschept, kan dan niet meelezen. Dat is belangrijk voor formulieren en inloggegevens en het is bovendien nodig voor een fatsoenlijke vindbaarheid. Wat het niet doet: het beschermt uw site niet tegen inbraak. Een gehackte site met een geldig certificaat verstuurt malware over een keurig versleutelde verbinding.
Sterker nog: phishingpagina’s hebben tegenwoordig vrijwel altijd een geldig certificaat. Het slotje zegt iets over de verbinding, niets over de betrouwbaarheid van wat er aan de andere kant staat. Beschouw SSL als een gesloten envelop, niet als een slot op uw voordeur.
Mythe 3: “Wij hebben een beveiligingsplugin geïnstalleerd”
Een beveiligingsplugin is nuttig. Hij begrenst inlogpogingen, scant op bekende malware, meldt gewijzigde bestanden en blokkeert een deel van het kwaadaardige verkeer. Voor veel sites is het een verstandige toevoeging.
Maar een plugin is geen strategie. Wat wij in de praktijk zien: een site met een uitgebreide beveiligingsplugin, waarvan alle meldingen naar een e-mailadres gaan dat niemand leest, terwijl WordPress zelf acht maanden achterloopt. De plugin waarschuwde netjes. Er was alleen niemand die luisterde.
Er is een tweede probleem. Een beveiligingsplugin draait binnen WordPress en wordt dus pas actief nadat WordPress is opgestart. Kwetsbaarheden die eerder in de keten zitten, of die de plugin zelf raken, ontsnappen daaraan. Filtering vóór uw site, op DNS- of serverniveau, vangt een categorie aanvallen die een plugin per definitie mist.
De kern: beveiliging is werk, geen product. Updates uitvoeren, back-ups controleren, meldingen lezen en accounts opruimen. Een plugin ondersteunt dat werk, hij vervangt het niet. Wat er dan wél in welke volgorde moet gebeuren, staat in onze beveiligingschecklist op volgorde van belang.
Mythe 4: “Onze hostingpartij regelt dat”
Deze mythe leeft omdat hostingpartijen inderdaad veel doen. Zij beveiligen de server, houden het besturingssysteem bij, filteren aanvallen op netwerkniveau en maken vaak back-ups. Dat is geen kleinigheid.
Alleen loopt de scheidslijn ergens anders dan mensen denken. De hostingpartij is verantwoordelijk voor de omgeving; u bent verantwoordelijk voor wat u erin zet. Een verouderde plugin, een zwak wachtwoord van een redacteur, een thema uit een dubieuze bron: dat valt buiten hun bereik. Bij vrijwel elke hostingpartij staat dat ook gewoon in de voorwaarden.
Ook de back-up verdient een kritische blik. Standaardback-ups gaan vaak zeven tot dertig dagen terug en staan op dezelfde infrastructuur. Bij een besmetting die zes weken oud is, of bij een probleem dat de hele server raakt, heeft u er weinig aan. Vraag drie dingen na: hoe ver gaan ze terug, waar staan ze fysiek, en wat kost het om er een terug te laten zetten.
Mythe 5: “Als er iets gebeurt, zetten we gewoon een back-up terug”
Deze klinkt het verstandigst en is misschien wel de gevaarlijkste, want hij geeft mensen een excuus om de rest te laten liggen.
Er zitten drie gaten in. Ten eerste: een back-up terugzetten haalt de besmetting weg, maar niet de ingang. Was het lek er al voor de datum van uw back-up, dan zet u de kwetsbaarheid netjes mee terug en bent u binnen weken opnieuw besmet. Ten tweede: u weet vaak niet wanneer het begon. Besmettingen die er zes weken zitten voordat iemand ze opmerkt, zijn geen uitzondering. Ten derde, en dat weegt vooral bij webshops: terugzetten betekent alles kwijtraken wat er sindsdien is gebeurd. Bestellingen, klantaccounts, voorraadmutaties, formulierinzendingen.
Daar komt bij dat back-ups die nooit zijn getest, geregeld niet blijken te werken. Een onvolledige database, een export die halverwege afbrak, een bestandsformaat dat de nieuwe server niet aankan. De enige manier om te weten of uw back-up werkt, is hem een keer terugzetten op een testomgeving.
Back-ups zijn onmisbaar, laat daar geen misverstand over bestaan. Maar ze zijn een schadebeperker, geen beveiliging. En bij een besmetting is de vraag “hoe lang stond het er al” vaak veel duurder dan de reparatie zelf, zoals wij hebben uitgewerkt in het artikel over de kosten van hackherstel.
Wat er dan wel toe doet
Als u van dit hele stuk één ding meeneemt: beveiliging is geen aankoop maar een gewoonte. Bijwerken op een vast moment, back-ups die buiten de server staan en getest zijn, unieke wachtwoorden met tweestapsverificatie, zo min mogelijk beheerders, en iemand die de meldingen daadwerkelijk leest.
Dat laatste is in de praktijk het struikelblok. Niet omdat het moeilijk is, maar omdat het werk is dat nooit urgent voelt tot het te laat is. Wilt u het niet zelf bijhouden, dan is uitbesteden een reële optie; bij ons zit dit in de doorlopende beveiliging, inclusief een maandrapport zodat u kunt zien dat het gebeurd is. Doet u het zelf, zet dan in elk geval een terugkerende afspraak in uw agenda. Een uur per maand is genoeg om de meeste ellende voor te zijn.
