Oplossing zonder beveiliging is geen oplossing

Heb je wel eens het boek 'Writing secure code' (Microsoft Press) gelezen? Nee? Schande! Zelfs als je geen ontwikkelaar bent zou je het moeten lezen. Dit boek was destijds voor mij een echte eye opener op het gebied van beveiliging van it-componenten en werd door Bill Gates op de must-read lijst voor Microsoft-medewerkers gezet.

En terecht. In veel gevallen wordt het beveiligen van software oplossingen behandeld zoals we documentatie en testen behandelen: we doen het als er tijd overblijft in het project. En we hebben er eigenlijk niet zo veel verstand van of zin in. Maar zo werkt het niet! Zeker niet meer sinds de komst van het internet en al helemaal niet meer sinds de komst van mobile en apps. De keten met informatie is zo veilig als de zwakste schakel. Elke component in de keten moet dus met veiligheid voorop ontwikkeld worden. Het boek, en de vele andere resources op dit gebied, kunnen hierbij uitstekend van dienst zijn. Verplicht leesvoer dus voor iedereen die in de it acteert. Dit is ook een onderdeel van het vakgebied waar continu in rap tempo verder geleerd kan worden.

Olievlek

Afgelopen week werd bekend dat er een lek in OpenSSL zit; de zogenaamde heartbleed bug (zie heartbleed.com). Deze bug is door een programmeur gecreëerd (een menselijke fout dus) en vervolgens is dit als een olievlek verspreid omdat de halve wereld aan elkaar hangt met internetprotocollen zoals http en dat betekent in de praktijk dat hett in veel gevallen op transport niveau ‘beveiligd’ is door middel van de OpenSSL implementatie. Grappig was dat Microsoft trots melde dat het Azure cloudplatform hier geen last van heeft, behalve de Linux VM’s die op de IaaS laag draaien. Omdat Azure zelf niet op open source gebaseerd is en deze bug niet in de Microsoft closed source implementatie van SSL zijn weg heeft gevonden. Andere programmeur. Met meer geluk?

Nee, dit heeft niets met geluk te maken. Dit gaat om het ontwerpen en ontwikkelen van software met de best mogelijke veiligheid als doel door middel van threat model analysis en strenge (deels te automatiseren) source code controle. Hiermee kan vroegtijdig (vaak al tijdens ontwerp) in kaart worden gebracht waar de kwetsbaarheden zich (zullen) bevinden en wat er aan gedaan kan worden om die kwetsbaarheden zo veel mogelijk te voorkomen of, in geval van ‘inbraak’ de negatieve effecten zo veel mogelijk te minimaliseren; als iemand dan al kan inbreken op een proces, dat hij of zij niet de rest van het systeem kan benaderen bijvoorbeeld.

Het is de plicht van elk software architect en engineer om veiligheidsrisico’s en bijbehorende softwarematige oplossingen vroegtijdig inzichtelijk te maken en als onderdeel van het ontwikkelproces gelijk aan te pakken. Hiervoor moet dus ook ruimte gemaakt worden in de projectbudgetten en -planning. Dit valt onder het kopje ‘architectuur’. Voorkomen moet worden dat het oplossen van veiligheidsproblemen door middel van refactoring in een Agile-team wordt gedaan. Iemand heeft ooit gezegd ‘you cannot test security into a product’ en daar heeft de man (of vrouw) helemaal gelijk in! En voor Agile geldt zeker ook: alle learnings op het gebied van security threats en issues worden in volgende sprints gelijk weer meegenomen.

Natuurlijk is het  in de meeste gevallen ook een kwestie van gecalculeerd risico. Maar wat gebeurt er als bijvoorbeeld een component herbruikt wordt in een product of proces met een veel hoger risicoprofiel? Liggen dat soort gevaren ook niet op de loer? Zeker in een meer en meer service oriented cloud-wereld, waarbij diensten van over de hele wereld onderdeel kunnen uitmaken van jouw totaaloplossing is het zaak om ook daar goed rekening mee te houden in je threat models. We hebben het gezien met OpenSSL en heartbleed. Iedereen ging er vanuit dat dit veilig was, maar dat viel toch even tegen. En lees maar in de nieuwberichten wat het kost om dit op te lossen. Nog afgezien van de geleden schade door alle gelekte informatie. Want door een lek in dit ene component, lag even bijna alle informatie op het internet voor het oprapen.

Overigens zou ik me ondertussen als open source softwaregebruiker toch zorgen gaan maken. De oproep tot donaties naar aanleiding van heartbleed heeft bij lange na niet het gewenste effect gehad. Er is dus niet genoeg geld om dit soort problemen in de OpenSSL-stack in de toekomst te voorkomen. Aldus de programmeur die de fout had gemaakt: ‘Het is ongelukkig dat de software gebruikt wordt door miljoenen mensen, maar dat er maar een paar mensen zijn die er een bijdrage aan leveren.’

Mijn conclusie is dat veilige software ontwerpen en ontwikkelen serieus werk is, niet goedkoop is en altijd voor een belangrijk gedeelte mensenwerk blijft. En maak bij het gebruik van diensten of componenten van derden dezelfde veiligheidsafwegingen als bij het zelf ontwikkelen van software. Maar bovenal: Oplossingen zonder afdoende beveiliging creëren staat gelijk aan het creëren van geen oplossingen.