De kathedralenbouwers

Het schrijven van veilige code vereist kennis, gereedschap, solide omgevingen en adequate ontwikkelpraktijken. Daarnaast zijn de juiste instelling in het hoofd van de ontwikkelaar en samenwerking tussen specialisten cruciaal.

De informaticawereld heeft een lange traditie van vertrouwen in wondermiddelen om problemen op te lossen. Standaarden, ontwikkelmethodologieën en -omgevingen; ze moeten instantoplossingen brengen voor problemen als de productiviteit van ontwikkelaars, de kwaliteit van software en de veiligheid van programmatuur. Zelfs in omgevingen die voor veilig doorgaan met schitterende tools blijkt het toch mogelijk te zijn om onbruikbare software of onveilige programmatuur te ontwikkelen. Veilige software is immers ook een kwestie van inzicht, instelling en nooit aflatende waakzaamheid.

Overleg

Is het mogelijk om echt veilige software te ontwikkelen, met een bescherming tegen zowel bekende als nog onbekende dreigingen? “Dat is moeilijk, maar niet onmogelijk”, meent softwaregoeroe Ken van Wyk. “Al in 1975 publiceerden Saltzer en Schroeder een artikel over hoe een systeem tegen klassen van aanvallen te beschermen valt.”

Leesvoer Softwaregoeroes Ken van Wyk en Konstantin Beznosov noemen diverse lezenswaardige titels. Jerome Saltzer en Michael Schroeder: ‘The protection of information in computer systems’, 1975, http://www.cs.virginia.edu/~evans/cs551/saltzer/. Ross J. Anderson: Security engineering: a guide to building dependable distributed systems. Wiley, 2001. John Viega en Gary McGraw: Building secure software: how to avoid security problems the right way. Addison-Wesley Professional, 2001. Greg Hoglund & Gary McGraw: Exploiting software: how to break code. Addison-Wesley Professional, 2004. Ellen Ullman: The bug. Nan A. Talese, 2003.

Of een systeem ook voldoende is beschermd, is een andere kwestie. “Het is moeilijk te bepalen wat voldoende is”, aldus softwaregoeroe Konstantin Beznosov. “Daarom laat je software bij voorkeur verschillende ontwikkeliteraties doorlopen, met naleving van goede ontwikkelprincipes, tot zowel de klant als de ontwikkelaar tevreden zijn.” Of de resulterende software ook aantoonbaar conform wetgeving en reglementen is, ziet Beznosov meer als een rechtszaakrisico. “Het is aan de ontwikkelaars en de bedrijfsleiders om samen uit te maken hoeveel ze aan dat aspect willen besteden.”
Veilige software is dus wel te maken, luidt de boodschap, maar vereist overleg tussen alle betrokkenen – niet alleen ontwikkelaars en eindgebruikers, maar ook beveiligingsspecialisten. Veilige software ontwikkel je immers niet blindelings, evenmin “als je een bergen beklimt door gewoon de ingeklopte haken te volgen, zonder een kaart te lezen”, aldus vrijetijdsalpinist Beznosov. “Dan loop je het risico in een verkeerde vallei te belanden.”

Oude fouten

Om vanaf het begin de software in veilige banen te kunnen leiden, moeten de beveiligingsexperts voldoende betrokken worden bij belangrijke beslissingen. Ontwikkelaars moeten leren voorbij de functionele analyse te kijken naar de mogelijke gevolgen van opzettelijk misbruik of gestuntel, en van eventuele programmeerfouten. Ze moeten niet alleen weten wat een bufferoverloop of sql-injectie is, maar ook welke aanvallen op basis hiervan zijn op te zetten. Dat continue beveiligingsbesef is een noodzakelijke verandering in de instelling van de ontwikkelaar, benadrukken beide goeroes. Een ‘extreme programming’-aanpak met veel iteraties is overigens volgens Beznosov te rijmen met gegarandeerde beveiliging.
Van Wyk wijst erop dat softwarebouwers meer aandacht moeten besteden aan ‘best practices’. Programmeerfouten van dertig jaar geleden worden nog steeds gemaakt. Ook aan nalatigheden, zoals het niet of onvoldoende valideren van invoer, is geen gebrek. Blijkbaar is de softwarebranche nog niet goed in het analyseren en leren van gemaakte fouten. De neiging van de ontwikkelaar om zichzelf de das om te doen, moet je evenmin onderschatten, grapt van Wyk. Meer dan de helft van de kwetsbaarheden in software blijkt het gevolg te zijn van fouten in het ontwerp, en niet in de uitvoering, vult Beznosov aan.

Gewoon negeren Hoe maak je een systeem veiliger? Door fout gedrag niet te aanvaarden en daarom straal te negeren. Onder de naam ‘failure oblivious computing’ of ‘acceptability oriented computing’ bestuderen Martin Rinard en anderen dit idee aan het MIT. Zie ook: http://www.cag.lcs.mit.edu/~rinard/acceptability_oriented_computing/.

Het bouwen van software en het beheer van de softwareontwikkelinglevenscyclus heeft nog niet de duizenden jaren traditie van het metier van bijvoorbeeld een ontwerper of bouwer van bruggen. Het heeft meer weg van de betere en minder goede experts die samen al doende lerend kathedralen bouwen. De kennis, tools, solide omgevingen en adequate ontwikkelpraktijken die samen voor een betere kwaliteit van de software moeten zorgen zijn al beschikbaar. Daarmee is de eerste randvoorwaarde vervuld. Vervolgens is het een kwestie van doorgroeien en leren van de fouten, ook die op veiligheidsgebied. Wel is de impact van gebrekkige software tegenwoordig sneller en harder voelbaar. Dit betekent dat de software-industrie niet op zoveel leertijd als de bruggenbouwers mag hopen.

Nooit 100 procent

Bedrijven moeten beseffen dat hun software en infrastructuur nooit 100 procent veilig zullen zijn, net zo min “als een mens zijn hele leven lang gezond zal blijven of zelfs ooit volledig gezond is”, aldus Beznosov. Ook veranderen beveiligingsbehoeften samen met de prioriteiten van het bedrijf. Bovendien wordt de omgeving waarin toepassingen moeten functioneren steeds complexer. Niet alleen door internationalisering (met bijvoorbeeld complicaties bij de invoervalidatie door de vele vreemde talen en het gebruik van Unicode); ook de toepassingen zelf worden ingewikkelder als verzamelingen van componenten, webservices enzovoort.
Veilige software vereist dan ook continue betrokkenheid, zowel van onder af (vanuit de ontwikkelaar) als van boven af (de bedrijfstop moet de middelen goedkeuren en daarvoor zicht krijgen op het investeringsrendement). Die betrokkenheid moet concreet vorm krijgen, onder meer door serieuze inspanningen op het gebied van beveiligingstesten van nieuwe software en het auditen van bestaande toepassingen. Bij voorkeur doet de organisatie daarvoor een beroep op personen van zowel binnen als buiten het bedrijf. Vooral ontwikkelprocessen met veel iteraties vragen in een testaanpak om speciale aandacht. Extra aandacht voor de ‘herfabricage’ van software moet daarbij helpen. Verder moet nog een equivalent van ‘unit-testing’ bedacht worden voor beveiligingsdoeleinden. Ook is het moeilijk om te testen of een toepassing inderdaad niet de fout kan ingaan.
Kortom, veilige software ontwikkelen is een kunst die zelf nog in volle ontwikkeling is. Eén feit staat als een paal boven water. Bedrijven die in- en externe ontwikkelaars niet bewust maken van de behoefte aan veiliger software, helpen zich als onderneming gegarandeerd om zeep.