NCSC-oproep over MS Exchange: wake-up call

Dit artikel delen:

Afgelopen week deed het Nationaal Cyber Security Centrum (NCSC) een herhaalde oproep om Microsoft Exchange-servers te updaten. Veel servers blijken nog kwetsbaar voor misbruik. Lokale oplossingen zijn nu eenmaal lastiger te patchen dan in de cloud. Tijd voor uniforme policies op elk platform?

Ondanks eerdere oproepen van het NCSC zijn in veel organisaties de door Microsoft beschikbaar gestelde beveiligingsupdates niet geïnstalleerd. Het risico op misbruik is groot, zeker doordat criminelen drie aanvalstechnieken hebben: ProxyShell, ProxyOracle en ProxyToken. Door ze te combineren is het mogelijk om kwetsbare Exchange-servers op afstand over te nemen.

Laat dit een wake-up call zijn voor organisaties in alle sectoren, stelt Wim van Campen, vice president EMEA bij it-beveiligingsbedrijf Lookout. Volgens hem is het de verantwoordelijkheid van de organisaties zelf om deze kwetsbaarheden te patchen. 'En juist daarin schuilt het probleem. Als dit een cloud service was geweest, dan zouden de benodigde patches door de cloud provider geïmplementeerd worden.'

'It- en securityteams hebben een manier nodig om uniforme policies voor databescherming toe te passen op ieder systeem en platform, zowel on-premises als in de cloud. Op dit moment zijn er nog veel verschillen in de wijze waarop deze verschillende omgevingen worden beveiligd.' Volgens Van Campen kan dit een negatieve impact hebben op de totale beveiliging van een organisatie.

Discussieer mee!

Wat vindt u? Waarom verschillen de policies voor databescherming op de verschillende systemen en platformen, lokaal en in de cloud? Hoe kun je deze verschillen opheffen? En: los je daarmee het probleem op van de ongenode gasten op je servers?

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

Wat mij nu ergert is dat iedereen ineens aan die MFA mag terwijl er dus aan de andere kant dit soort gaten waar MFA dus absoluut niets helpt in MS exchange steeds blijken te zitten! Het wordt tijd dat ook die softwareleverancier op zijn verantwoordelijkheden gewezen wordt!

Het is en blijft mensen werk en daar worden soms fouten gemaakt. In de cloud is het alleen iemand anders zijn verantwoordelijkheid om dit op te lossen en daar betaal je een X bedrag per maand voor. Standaardisatie en uniformiteit is wenselijk maar mijns inziens een utopie er zijn immers veel te veel belanghebbende die allemaal hun eigen idee en opvattingen hebben.

Het valt of staat met aandacht! Of je nu de leverancier of afnemer bent je moet goed zorgen voor de spullen die je neerzet om je bedrijfsdoelstellingen te halen. Wil je daar minder omkijken naar hebben dan is cloud misschien een oplossing, doe je het liever helemaal zelf dan kost dan nu eenmaal wat meer tijd en energie.

Helemaal eens met de reactie van Maikel.
Aangezien cybercriminelen als eerst de updates gaan 'onderzoeken', moet het gewoon een standaard maatregel zijn om ASAP alle systemen (servers e.d.) te updaten!

Om diverse redenen denk ik dat het niet altijd helemaal haalbaar is om een uniforme policy af te dwingen voor serversystemen, omdat de samenhang met andere systemen vaak wat complexer ligt dan een update voor bijvoorbeeld de smartphone. Een herstart van een kritisch systeem kan tot een onvoorspelbare dienstverlening leiden en bedrijven op hogere kosten, doordat extra voorzieningen getroffen moeten worden.

Wat denk ik wel zou helpen en misschien een goede eerste stap, is als er stappen ondernomen zouden worden om meer transparantie te bieden over het vulnerability management en patchbeleid van organisaties. Het zou in mijn ogen niet misstaan als organisaties, behalve de privacy policy, ook een "Patch policy" verplicht zouden moeten publiceren. Het zichtbaar maken van de mate waarin dit onderwerp serieus genomen wordt door marktpartijen, helpt de klant bij de keuze voor de juiste partij als leverancier van een digitale services. Volgende stap is natuurlijk dan controle op naleving hiervan, dat wellicht gecombineerd kan worden met een ander onderwerp.

Dit onderwerp is van dermate groot belang, omdat het regelmatig patchen en scannen op vulnerabilities de achillespees is van security. Een serieus gat kan in de praktijk soms wel dagen of weken "open staan" en andere maatregelen om persoonlijke gegevens te beschermen nutteloos maken.

Niet iedereen krijgt de notificaties in de mail van het NCSC. Je moet ze zelf gaan halen. Daarnaast is de berichtgeving niet vóór iedereen duidelijk, en wat de Ernst precies is.
Veel van de exchange servers die lokaal draaien zijn ook van klein bedrijven in de zogenaamde smb servers. Vaak hebben die geen eigen beheerder, maar iemand die die server herstart en de tapes van de backup wisselt.
Voor een aantal van de patches moest je een minimale CU versie hebben en die worden niet aangeboden via Windows Update maar moeten met het handje geïnstalleerd worden.

Een uniforme policy gaat derhalve niet werken, tenzij Microsoft de updates can Exchange anders gaat aanbieden. De CU ook weer via Windows update. Een andere optie is dat er standaard de WAP/WAF geïnstalleerd wordt die via Windows updates mitigaties krijgt die dit soort aanvallen tegen te gaan.

Daarnaast kan ook het NCSC actief scannen naar alle Exchange servers en servers die kwetsbaar zijn identificeren en de eigenaars direct benaderen om dit aan te pakken. Veel weten het ook gewoon niet dat dit lek er is, en weten niet dat ze zelf deze kennis moeten halen.

Ik denk niet dat je van alle organisatie kunt verwachten dat ze zelf verantwoordelijk zijn voor het patchen van kwetsbaarheden, zoals Wim van Campen stelt. Veel organisaties maken gebruik van dienstverleners die de gebruikte IT diensten voor ze beheren. En gaan er daarbij vanuit dat dit op een gecontroleerde én veilige manier wordt gedaan. Dit is in de praktijk helaas niet altijd het geval. Bijvoorbeeld door het ontbreken van duidelijke afspraken met de dienstverlener. Of een gebrek aan transparantie met betrekking tot verantwoordelijkheden.

Daarnaast kan niet van alle organisaties verwacht worden dat ze op de hoogte zijn van de risico’s die ze lopen bij het gebruik van de IT diensten die ze gebruiken of afnemen. Als voorbeeld: vaak weten organisaties niet eens dat er gebruik wordt gemaakt van een Exchange server. Ze maken gebruik van mail. En welk systeem of dienst daar achter de schermen technisch voor zorgdraagt? Geen idee. Hoeft een organisatie eigenlijk ook niet te weten. Voor een organisatie is mail net als water uit de kraan. Je doet de kraan open en er komt water uit. En je gaat er zonder nadenken van uit dat het water veilig is om te drinken. Maar hoe dat water veilig wordt gemaakt om te drinken? Al die systemen en platformen die daarvoor gebruikt worden? Daar sta je niet bij stil. Je denkt er niet over na. Misschien als je in het buitenland bent wel. Maar in Nederland? Niet echt.

Ik denk dan ook niet dat je de verantwoordelijkheid alleen bij organisaties neer kunt leggen als het gaat om het patchen van systemen en de veiligheid ervan. Die verantwoordelijk moet eerder liggen bij de partijen die de systemen en diensten beheren waar organisaties gebruik van maken. Dat kunnen zowel interne (de IT afdeling) als externe partijen (een Managed Service Provider, IT dienstverlener of desnoods Microsoft of Google zelf) zijn.

Het klopt dat IT- en securityteams policies moeten hebben met betrekking tot de bescherming van de data die ze voor organisaties verwerken. Wim van Campen stelt: ‘Op dit moment zijn er nog veel verschillen in de wijze waarop deze verschillende omgevingen worden beveiligd’. Maar dat gaat niet zozeer over de policy, het beleid. Meer over de wijze waarop technische beveiligingsmaatregelen zijn geïmplementeerd. Die inderdaad zullen verschillen omdat de gebruikte systemen en platformen nu eenmaal niet allemaal technisch op dezelfde wijze werken. Daarvoor zijn er domweg teveel verschillende IT systemen en platformen in gebruik.

Wat wel uniform kan zijn is het beleid. En dat beleid zou je in principe vast kunnen leggen in voorschriften en regelgeving. Ter vergelijking: bouwvoorschriften. Ik noem het bouwbesluit 2012. Dit besluit bevat voorschriften met betrekking tot bouwwerken zoals de staat en het gebruik van bouwwerken. Maar ook de veiligheid tijdens bouwen en slopen. Lees ‘em eens na: https://www.rijksoverheid.nl/onderwerpen/bouwregelgeving/bouwbesluit-2012.

En lees in plaats van bouwwerken dan even IT systemen en platformen.

Als je dan toch een uniform beleid wilt vastleggen, doe het dan op basis van voorschrifen en regelgeving waar IT dienstverleners zich aan moeten conformeren. En waar interne IT afdelingen ook gebruik van kunnen maken. Een organisatie die IT diensten afneemt bij een dienstverlener (of interne organisatie) kan het dan inderdaad als water uit de kraan zien: het is veilig om te drinken.
Om even terug te komen op de discussie en een uniforme policy: in dit geval zou de policy als volgt kunnen zijn:

“Alle beheerde IT systemen en platformen dienen voorzien te zijn van de meeste recente beveiligingsupdates/ patches die door de leverancier van die betreffende systemen en platformen ter beschikking wordt gesteld.“

Los je daarmee het probleem op van ongenode gasten op je server, zoals in het artikel wordt gevraagd? Nee. Helaas, 100% veilig bestaat niet. Ook niet voor water uit de kraan. Maar veel veiliger kan wel, zeker als een duidelijk beveiligingsbeleid wordt nageleefd. En dat beleid hoeft helemaal niet ingewikkeld te zijn. Je moet beveiliging ook niet ‘erbij’ doen, maar zien als fundamenteel onderdeel van IT dienstverlening. Beveiliging als uitgangspunt.

Zero Trust architectuur. Iemand?

Interessante opmerking van Bas Steelooper over de informatieplicht want notificatie aan de gebruiker dat het systeem vanwege onderhoud even niet beschikbaar is wordt in de cloud nog weleens vergeten. En misschien moeten we aan de discussie toevoegen of er nog wel 'downtime' gepland wordt want veel patches worden uiteindelijk pas actief na een herstart van het systeem.

Helemaal eens met artikel en dat bedrijven meer aandacht moeten besteden aan een goed en gedegen kwetsbaarheid and patch beleid en uitvoering. Echter voor veel organisaties is het lastig om bij te houden hoe dit goed te doen aangezien het toch steeds gaat om een risico inschatting te maken voor al die kwetsbaarheden. Het gaat soms om honderden kwetsbaarheden die moeten worden ingeschat en eventueel worden gepatched. En dan ook nog daadwerkelijk het patchen uitvoeren op het juiste tijdstip en manier is geen sinicure. Een partij inschakelen die dat helpt te verzorgen is mijns inziens een goede stap in de richting alhoewel risico management nooit vollledig kan worden uitbesteed. Dit blijft een verantwoordelijkheid van de organisatie zelf!!

In tegenstelling tot Wilco Turk ben ik van mening, dat we organisaties wel degelijk verantwoordelijk moeten houden voor de beveiliging van hun IT-omgeving. Want als de afnemer geen verantwoording draagt, dan ontbreekt ook de prikkel om deze prioriteit hoog te houden bij de leverancier.

Ik zie een grote parallel met de AVG/GDRP: als organisatie moet je de juiste keuzes maken voor je leveranciers en ze goed kwalificeren, zodat je de privacy van de persoonlijke data kan borgen. Voor het patchen van de systemen zou dezelfde verantwoordelijkheid moeten gelden, want het ontbreken van belangrijke patches maakt dat het systemen behoorlijk kwetsbaar kunnen worden voor data diefstal.

Transparantie over het patch- en beveiligingsbeleid zoals ik al eerder betoog, is daarbij denk ik de sleutel voor succes. Dat stelt afnemers in staat om de juiste keuze te maken en zal uiteindelijk ook de consument ten goede komen, omdat de veiligheid van de gegevens verbeterd wordt.

Met de slotopmerking van Wilco ben ik het wel eens: dit is minder complex dan dat het noodzakelijk is.

Goed punt van Wilco Turk "Je moet beveiliging ook niet ‘erbij’ doen, maar zien als fundamenteel onderdeel van IT dienstverlening. Beveiliging als uitgangspunt." . Ik begrijp dat het ontzetten moeilijk is om een patch beleid na te streven. Vaak is het voor dienstverleners of beheerders dan ook een uitdaging om up-to-date te zijn. Ze krijgen niet snel genoeg een change window of de impact is te groot en in het ergste geval word de patch dan overgeslagen. Organisaties hebben meestal security tools zoals IPS, Anti-Malware en endpoint security. Dit soort tools kunnen in veel gevallen kwaadaardigheden die misbruik maken van vulnerabilities tegenhouden. Hierdoor heb je de mogelijkheid het patchen van system minder adhoc uit te voeren.

Hmmm wat nu als MS exchange patches elke dag automatisch zonder reboot en risico van interruptie van de dienst doorgevoerd zouden kunnen worden... utopie? als ik mijn ervaringen met security updates bij RHEL er tegenover zet misschien toch niet zo. Niet dat ik hiermee een open/closed source flame wil starten, ik wil namelijk betrouwbare automatische dagelijkse patches op MX exchange en ik denk dat dat technisch wel degelijk kan en daarom haal ik het RHEL voorbeeld erbij! Ik denk dat daarom een deel van de verantwoordelijkheid toch ook wel bij MS ligt!

Ik blijf erbij dat organisaties niet verantwoordelijk hoeven te zijn voor de beveiliging van hun IT omgeving, tenzij ze die zelf ook beheren. Doen ze het beheer niet zelf, dan ligt de verantwoordelijkheid bij een partij/ dienstverlener die de IT omgeving voor de organisatie beheerd.

Een organisatie is wel altijd eindverantwoordelijk voor bedrijfsdata. En het is uiteraard ook de verantwoordelijkheid van een organisatie om due diligence toe te passen bij het selecteren van een dienstverlener die hun kroonjuwelen (lees: bedrijfsdata) voor ze gaat verwerken. Maar je kunt moeilijk van de plaatselijke groenteboer, die een mailbox via zijn Internet provider gebruikt, verwachten dat die dat gaat doen. Ook hier weer: water uit de kraan. Maar als de Internet provider in kwestie zijn patchbeleid niet op orde heeft dan kan de groenteboer daar de dupe van worden.

De dienstverlener moet daarom transparant zijn in de diensten die worden aangeboden en de manier waarop ze zijn beveiligd. Helder, duidelijk en liefst zo functioneel mogelijk omschreven zonder te technisch te worden. Onderdeel daarvan is ook patchbeleid en de wijze waarop deze is geimplementeerd. Ik ben het met Hans Rattink eens dat dit meer zichtbaar mag zijn, vaak is het nu niet expliciet beschreven in een overeenkomst. Of zichtbaar zoals een privacy policy. Wellicht dat een landelijk erkend keurmerk daarbij zou kunnen helpen. Maar de transparantie waar ik het over heb moet binnen een grote organisatie die zijn eigen IT spullenboel beheerd van toepassing zijn.

Er is een duidelijk onderscheid tussen policy (beleid) en de implementatie ervan. Laten we policy in dit verband ook niet verwarren met technische policies. Policies die zijn ingesteld op systemen en platformen en die er voor zorgen dat updates/ patches automatisch, op reguliere momenten worden geinstalleerd. Die kunnen wel onderdeel zijn van de implementatie van een beveiligingsbeleid, maar daar gaat het niet over.

Om weer even naar het oorspronkelijke artikel terug te verwijzen, daarin wordt het volgende gezegd:

“It- en securityteams hebben een manier nodig om uniforme policies voor databescherming toe te passen op ieder systeem en platform, zowel on-premises als in de cloud”

Zo’n uniforme policy kan prima worden gebaseerd op het Cybersecurity Framework dat door het National Institute of Standards and Technology (NIST) is gemaakt. Of wat te denken van de ISO 27001 normering, die gaat uiteindelijk over informatie beveiliging.
We hoeven het wiel niet opnieuw uit te vinden volgens mij, dat is al gedaan. Je moet het alleen wel toepassen.

Kijk eens op https://delorentz.nl/ransomware-deel-1 waarin ik praat over bescherming en identificatie met betrekking tot ransomware.

Misschien moet ik mijn punt ietsjes nuanceren: organisaties zijn volgens mij verantwoordelijk voor het correct (laten) beveiligen van data en kunnen daarbij het onderhoud van de onderliggende systemen en diensten eventueel delegeren naar derden. Dat ontslaat ze volgens mij niet van de verantwoording om daarbij dienstverleners te kiezen, die (onder andere) een passend vulnerability management beleid voeren, dat overeenkomt met de vereisten voor de data die door die systemen bewaard en verwerkt wordt. Probleem van dit moment is echter, dat door het ontbreken van transparantie de organisaties die verantwoording inderdaad vaak moeilijk kunnen dragen.

Het goed beleggen van verantwoordelijkheid helpt om organisaties aan te sporen om de juiste maatregelen te (laten) nemen en leveranciers te kiezen, zodat de systemen en data beter tijdig en adequaat beveiligd worden. Hierbij is transparantie over het gevoerde beveiligingsbeleid denk ik de sleutel die dat mogelijk kan maken, waarin het patch beleid goed begrijpelijk in moet zijn verwoord. Met andere woorden, de groenteboer moet eenvoudig een antwoord kunnen krijgen of zijn leverancier beveiligingsmaatregelen snel (genoeg) doorvoert - en een beter voorbeeld is wellicht de lokale boekhouder, die wat meer gevoelige informatie beheert maar nog steeds niet veel weet van IT of Security.

Ik ben het eens met Wilco Turk dat veiligheidsraamwerken zoals NIST en ISO27k en goede standaarden bieden om de gegevensbeveiliging structureel te verbeteren, maar ze vragen ook om inhoudelijke kennis om het resultaat ervan goed te kunnen interpreteren. Dat is voor velen niet weggelegd. Ook kan dit voor veel kleine organisaties een behoorlijke uitdaging zijn om zo'n raamwerk te implementeren.

Daarom zou ik ook niet een nieuwe standaard willen introduceren; wel zou ik voorstander zijn van een soort van "Energielabel voor security". Daarmee zou niet gereguleerd of gedicteerd hoeven worden, hoe de leveranciers de digitale wereld moeten standaardiseren, maar bieden we wel een houvast voor de meerderheid van de niet IT onderlegde beslissers bij organisaties maar ook bijvoorbeeld de overheid, om een mening te kunnen vormen over het resultaat van de genomen maatregelen. Een NIST of ISO certificering zal dan vrij snel een "groen label" kunnen opleveren maar het biedt ook ruimte om organisaties te kwalificeren zonder die certificeringen, bijvoorbeeld door er kwantitatieve wegingen in op te nemen. Zo kan bijvoorbeeld en onder andere, en zowel voor ISO/NIST gecertificeerde als ongecertificeerde levaranciers meegewogen worden, of kritische patches binnen een dag, week of maand geinstalleerd worden en kan de "groenteboer" een kosten/baten-analyse maken voor zijn digitale leverancier, die wellicht met een B-label "klaar is", terwijl de locale boekhouder toch echt een "A++" nodig heeft :-)

Zo komen we nog eens ergens. Ik vindt 'Energielabel voor security' een goede bewoording. Zelf zat ik met 'keurmerk' in mijn hoofd, maar de analogie met een energielabel is een betere. Een energielabel gaat ook niet in op de achterliggende technische maatregelen die ervoor zorgen dat een apparaat een B, A of A+ label krijgt. Maar beschrijft wel de voorwaarden waar het apparaat aan moet voldoen om zo'n label te verdienen. Dat kun je heel goed vertalen naar voorwaarden waar een organisatie, leverancier of dienstverlener aan moet voldoen om een bepaald IT security label te verdienen.

Een hele grote uitdaging daarbij is dan natuurlijk wel de naleving ervan en de controle erop. Dat vraagt om auditing, een regelmatige 'keuring'. Bedrijven moeten wel (blijvend) kunnen aantonen dat ze voldoen aan de voorwaarden om een bepaald label te mogen gebruiken.

De NCSC heeft ook al eens een plan geopperd voor de 'Orde van ict-beveiligers'. Ook daar kun je wat mee, al is het dan meer op de professionals gericht die voor een organisatie, leverancier of dienstverlener werken. Ze beschikken dan bijvoorbeeld over een certificering of opleiding, en er zijn duidelijke regels waaraan ze zich moeten houden. Doen ze dat niet dan worden ze, helaas, uit de 'orde' gezet. Een ethische code kortom. En dat kan dan weer bijdragen aan het verkrijgen van het 'IT security label', immers men werkt met professionals uit de 'Orde van ict-beveiligers'.

Het patchen van systemen wordt vaak gezien als saai en lastig. Teams zijn doorgaans al zo overladen met werk dat zelfs het installeren van security patches een lagere prioriteit krijgt, triest maar waar. Daarnaast kan het ook een service onderbreking zijn: bij het installeren van nieuwe software is vaak een restart nodig, niet altijd gewenst.

Een andere reden van uitstel zit ook vaak in afhankelijkheden: het installeren van een nieuwere software versie, patch/upgrade kan effecten hebben bij integraties en koppelingen met andere systemen. De integraties die er tegenwoordig zijn maken het snel patchen en upgraden van systemen er niet eenvoudiger op.

Vanuit architectuur helpt het al wel door services, de essentiële, in een failover structuur te bouwen. Dat geeft dan meer ruimte voor een update/patch zonder service-interruptie, maar dat verkleint de werkdruk niet. Het verder automatiseren van repetitief werk zou daarvoor helpen.

Wederom, patchen zal vlugger beter en vanzelf gaan als de kwaliteit van de updates en de frequentie op orde zijn. Het zou helemaal ultiem zijn als er dan ook vrijwel geen down time is omdat er geen reboot nodig is maar bijv alleen het herstarten van de service zodat nieuwe verbindingen met de gepatchte diensten aan de slag gaan. Alle problemen die hierboven wederom met keurmerken en theorieen en wat allemaal nog meer eigenlijk alleen maar in stand gehouden gaan worden, zullen als sneeuw voor de zon verdwijnen als in de PRAKTIJK het risico loos is elke dag automatisch zonder interrupties patches door te voeren! We hebben met fundamentele kwaliteitsproblemen te maken als je patches en updates doorvoeren instabiele diensten veroorzaken. Gaat niet met een beetje management we gepoetst worden hoor!

Ik snap wat je zegt Martin, en ik zie dat ook in praktijk gebeuren. Maar het mag geen excuus zijn. Net zoals een serviceonderbreking of herstart dat ook niet mag zijn. Soms is een serviceonderbreking of herstart nu eenmaal nodig. Uit ervaring weet ik dat communicatie daarbij erg belangrijk is en dat vrijwel niemand bezwaar heeft tegen een onderbreking als het gaat om de veiligheid van bedrijfsdata.

Eén van de belangrijkste pijlers in cybersecurity is het tijdig updaten en patchen van systemen. Kwetsbaarheden in systemen worden continue misbruikt door kwaadwillenden. En zeker de kwetsbaarheden die net aan het licht zijn gekomen en waar nog geen oplossing voor beschikbaar is. Juist daarom is tijdig updaten en patchen zo belangrijk.

Zoals ik al eerder heb gezegd: je moet beveiliging niet ‘erbij’ doen, maar zien als een fundamenteel onderdeel van IT dienstverlening. Beveiliging als uitgangspunt. Patchen van systemen is wat mij betreft dan ook een reguliere, terugkerende taak. Niet alleen het uitvoeren ervan, ook het controleren erop. Procedureel vastgelegd en onderdeel van de dienstverlening.

Van papieren tijgers naar nietzeggende keurmerken omdat er niemand meer is om de pleisters te plakken doet me denken aan de zorg. Wat er niet is zal er niet vanzelf komen want de cirkelredenering (circulus in probando) van een audit omdat een keurmerk anders een sticker zonder waarde wordt gaat voorbij aan het beginpunt van de discussie. Het negeren van de adviezen - hoe dringend dan ook - gaat om een gemis aan dwang want het is niet NCSC die op de bok zit als bestuurder en daar is een reden voor.

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2021-09-03T17:14:00.000Z Diederik Toet
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.