De race tussen cybercriminelen en security professionals wordt steeds sneller en intenser. Telkens de security-sector een nieuwe bescherming ontdekt tegen de gevaren van buitenuit, vinden de cybercriminelen wel een manier om deze technologie in hun voordeel te gebruiken.
Denk maar aan Artificial Intelligence. De meeste security vendors hebben wel een of andere vorm van intelligentie ingebouwd die automatisch potentiële malware als schadelijk kan identificeren en zonodig elimineren en meteen ook deze malware kan toevoegen aan de lijst van gekende gevaren.
Maar ook de cyberschurken hebben de voordelen van AI intussen al ontdekt: door automatisering van taken zoals het doorzoeken van netwerken op zwakke schakels kunnen de ‘baddies’ veel sneller en grondiger te werk gaan in hun voorbereiding op het echte werk: de eigenlijke aanval, bij voorkeur op de minst beveiligde flank.
Potentiële verdachten
Het is maar één voorbeeld van hoe eenzelfde innovatieve technologie uiteindelijk beide partijen vooruithelpt en uiteindelijk aan de race zelf weinig verandert. Het blijft dus dweilen met de kraan open en aanvaarden van risico’s in de wereld van cybersecurity. We houden redelijk goed stand maar een voorsprong nemen op de criminelen lukt voorlopig niet.
U kunt zich afvragen hoe dit komt. Is het nu echt zo moeilijk om software te maken die veilig is?
U kunt zich afvragen hoe dit komt. Is het nu echt zo moeilijk om software te maken die veilig is? Hier zijn meerdere antwoorden op. Het eerste is een kort “ja”. Inderdaad is het niet eenvoudig om een technologiestack die gemaakt is om gebruikt te worden, die zeer flexibel is en ook nog eens wereldwijd beschikbaar is, veilig te maken en te houden. Verder mag je natuurlijk de “human factor” niet over het hoofd zien – veel cybersecurityproblemen worden veroorzaakt doordat mensen vergissingen maken of zich gewoon laten beetnemen.
Dit laatste is aan te pakken via continue campagnes, bewustwording, opleiding etc. Het eerste probleem ligt evenwel wat moeilijker: veel van onze systemen zijn domweg niet gebouwd met security op de radar, en soms zefs niet eens met security in het achterhoofd. Dit is geen kritiek, het is een vaststelling. Als we jaren geleden al dit gevoel van voortdurende bedreiging hadden gekend, dan hadden ontwikkelaars van meet af aan programma’s kunnen ontwikkelen met het gevaar van misbruik in gedachten.
Dan hadden we een hele generatie ontwikkelaars en ICT-architecten kunnen vormen die steeds vertrekken vanuit diezelfde gedachte: iedereen is een potentiële verdachte, tot het tegendeel bewezen is. Misschien niet echt een erg menslievende gedachte maar wel de enige juiste voor software die mogelijk door de hele wereld kan gebruikt en misbruikt worden.
Misbruikbestendig
‘Security by design’ noemen we die aanpak: in plaats van software te beveiligen door er firewalls, isolerende compartimenten en andere beschuttingsmiddelen voor en rond te plaatsen, als een soort bijgedachte (in het Engels zeg je zo mooi “afterthought”), zorgen we gewoon dat beveiliging op alle niveaus, zelfs in de software zelf, is ingebouwd. Zo worden de kansen op misbruik tot een minimum beperkt.
Nu ja, ‘gewoon’… Uit ervaring blijkt dat het allesbehalve eenvoudig is om software volledig misbruikbestendig te maken.
Nu ja, ‘gewoon’… Uit ervaring blijkt dat het allesbehalve eenvoudig is om software volledig misbruikbestendig te maken. En vooral blijkt dat voor zulke extra omzichtigheid in het ontwikkelwerk zelden tijd en budget worden vrijgemaakt. Nochtans is dit één van de beste en kostenefficiëntste manieren om cybermisbruik te bestrijden. Fouten en lekken achteraf ontdekken en dichten kost een bedrijf veel meer dan ze nog in de ontwikkelfase detecteren en aanpassen.
Toch zal het nog enige tijd duren eer dit besef doordringt tot elke organisatie en eer in het ontwikkelproces standaard de nodige tijd wordt vrijgemaakt voor security-maatregelen. Wellicht zal dit pas echt volledig doorbreken, als we er – GDPR achterna – een wet- en regelgeving rond bouwen en een bestraffingsysteem voor iedereen die niet aantoonbaar zijn best heeft gedaan om in de ontwikkelfase al aandacht te besteden aan security.
Y2K maar erger
Dat klinkt allemaal heel mooi (en al niet eenvoudig), maar we blijven dan nog zitten met de ‘legacy’: alle toepassingen en apps die werden ontwikkeld nog voor het courant werd om security van bij het ontwerp te integreren. Dat zijn geen tientallen of honderden maar vele miljoenen toepassingen, en talloze miljarden lijnen code. Om die allemaal inherent veilig te krijgen, zou je een ‘application overhaul’ moeten voorzien zonder voorgaande. Vergeleken daarmee zou de hele Y2K-heisa een doordeweeks projectje lijken.
Om die impact in te schatten hebt u niet eens echt veel verbeelding nodig. Ten eerste zijn vele bedrijfskritieke programma’s nog steeds in oude talen zoals Cobol ontwikkeld en is het aantal hiervoor beschikbare programmeurs niet bepaald gestegen. Ten tweede is een transitie van de ene omgeving naar de andere vaak erg pijnlijk.
In afwachting van een toekomst waarin elke software ‘secure by design’ is, zullen we ons dus moeten behelpen met ‘next best things’.
Denk maar aan de vele ERP-projecten in het verleden: het bleek eenvoudiger om de organisatie aan te passen aan de software dan om de software bij te sturen in functie van de bedrijfsrealiteit. Zo lastig is het om de logica in een toepassing bij te sturen, en dus ook om de software ‘secure by design’ te maken. Want security inbouwen is een veel grotere ingreep dan de aanpassing van die enkele datumveldjes die bij Y2K vaak voldoende was.
In afwachting van een toekomst waarin elke software ‘secure by design’ is, zullen we ons dus moeten behelpen met ‘next best things’ zoals segmentering van de infrastructuur, zodat bij eventueel geslaagde inbraken nog steeds slechts een beperkte toegang tot de totale infrastructuur mogelijk is.
Dit is een ingezonden bijdrage van Rudolf de Schipper, Delivery Lead Belgium and International Institutions bij Unisys. Via deze link vind je meer informatie over de mogelijkheden van het bedrijf.