ORDINA BLOGT

De basis van ICT security - deel 2

Waar het allemaal mis kan gaan met de techniek (ICT security).

  • Daniël Geerts
  • 7 juni 2016

In mijn vorige post heb ik gezegd dat een keten (systeem) slechts zo sterk is als haar zwakste schakel. Maar hoe zien deze zwakke schakels er nou eigenlijk uit? In wat voor vormen en smaken komen ze allemaal?


Zwakke schakel in een keten

Bugs in computers.

Een typisch computer systeem bestaat uit meerdere onderdelen, die grofweg in drie categorieën onder te verdelen zijn: hardware, firmware, en software. Hardware is de fysieke apparatuur van de computer: de kast, de printplaten, en alle andere elektronica. Software is de code (instructies) die aangeven welke operaties de hardware moeten uitvoeren. Dit zijn bijvoorbeeld programma's zoals Microsoft Office en Adobe Reader, maar ook het besturingssysteem (Windows, Mac OS, ...) zelf. En firmware zit daartussenin: het is de software die nodig is om de hardware haar werk te laten doen, maar die wel onlosmakelijk verbonden is met het functioneren van de hardware. Een voorbeeld is de code die op een e-reader (zoals een Amazon Kindle) of een MP3-speler draait: het is een vorm van software (code), maar het is wel noodzakelijk om de hardware überhaupt correct te laten opstarten. Het bekendste voorbeeld van computer is de BIOS of UEFI firmware.

En dan is er nog een computer-overstijgende onderdeel: netwerken. Een netwerk bestaat uit hardware (kabels, routers, etc.) en uit software (de code die data verstuurd over de lijn), maar het gedraagt zich zo significant anders dan hard-, soft-, of firm-ware dat het in een eigen categorie thuishoort.




Op elk van deze vier gebieden kunnen zwakke schakels ontstaan. In het algemeen gebeurt dit natuurlijk niet expres of bewust, maar omdat programmeren en ontwerpen ingewikkelde bezigheden zijn, worden er fouten gemaakt en dingen over het hoofd gezien.

Vuistregel nummer twee:
Aangezien fouten maken menselijk en onvermijdelijk is, moet hier rekening mee gehouden worden.

De gemaakte fouten en vergissingen kunnen vervolgens in drie groepen gesorteerd worden: implementatiefouten, ontwerpfouten, en inherente risico's.


Een implementatiefout betekent dat de code niet geheel volgens specificatie of best practices is gemaakt. Vaak zijn dit simpele foutjes (bugs) in de code; bijvoorbeeld bij een gemiddelde uitrekenen een getal vergeten mee te nemen. Door functionele testen kunnen dit soort fouten opgespoord worden. Maar dit soort fouten kunnen ook beveiligingsimplicaties hebben, als er bijvoorbeeld vergeten wordt te controleren of de gebruiker wel de goede rechten heeft om de verzochte actie uit te voeren. Ook komt het voor dat de programmeur aannames gemaakt heeft ("dat gebeurt toch nooit"), waardoor bepaalde situaties niet correct afgehandeld worden.


Ontwerpfouten zijn fouten of onzorgvuldigheden in de specificatie van het ontwerp van een systeem. Een goed voorbeeld is het email-protocol, waarbij alle data zonder verificatie wordt verstuurd. Hierdoor is het mogelijk om de afzender van een email te wijzigen, zodat de email van een ander adres afkomstig lijkt (spoofen). Dit is geen bug in de email server, maar een "bug in het protocol". Zelfs een perfecte implementatie zal hier last van hebben, omdat email simpelweg op deze manier werkt.

Ook kunnen ontwerpfouten "ontstaan" door voortschrijdend inzicht. Dit gebeurt bijvoorbeeld in de wereld van de cryptografie: door nieuw wiskundig inzicht worden betere manieren gevonden om encryptie te doorbreken, waardoor bepaalde versleutelingsalgoritmes verzwakken of zelfs gebroken worden. Versleutelde data die gisteren veilig was, is dat dan morgen niet meer. Een systeem dat blijft leunen op een verouderd algoritme wordt daarmee dus onveilig.


Inherente risico's zijn mogelijke beveiligingsproblemen die ten grondslag liggen aan de ontwerpkeuzes die gemaakt zijn voor het systeem. Een pincode is bijvoorbeeld gelimiteerd tot maximaal 10000 mogelijkheden. Als er geen additionele maatregelen getroffen worden, biedt dit dus niet veel veiligheid, omdat een aanvaller gewoon alle mogelijkheden af kan gaan. Dit is een risico inherent aan het pincode-systeem, dat weer apart gemitigeerd moet worden (door bijvoorbeeld de pas "op te eten" na drie foutieve pogingen), of geaccepteerd moet worden als tekortkoming van het systeem zelf.




Inherente risico kunnen (en behoren) in kaart gebracht worden tijdens het ontwerpen van het systeem. Tevens kunnen tegelijkertijd ontwerpfouten opgespoord en opgelost worden, voordat ze een probleem vormen, want ze achteraf herstellen is zeer moeilijk. Maar het is de eerste groep waarop ik me ga richten in de volgende blogpost: implementatiefouten. Oftewel: bugs.