Beveiligingslek in Exchange, Citrix of SharePoint

Waarom grote beveiligingslekken gevaarlijk zijn voor het mkb

Als er in het nieuws een groot beveiligingslek voorbijkomt – bijvoorbeeld in e-mailservers zoals Exchange, in remote-oplossingen zoals Citrix of in samenwerkingsplatformen zoals SharePoint – lijkt dat soms een ver-van-je-bed-show. Maar juist het mkb maakt veel gebruik van dit soort standaardproducten. Dat maakt deze lekken interessant voor cybercriminelen: met één kwetsbaarheid kunnen ze in één klap heel veel bedrijven raken.

De gevolgen voor een mkb-bedrijf kunnen groot zijn:

• Datalek: klantgegevens, offertes, contracten en mailboxen liggen op straat.
• Stilstand: systemen moeten uit voorzorg uit, medewerkers kunnen niet werken.
• Ransomware: aanvallers gebruiken het lek om malware te plaatsen en bestanden te versleutelen.
• Reputatieschade: klanten gaan zich afvragen hoe veilig hun gegevens bij jou zijn.

Je hebt geen invloed op het feit dát er lekken worden ontdekt. Maar je hebt wél invloed op hoe je organisatie daarop reageert. Dit artikel helpt je om dat proces gestructureerd in te richten.

Wat is een groot beveiligingslek precies?

Bij een groot beveiligingslek (vaak aangeduid als “kritieke kwetsbaarheid”) blijkt er een fout in software te zitten waardoor een aanvaller bijvoorbeeld:

• zonder geldige inloggegevens toegang kan krijgen (bijvoorbeeld via een kwetsbare webinterface);
• zijn rechten kan verhogen tot administrator;
• op afstand code kan uitvoeren op de server;
• of data kan uitlezen, wijzigen of verwijderen.

Bij Exchange-, Citrix- en SharePoint-lekken zag je telkens hetzelfde patroon:

• De leverancier maakt bekend dat er een ernstig lek zit in een veelgebruikt product.
• Er komt een beveiligingsupdate (patch) beschikbaar.
• Korte tijd later verschijnen de eerste geautomatiseerde tools waarmee aanvallers het internet afzoeken naar systemen die nog niet zijn bijgewerkt.

Het verschil tussen wel of niet geraakt worden, zit vaak in de manier waarop je patchbeleid, monitoring, back-up en verantwoordelijkheden</strong zijn geregeld.

Stap 1: Weet welke systemen je hebt en waar ze draaien

Je kunt pas reageren op een kwetsbaarheid als je weet of je het getroffen product überhaupt gebruikt. Dat klinkt logisch, maar in de praktijk ontbreekt bij veel mkb-bedrijven een actueel overzicht.

Belangrijke vragen:

• Draaien er nog eigen servers (bijvoorbeeld Exchange of een eigen fileserver), of is alles al naar de cloud verhuisd?
• Wordt remote toegang geregeld via een oplossing als Citrix, Remote Desktop of VPN?
• Gebruik je SharePoint of andere webapplicaties die vanaf internet bereikbaar zijn?
• Staan er nog “vergeten systemen” ergens in een hoekje te draaien (oude testserver, oude webapplicatie, NAS)?

Een goede eerste stap is een actuele IT-inventarisatie:

• Welke servers, applicaties en diensten gebruik je?
• Welke versies draaien er?
• Waar staan ze (on-premise, datacenter, cloud)?
• Wie is eigenaar van welke applicatie (intern of extern)?

Hoe beter dit overzicht, hoe sneller je bij een nieuw lek kunt zeggen: “dit raakt ons wel” of “dit raakt ons niet”. Dat scheelt enorm in paniek, tijd en fouten.

Stap 2: Een strak patchbeleid en change management

Zodra een leverancier een lek meldt, komt er meestal een patch of beveiligingsupdate beschikbaar. De kunst is om die update snel genoeg uit te rollen, zonder je hele bedrijf plat te leggen.

Wat hoort er in een goed patchbeleid?

• Classificatie van systemen: welke systemen zijn kritisch (bijvoorbeeld e-mail, ERP, boekhouding)? Die krijgen hogere prioriteit bij patchen.
• Vaste patchmomenten: bijvoorbeeld maandelijks voor reguliere updates.
• Procedure voor spoedpatches: als er een groot lek is (zoals bij Exchange, Citrix of SharePoint), moet je kunnen afwijken van de normale planning.
• Testomgeving of testrichtlijn: waar mogelijk eerst testen, of in ieder geval een duidelijk rollback-plan hebben.
• Documentatie: vastleggen wanneer wat is bijgewerkt, door wie en met welk resultaat.

Bij grote beveiligingslekken geldt vaak: niet patchen is riskanter dan wél patchen. Zeker als het om systemen gaat die vanaf internet bereikbaar zijn. Wachten tot het “rustiger wordt” is precies wat aanvallers nodig hebben.

Change management in het mkb

Change management klinkt groot en enterprise-achtig, maar in het mkb kun je het pragmatisch houden:

• Voor elke grotere wijziging (zoals een beveiligingspatch op een server):
  • wanneer wordt de wijziging uitgevoerd;
  • welke systemen zijn geraakt;
  • wat is het verwachte effect voor gebruikers;
  • wat doe je als het misgaat (rollback-plan).

Als je dit proces helder hebt, kun je bij een nieuw lek veel sneller schakelen.

Stap 3: Monitoring, logging en EDR

Zelfs als je snel patcht, wil je weten of er misschien al misbruik is gemaakt van een kwetsbaarheid. Daarvoor heb je goede monitoring, logging en Endpoint Detection & Response (EDR) nodig.

Monitoring en logging

Belangrijke onderdelen:

• Logbestanden van servers, applicaties en firewall worden bewaard en centraal verzameld.
• Er is aandacht voor verdacht gedrag, zoals:
  • aanmeldpogingen van vreemde locaties of op vreemde tijden;
  • plotseling veel mislukte inlogpogingen;
  • onverwachte wijzigingen in configuraties of rechten.
• Bij kritieke systemen worden alerts ingesteld, zodat iemand een melding krijgt als er iets verdachts gebeurt.

Wat doet EDR?

Traditionele antivirus kijkt vooral naar bekende virussen. EDR-oplossingen gaan een stap verder en letten op gedrag. Bijvoorbeeld:

• een proces dat ineens heel veel bestanden versleutelt;
• onverwachte verbindingen naar command&control-servers op internet;
• tools die typisch zijn voor een aanvaller (zoals bepaalde scripts of scanners).

Als er misbruik wordt gemaakt van een lek in bijvoorbeeld Exchange, Citrix of SharePoint, zie je dat vaak terug in dit soort verdachte activiteiten. Met EDR kun je sneller constateren: “hier is iets niet in de haak”. In veel gevallen kan EDR een endpoint automatisch isoleren van het netwerk om verdere schade te beperken.

Stap 4: Back-up en herstelplan (als het toch misgaat)

Ook met goed patchbeleid en EDR blijft er altijd een risico over. Daarom is een solide back-up en herstelplan onmisbaar.

Ken je RPO en RTO

• RPO (Recovery Point Objective): hoeveel data mag je maximaal verliezen? Bijvoorbeeld: “we accepteren maximaal één uur dataverlies”.
• RTO (Recovery Time Objective): hoe snel moeten systemen weer draaien na een incident? Bijvoorbeeld: “e-mail moet binnen vier uur weer online zijn”.

Bij het ontwerp van je back-upstrategie hou je hiermee rekening. Dat bepaalt bijvoorbeeld:

• hoe vaak er back-ups worden gemaakt;
• waar ze worden opgeslagen (on-premise, cloud, combinatie);
• of er een offline of immutable back-up is die niet zomaar overschreven kan worden door ransomware.

Test je back-ups regelmatig

Een back-up waar nooit op getest wordt, is in feite een gok. Plan daarom regelmatig hersteltests:

• kan een volledige server of applicatie worden teruggezet;
• hoe lang duurt dat in de praktijk;
• kloppen rechten en instellingen nog na een herstelactie.

Bij grote beveiligingslekken zie je soms dat bedrijven uit voorzorg systemen uitzetten of terugrollen naar een eerdere back-up. Dat lukt alleen soepel als het herstelplan vooraf is doordacht.

Stap 5: Rollen, verantwoordelijkheden en communicatie

Bij een groot beveiligingslek is er vaak tijdsdruk en onzekerheid. Wie neemt dan de leiding? Wie besluit of een systeem tijdelijk uit moet? Wie praat er met leveranciers, en wie met de directie?

Verantwoordelijkheden binnen de organisatie

Het helpt als je dit alvast hebt vastgelegd:

• Technische verantwoordelijkheid: wie beoordeelt de technische impact en stuurt beheer of leveranciers aan?
• Besluitvorming: wie mag besluiten om systemen (tijdelijk) uit te schakelen, updates versneld uit te rollen of extra maatregelen te nemen?
• Communicatie intern: wie informeert medewerkers over eventuele verstoringen, tijdelijke maatregelen en wat er van hen verwacht wordt?
• Communicatie extern: als er sprake is van een datalek, wie onderhoudt contact met klanten, partners en – indien nodig – de Autoriteit Persoonsgegevens?

Als deze rollen duidelijk zijn, voorkom je dat iedereen door elkaar gaat praten of dat er juist helemaal niet wordt besloten.

De rol van een IT-partner bij grote beveiligingslekken

Voor veel mkb-bedrijven is het niet haalbaar om alle securitykennis zelf in huis te hebben. Een goede IT-partner kan dan het verschil maken tussen paniekreactie en een gecontroleerde aanpak.

Een IT-partner kan onder meer helpen bij:

• het opstellen en uitvoeren van een patchbeleid;
• het inrichten van monitoring, logging en EDR op servers en werkplekken;
• het ontwerpen en beheren van een back-up en herstelstrategie;
• het maken van een incident response-plan voor als er ondanks alles toch iets misgaat;
• het vertalen van technische adviezen naar duidelijke stappen voor directie en medewerkers.

Bij grote lekken in bijvoorbeeld Exchange, Citrix of SharePoint is het prettig als je niet op dat moment nog op zoek hoeft naar hulp, maar al een partner hebt die jouw omgeving kent en snel kan handelen.

Checklist: ben jij klaar voor het volgende lek?

Tot slot een korte checklist om te bepalen hoe goed je voorbereid bent op het volgende grote beveiligingslek:

• We hebben een actuele inventarisatie van onze systemen (servers, applicaties, cloud).
• We weten of we producten gebruiken zoals Exchange, Citrix, SharePoint of vergelijkbare oplossingen.
• Er is een patchbeleid met vaste momenten én een procedure voor spoedpatches.
• We hebben monitoring en logging ingericht op kritieke systemen.
• Op werkplekken en servers draait een moderne EDR-oplossing.
• Onze back-up wordt regelmatig getest en bevat ook een variant die niet zomaar door ransomware kan worden versleuteld.
• Rollen en verantwoordelijkheden bij grote beveiligingslekken zijn vastgelegd en bekend.
• We hebben een IT-partner die ons helpt bij het beoordelen en afhandelen van grote lekken.

Kun je veel van deze punten met “ja” beantwoorden? Dan is de kans een stuk groter dat het volgende grote beveiligingslek voor jou vooral een georganiseerde werkdag wordt, in plaats van een crisissituatie.