Nieuws

Realiteit: software zit vol fouten

2x Aanbevolen

Gepubliceerd:10-03-2010 om 15:13 Auteur:Neil McAllister

Niet iedere software-onderneming krijgt te maken met fouten die zo ernstig zijn als de fouten die bij Toyota tot auto-ongelukken hebben geleid, maar één ding wordt wel steeds duidelijker: iedere software-leverancier levert zijn producten af met verborgen veiligheidsproblemen. Daarin zijn nagenoeg geen uitzonderingen.

Volgens een rapport van Veracode, dat op verzoek softwaretests uitvoert, ging bijna zestig procent van alle software die ze in de afgelopen 18 maanden hebben getest al in de eerste testronde onderuit. Roger Oberg, senior VP marketing bij Veracode, merkte op dat het daarbij notabene gaat om leveranciers die veiligheid belangrijk vinden – belangrijk genoeg om er een service als die van Veracode op los te laten.

De bevindingen van Veracode zijn niet uniek. Afgelopen jaar bleek uit een studie van WhiteHat Security dat 82 procent van alle zakelijke websites gedurende enige tijd minimaal één beveiligingsfout had in de categorie “hoog, kritiek of urgent”, en dat in 63 procent van de gevallen die bugs ten tijde van het onderzoek nog steeds bestonden.

Ik geef direct toe dat onderzoeken door beveiligingsconsultants niet bepaald onafhankelijk zijn. Toch is het verstandig hun bevindingen niet direct van de hand te wijzen. Als je het nieuws een beetje in de gaten houdt, zie je zelf ook hoe vaak er kwetsbaarheden worden ontdekt in belangrijke software-producten van erkende leveranciers. Onafhankelijke ontwikkelaars zouden wel gek zijn te denken dat hun eigen software het zoveel beter doet, om de simpele reden dat fouten nu eenmaal zo moeilijk te vermijden zijn.

Ontwikkelaars spelen ‘mep-de-mol’

Denk vooral niet dat alleen obscure en ingewikkelde fouten door de mazen glijden. Ieder jaar publiceert het SANS Institute samen met CWE een lijst met de 25 meest voorkomende en gevaarlijkste programmeerfouten. En net als in voorgaande jaren bevat de lijst voor 2010 weer een aantal instinkers, zoals onbewust gevoelige informatie vrijgeven via foutmeldingen, of ongelimiteerde uploads toestaan van gevaarlijke bestandsformaten. Maar de lijst staat ook propvol echte beginnersfouten, zoals race conditions, buffer overflows et cetera. Dat zijn fouten die al sinds de begindagen van het computerprogrammeren worden gemaakt; dat dit in 2010 nog steeds zo vaak voorkomt is verbluffend.

En toch zijn er ook aanwijzingen dat zelfs erkende best practices soms tot fouten kunnen leiden. In 2006 schreef Googles Joshua Bloch in een blog dat hij een fout had ontdekt in het binaire sorteringsalgoritme uit Jon Bentleys populaire standaardwerk “Programming Pearls” uit 1986. Het was niet Blochs bedoeling Bentley te kijk te zetten – in tegendeel. De binaire zoekcode die Bloch zelf voor de JDK had geschreven, bevatte dezelfde fout, en negen jaar lang was het helemaal niemand opgevallen.

Kunnen programmeurs dit voorkomen? Softwaretests, met behulp van dienstverleners als Veracode, kunnen inderdaad helpen, maar ook dat soort oplossingen zijn niet perfect. In sommige gevallen zorgt de applicatie architectuur of de programmeertaal ervoor dat grondig testen buitengewoon onpraktisch is.

Open source ontwikkelaars schuiven in dit soort discussies graag “de wet van Linus” naar voren, die iets zegt als: “als er maar genoeg mensen naar kijken, worden alle fouten ontdekt”. Oftewel: de transparantie van het open source software-ontwikkelingsproces betekent dat fouten in open source software eerder worden ontdekt en opgelost dan bij proprietary software.

Maar er zijn ook mensen die daar niet in geloven. Zoals Shawn Hernan bijvoorbeeld, security program manager bij Microsoft – voorspelbaar, zou je denken, maar hij maakt een goed punt. Volgens Hernan is het bepaald niet zo dat het simpele feit dat programmeurs toegang hebben tot code, er voor zorgt dat ze die code ook daadwerkelijk gaan controleren op bugs. Er zijn sterke aanwijzingen dat alleen programmeurs die ervoor worden betaald gemotiveerd genoeg zijn om andermans code te controleren. Als dat waar is (en ik denk dat het op zijn minst waarschijnlijk is), dan zijn het alleen de software leveranciers met de grootste budgetten (en daarmee de meeste programmeurs) die werkelijk profiteren van de wet van Linus.

Blijf communiceren

Met dit alles wil ik niet de indruk wekken dat de veiligheid van software moet worden opgegeven als een verloren zaak. Dat is het niet, maar het begint allemaal wel met de erkenning dat er een grens is aan wat je met code kunt doen. Het is de verantwoordelijkheid van iedere ontwikkelaar om code uit te brengen van de hoogst mogelijke kwaliteit – met de nadruk op “hoogst mogelijke”. Los daarvan moet de nadruk in de beveiligingsstrategie van software ontwikkelaars niet liggen in het ontwikkelingsproces zelf, maar in de manier waarop wordt omgegaan met de onvermijdelijke beveiligingsincidenten.

De dagen dat softwarepatches op cd’s en floppies werden nageleverd zijn al lang voorbij. Tegenwoordig verwachten klanten dat patches vrijwel direct nadat een gat in de verdediging is geconstateerd worden afgeleverd. Dat is praktisch gezien vaak moeilijk, maar leveranciers die lang wachten met dat soort patches, doen dat op eigen risico.

Let wel, de manier waarop leveranciers patches afleveren kan soms ook voor aardig wat problemen zorgen. Ooit leverde Microsoft patches af zodra die beschikbaar kwamen, ongeacht het tijdstip. Maar hun klanten begonnen te klagen dat ze op die manier voortdurend bezig waren patches te evalueren, waardoor er onnodig veel druk op de IT-afdeling kwam te liggen. Microsoft kwam vervolgens met de “Patch Tuesday”, tweemaal per maand. Ook die methode heeft weer tot kritiek geleid, met name vanuit de hoek die beweert dat een “Patch Tuesday” leidt tot “Exploit Wednesday”: de dag erop zouden hackers direct proberen slachtoffers te maken onder de gebruikers die de patches nog niet hadden ingevoerd.

Klanten zullen altijd blijven klagen over beveiligingsgaten en de noodzaak die te dichten. Wat ontwikkelaars het beste kunnen doen is zo open en eerlijk mogelijk zijn over beveiligingsproblemen met hun software, en de klanten die ermee te maken hebben zo duidelijk mogelijk te adviseren en te assisteren, ook als er nog geen patch beschikbaar is. Het alternatief is dat de cultuur van zwijgzaamheid en geheimhouding rond beveiligingsproblemen blijft bestaan, en dat is vragen om problemen.

Doordat bedrijven als Veracode en WhiteHat Security dit soort rapporten blijven leveren, dringt het langzamerhand tot gebruikers door dat we moeten leren leven met gaten in de beveiliging. Dat besef leidt ertoe dat klanten steeds vaker niet alleen patches eisen, maar vooral ook grotere openheid rond software beveiligingsproblemen. Het zal niet lang meer duren of software-bedrijven die geen openheid geven over fouten in hun software worden niet langer gezien als leveranciers met de beste apps, maar als de leveranciers die het meeste te verbergen hebben.