9 leerzame securitybloopers

Elke organisaties maakt fouten, ook op ict-vlak. Echter fouten in de security kunnen direct problemen opleveren. Het verlies van informatie, imagoschade, dat wil je niet op je geweten hebben. Steek daarom wat op van de volgende securitybloopers.

1. Veilige wachtwoorden
Een postbedrijf denkt het goed te doen en adviseert zijn klanten om veilige wachtwoorden te gebruiken. Een prima advies, alleen bij de instructies van het postbedrijf zal menigeen zijn wenkbrauwen gefronst hebben. ‘Voorkom misbruik, gebruik een veilig wachtwoord van minimaal acht tekens, zoals ‘Wachtwoord1’.’ Onbedoeld adviseerde het bedrijf dus om zo’n beetje het meest gebruikte wachtwoord te gebruiken. Slimmer is om in het wachtwoord geen link te leggen met iets voorspelbaars rondom de eigen persoon of organisatie. Beter is om qua wachtwoord een reeks van cijfers en letters, kapitaal en onderkast, te gebruiken, bij voorkeur gecombineerd met leestekens. Leg dit ook in het securitybeleid vast.

2. Privé e-mail
Iedereen heeft weleens meegemaakt dat op de e-mail een bericht binnenkwam dat voor iemand anders bedoeld was. Pijnlijker wordt het als op de privémail een vertrouwelijk document van een grote Nederlandse bank binnenkomt. Het e-mailadres bleek vroeger van een bankmedewerker te zijn geweest die dit persoonlijke e-mailadres ook zakelijk gebruikte. Collega’s van hem stuurden blijkbaar dus interne stukken naar zijn privémail. Doe dit nooit, zorg dat je vastlegt dat medewerkers geen privémail gebruiken voor zakelijke communicatie.

3. Data veilig in cloud
Onlangs kwam naar buiten dat er in het afgelopen jaar miljoenen Dropbox-gebruikersnamen en -wachtwoorden zijn gelekt. Hoe had dit voorkomen kunnen worden? Ten eerste moet men niet hetzelfde wachtwoord gebruiken voor meerdere accounts (e-mail, webshop, Dropbox, et cetera). Daarnaast is encryptie een andere perfecte oplossing. Wanneer een cybercrimineel zich toegang weet te verschaffen tot de cloud, dan zorgt encryptie ervoor dat de data sowieso niet leesbaar zijn voor onbevoegden.

4. Autorisatie
Een ervaren developer had een speciaal systeem gebouwd om beveiligd bestanden uit te kunnen wisselen. De ontwikkelaar had aan bijna alles gedacht: two factor-authenticatie, beveiligde verbinding, encrypted opslag, auditing, et cetera. Eén ding was hij echter vergeten in te bouwen: autorisatie. Dus uiteindelijk kon iedereen nog steeds overal bij. Zorg bij het ontwikkelen van een nieuw systeem of proces dat voor elk object de nieuwe of gewijzigde autorisaties worden ingesteld. Een ‘access control list’ kan hierbij helpen.

5. Certificaten
Een middelbare school had op zijn website een certificaat staan met als naam ‘192.168.1.1’. Ze vonden het vreemd dat Internet Explorer geen beveiligde verbinding naar hun website wilde maken en stuurden aan hun medewerkers een brief waarin werd gemeld dat er een bug in de nieuwste versie van Internet Explorer zat. Later bleek dat ze helemaal geen idee hadden dat er een certificaat nodig was. Ze hadden het certificaat laten staan dat door de leverancier standaard op de firewall was geïnstalleerd. Uiteraard hadden ze zelf voor een certificaat moeten zorgen en dit op hun firewall moeten installeren.

6. Rest-interface
De applicatie Silverlight deed in de frontend de authenticatie, een controle van de gebruikersnaam en het wachtwoord. Om de wachtwoorden te kunnen controleren was er een rest-interface gemaakt waarmee het frontend de volledige gebruikersgegevens, inclusief wachtwoord, clear-text ophaalde. Die rest-interface was door iedereen gewoon aan te spreken. Dit is relatief eenvoudig te voorkomen. Wat men namelijk had moeten doen, was de controle niet in de user interface stoppen, maar in de backend.

7. Back-up
De interne informatie die medewerkers in hun onderneming zochten, bleken te komen uit back-up service accounts. Het management was al zwaar verbaasd waarom het gehele bedrijf altijd van alles op de hoogte was. Draai daarom nooit je back-ups op de centrale server. Zorg er als organisatie altijd voor dat je een aparte back-upserver hebt met voldoende opslagcapaciteit, die niet gekoppeld zit aan de server waar medewerkers gebruik van maken.

8. Gratis tools
Een meedenkende systeembeheerder had een plek gevonden waar hij gratis tooling vandaan haalde om zakelijk in te zetten. Echter downloadde hij bij een tool ook een Trojaans paard op het management-lan, waardoor hij alle servers infecteerde. Kijk daarom uit met aanbieders van gratis tooling, want niet iedere tool is goed bedoeld. Controleer de afzender en de maker van de tool en ga niet altijd voor de laagste prijs. Soms is het gewoon veiliger om een betaalde variant, inclusief ondersteuning aan te schaffen.

9. Security-architectuur
De meest voorkomende fout in het bepalen van een securitypropositie is de methode waarin een organisatie tegen elk probleem een technologie plakt. Organisaties moeten een helikopterview toepassen op de ict-omgeving en van daaruit de juiste securityarchitectuur en -strategie bepalen. Techniek gaat daarbij een ondergeschikte rol spelen aan de initiële vragen. Geen enkele point solution is in staat om de complete securityproblematiek aan te pakken en daarom moet er goed gekeken worden naar integratie van end-to-end securitystrategieën. Veel bedrijven zullen daarom meer moeten investeren in zichtbaarheid en continue monitoring in plaats van point in time-detectie. Overstijg dus de techniek en analyseer de juiste risico’s en uitdagingen die voor de organisatie van belang zijn.

Dit artikel is eerder verschenen in Computable magazine jaargang 48, nummer 1 van januari 2015.