Alles is kwetsbaar. De recente rij grote security-incidenten toont dit wel aan: Heartbleed, Shellshock, POODLE en ga maar door. Voorkomen door veiligere code is één ding. Beter monitoren en breekpennen gebruiken is ook nodig.
Over deze blogger
Ronald Prins is directeur en medeoprichter van Fox-IT. Hij studeerde Technische Wiskunde aan de TU Delft en heeft zich daarna gespecialiseerd als cryptograaf. Bij het Nederlands Forensisch Instituut was hij werkzaam als wetenschappelijk onderzoeker. In het kader hiervan heeft hij vele beveiligingen doorbroken waar de politie tegenaan liep bij het uitvoeren van hun onderzoeken. Daarnaast is hij medeverantwoordelijk voor de inzet van nieuwste methoden om digitale informatie voor rechercheonderzoeken te verkrijgen. In 1999 heeft hij samen met Menno van der Marel Fox-IT opgericht.
Heartbleed en andere grote, recente beveiligingslekken laten zien dat alles kwetsbaar is. En dat er slecht naar code wordt gekeken. Bij open source is er wel de optie om de broncode in te zien, maar in de praktijk blijkt dat dit te weinig gebeurt. Vaak is code ook een allegaartje; niet iedereen kan goed programmeren. Het eerste wat Fox-IT doet bij een pentest is kijken in de broncode. Daar vinden we vaak kwetsbaarheden, om te benutten voor de penetratietest bij een klant.
Securitychecks voor álle code
Het is dan ook zaak om securitychecks te doen, voor alle soorten code. Niet alleen voor securitysoftware. Bij de encryptie-library OpenSSL is het logisch om de code te auditen op beveiliging, maar toch zat daar een groot gat in: Heartbleed. Bij de Unix-shell Bash lijkt het minder logisch om een security-audit te doen, maar ook daar bleek het nodig te zijn. De grote Shellshock-kwetsbaarheid was het zoveelste forse beveiligingslek op rij.
Dat het ontwikkelteam achter het door Heartbleed geraakte OpenSSL klein is, maakt niet veel uit. Het hoeft geen groot team te zijn om veilige code te maken. Een groot bedrijf lukt het meestal wel om code goed door te nemen op kwetsbaarheden, maar dat maakt het wel kostbaar. Bovendien speelt er nog de planning of time-to-market mee: als een product is aangekondigd om op een bepaald moment uit te komen dan krijgt die deadline vaak voorrang. Dit geldt niet alleen voor nieuwe producten maar ook voor updates; die blijken niet altijd uitgebreid genoeg getest te zijn.
APK voor software?
Soms nemen leveranciers het moeilijke besluit om een product of update even uit te stellen. Vanwege beveiligingskwesties of vanwege functionele bugs. Zie bijvoorbeeld Google dat de uitrol van de nieuwe Android-versie Lollipop tijdelijk heeft stopgezet in Nederland. Het bleek namelijk dat sms-berichten bij Vodafone Nederland niet goed werkten op Lollipop. Vervolgens krijgt Google daar wel kritiek over. Terwijl dit op het eerste oog geen beveiligingkwestie is, komt de keuze voor uitstel en bugfixing vaak neer op een keuze tussen marketing en security.
Misschien moet er een soort APK voor software komen. Dat is makkelijker gezegd dan gedaan. Een bezwaar is dat er dan een enorme overheidsbemoeienis met de marktwerking zou komen. Een ander, praktisch bezwaar is de vraag hoe je dan een goed auditsysteem voor softwaredevelopment op moet zetten. In het verleden zijn er al vele IT-beveiligingsaudits geweest die organisatie glansrijk hebben doorstaan terwijl er later toch beveiligingsproblemen bleken te zijn.
100% foutvrij gaat toch niet lukken
Bovendien komen we er niet met alleen preventieve codecontrole. Het gaat ons namelijk toch niet lukken om honderd procent foutvrije code te maken. Er wordt elke dag meer code geschreven dan er wordt bekeken. Dus komt het uiteindelijk neer op beter monitoren. Misbruik van het Heartbleed-lek laat naderhand op misbruikte servers geen sporen na, maar tijdens het misbruik valt er met netwerkmonitoring ineens verdacht verkeer te bespeuren. Dan zou er een automatische blokkering of afremming moeten zijn die dan de verdachte handeling tegenhoudt; een zogeheten rate limiter. Zoals een fysieke breekpen bij een buitenboordmotor fysieke beschadiging voorkomt wanneer de schroef iets raakt. IT zou meer breekpennen moeten hebben.
