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.
Leuk en leerzaam stuk Gijs. Waar voor dank.
Je draagt een aantal zeer valide punten aan.
Goed verhaal Gijs.
Had wel een langere reactie willen schrijven.. maar resumerend zou die niet anders zijn dan wat ik al vaker heb gemeld.
Wat maakt het nog uit als geheime diensten software bedrijven verplichten om backdoors in te bouwen. Dan is het ook niet zo vergezocht om te veronderstellen dat ze het niet zo nauw nemen door ontwikkelaars van open-source software in te zetten om bewust dit soort bugs in te laten bouwen.
Waarom wordt hier weer het open source model als risicovol neergezet terwijl dat door de bank genomen juist omgekeerd is.
Wanneer we naar alle software kijken dat komt FOSS in dit opzicht beter weg als proprietary. Beter eerst informeren voor dit soort uitspraken gedaan worden.
Het profiel van Gijs:
over ervaring “en de laatste 14 jaar specifiek in de Microsoft wereld”.
Ik ruik fud op grote afstand.
Heeft MS hiervoor betaald?
Lees dit eens:
http://thevarguy.com/open-source-application-software-companies/041614/coverity-scan-says-open-source-code-better-quality
Het geeft exact weer waarom jouw artikel beter niet zo geschreven was.
*huilt*
Dat er problemen zijn met een open source oplossing die wijd en en zijd verspreid zijn komt misschien wel door een verkeerde zuinigheid. Als het goedkoop moet is kwaliteit daar dus meestal als eerste slachtoffer van. Of we het hier nu over goedkope confectie hebben die onder erbamelijke omstandigheden door kinderen in elkaar genaaid wordt of software maakt niet veel uit. Stellen dat closed source niet dezelfde fouten kan hebben is dan ook hoogst discutabel omdat steeds meer code uit lage lonen landen komt. En voor wie het vergeten is, Microsoft had 13 jaar geleden met Nimda een soortgelijk probleem.
P.S.
En voor de open source evangelisten: het blijft door mensen geschreven, ouderhouden en gebruikte software!
@Jan – haha, niet betaald hoor. Heb alleen te vaak gehoord dat MS lek is en open source heilig verklaard. Ik nuanceer dat alleen maar. De conclusie die ik trek geldt voor zowel closed als open source. Alleen als er iets gebeurt in close source is gemakkelijk de zondebok aan te wijzen. Bij open source is de zondebok “geldgebrek”… Duh.
@Gijs
Ik zal niet beweren dat MS lek is, dat was het, sinds windows 7 is dat bijna geen thema meer.
De vooroordelen naar beide kanten zijn achterhaald. Open source is al lang niet meer synoniem met gratis en wordt meest onderseund door grote firmas.
Dat linux van grote firma’s ondersteund wordt is hier te zien.
http://www.linuxfoundation.org/news-media/announcements/2014/04/amazon-web-services-cisco-dell-facebook-fujitsu-google-ibm-intel
En wat heartbleed betreft, net als bij proprietary software dempt men de put als het kalf verdronken is.
Overigens ben ik geen open source evangelist, ik gebruik beide proprietary en open source, de kunst is de juiste oplossing voor een gegeven probleem te kiezen en niet de ogen sluiten voor een van beide.
Voor de goede lezer zal hopelijk duidelijk zijn dat de essentie van het verhaal niet in open vs. closed source zit. Speldeprikjes uitdelen is echter altijd leuk 😉 Maar lees vooral de laatste paragraaf goed, want daar draait het artikel om. Verdere inhoudelijke reacties die niet over closed vs. open gaan zijn meer dan welkom.