Top 25-fouten niet uit het hoofd leren

20 februari 2009
In een recent artikel in de Automatisering Gids (16 januari jongstleden) wordt melding gemaakt van een alarmerend rapport van het SANS Institute uit de Verenigde Staten over een top 25 van programmeerfouten die samen verantwoordelijk zijn voor een groot aantal beveiligingsissues. In deze bijdrage wil ik vanuit de invalshoek van softwarekwaliteit een aantal kanttekeningen maken bij dit artikel. Binnen het domein softwarekwaliteit wordt pas de laatste jaren ruim aandacht besteed aan het onderwerp beveiliging (zie kader). Maar, de aandacht die er momenteel is, richt zich op veel meer dan zwakke plekken in de programmatuur. Beveiliging is een onderwerp met veel aspecten, en een zaak van alle partijen in de ontwikkel- en beheerketen.

De aandacht voor programmeerfouten vanuit beveiligingsoogpunt mag (relatief) nieuw zijn, sommige fouten uit de top 25 zijn al tientallen jaren een punt van zorg. Improper input validation, het vermijden van race conditions, het voorkomen van buffer overflows, improper resource shutdown or release, improper initialization, iedere programmeur leert al jaren dat hij hierop bedacht moet zijn. Al is er wel een verschil met vroeger als het gaat om de gevolgen van deze fouten: toen werd alleen de gebruiker van de applicatie de dupe van een fout, nu wordt het hele systeem/netwerk waarop de applicatie draait bedreigd. Andere fouten zijn wel specifiek voor de voor iedereen toegankelijke netwerkomgeving waarin tegenwoordig veel applicaties draaien. Het zorgvuldig communiceren van paden en filenamen door een netwerk wordt van belang in een onbetrouwbare omgeving. Zwakheden in authenticatie en autorisatie zijn, als gevolg van de toename aan koppelingen en ontsluiting, nu veel meer bedreigend dan vroeger.
De lijst is een ‘top 25’, wat betekent dat er meer dan vijfentwintig zijn. De lijst is ook niet statisch; SANS heeft al aangekondigd regelmatig met een update te komen.

Moet iedere programmeur nu die lijst met vijfentwintig fouten uit zijn hoofd leren en zijn code permanent daarop controleren? Dat lijkt me niet. De meeste van de genoemde fouten zijn goed te detecteren met tools. En die tools kunnen wellicht een veel grotere lijst van fouten controleren. Een programmeur moet zich aanwennen om zijn code te controleren met deze tools.
Daarnaast geldt ook hier dat voorkomen beter is dan genezen. Dat vereist een manier van denken en werken waarin het bewustzijn van beveiligings­issues voortdurend aanwezig is. In het bekende software-engineeringboek van Sommerville staan tien ‘security design guidelines’ (zie kader). Deze richtlijnen kunnen prima gebruikt worden om een algehele benadering van beveiliging vorm en inhoud te geven.

Beveiliging is niet alleen de verantwoordelijkheid van de programmeur, maar van de hele keten van softwareproductie en -beheer. De opdrachtgever zal expliciet eisen moeten stellen. En dan bij voorkeur meer eisen dan een garantie dat de top 25-fouten niet voorkomen in de programmatuur. De projectmanager is ervoor verantwoordelijk dat tijdens het ontwerpen en bouwen van een systeem er voortdurend aandacht voor beveiligingsissues is. De beheerder zal een systeem alleen in beheer moeten nemen als aangetoond kan worden dat aan alle beveiligingseisen van de opdrachtgever voldaan is, en dat het systeem, eenmaal in productie, geen beveiligingsproblemen zal veroorzaken. De gebruikers van een systeem moeten weten hoe ze veilig met het systeem om moeten gaan, inclusief het gevaar van misbruik van vertrouwen (social engineering). Alleen als alle partijen zich inzetten voor een goede beveiliging ontstaat een sterke keten zonder (te) zwakke schakels.

Uiteraard heeft het onderwijs de taak om aankomende programmeurs te leren om veilig te programmeren. Daarbij zijn de fouten uit de SANS-top 25 belangrijk illustratiemateriaal. Maar belangrijker is het aanleren van bewustzijn op het terrein van beveiliging. Waarbij het vanzelfsprekend wordt dat je code checkt op beveiligingsissues, dat je op de hoogte blijft van de laatste ontwikkelingen. Waarin je je bewust bent van de verantwoordelijkheden van de verschillende partijen, van opdrachtgever tot gebruiker. Juist dat bewustzijn moet aangekweekt worden in het reguliere programmeeronderwijs. Specifiekere issues kunnen behandeld worden in aparte beveiligingsvakken.
Het werkveld – of het nu opdrachtgevers, IT-managers, programmeurs, beheerders of gebruikers zijn – is nauwelijks opgeleid op het vlak van beveiliging. Al is daar nu wel een grote inhaalslag waarneembaar; veel organisaties zijn zich (soms door schade en schande) zeer bewust van het belang van een goede beveiliging. Medewerkers krijgen bijscholing, een eigen security policy wordt opgesteld, processen worden ingericht om deze policy te bewaken. Het is zonder meer wenselijk om deze (bij)scholing intensief voort te zetten.

Maar, dan is er ook nog altijd die programmatuur die in het verleden gemaakt is. Zoals aangegeven in het kader, een verleden waarin het onderwerp weinig aandacht kreeg. Dat betekent dat er veel systemen in productie zijn die naar de huidige maatstaven onveilig zijn. Wellicht bevatten ze een of meerdere van de 25 fouten uit het SANS-rapport. Het uitvoeren van security-audits op de complete portfolio van een organisatie is een zeer omvangrijke operatie, zeker als er ook verbeterd/aangepast moet worden. Dat zal dus niet van vandaag op morgen gebeuren. Een meerjarenplan met goede prioriteitstelling, in het kader van een organisatiebreed beveiligingsbeleid, biedt hier wellicht een oplossing.

Jacob Brunekreef is als lector Softwarekwaliteit werkzaam aan de Hogeschool van Amsterdam (j.j.brunekreef@hva.nl). Tevens is hij senior consultant bij DNV-CIBIT.

Literatuur over beveiliging en softwarekwaliteit
Binnen de wereld van software is al vroeg (in de jaren zeventig van de vorige eeuw) sprake van aandacht voor beveiliging. Die aandacht richt zich dan vooral op privacy: bescherming van (de toegang tot) vertrouwelijke gegevens. Lange tijd was beveiliging het speelterrein van een groepje specialisten. Pas de laatste paar jaren ontstaat er brede aandacht voor het onderwerp. Dat is te zien in de literatuur. De kwaliteitsstandaard ISO 9126 (afkomstig uit de jaren negentig van de vorige eeuw) kent één subitem ‘Beveiligbaarheid’. Bekende boeken over softwarekwaliteit (Kan, Metrics and models in Software Quality Engineering, 2003; Heemstra et al, Softwarekwaliteit, 2001) besteden nagenoeg geen aandacht aan het onderwerp beveiliging. Maar, in een recent boek over testen (TMap Next, 2006) wordt vrij uitgebreid stilgestaan bij (het testen van) informatiebeveiliging.
Meer specifiek op het vlak van de kwaliteit van code zien we eenzelfde patroon. McConnell (Code Complete, 2004) besteedt nog nauwelijks aandacht aan beveiliging.
Spinellis (Code Quality, the Open Source Perspective, 2006) besteedt al veel meer aandacht aan secure programming. Veel van de fouten uit de SANS-top 25 worden in dit boek behandeld (!), naast tal van andere potentiële zwaktes in programmatuur.


Security design guidelines
Ian Sommerville (Software Engineering, 8th edition, 2007) presenteert tien ‘security design guidelines’:
  1. Baseer beslissingen op het vlak van beveiliging op expliciet beveiligingsbeleid. Daarin leg je vast ‘wat’ je zult doen, niet zozeer ‘hoe’.
  2. Vermijd een ‘single point of failure’. Een systeem moet niet direct helemaal vastlopen na het optreden van een enkel probleem.
  3. Faal veilig. Zorg dat, als een systeem crasht, er geen lek in de beveiliging ontstaat.
  4. Zoek een goed evenwicht tussen beveiliging en bruikbaarheid. Als je een gebruiker verplicht om een zeer complex wachtwoord te gebruiken, weet je zeker dat hij het ergens op gaat slaan.
  5. Wees bewust van de mogelijkheid van ‘social engineering’. De mens is veelal de zwakste schakel als het gaat om beveiliging. Wees bewust van het feit dat mensen relatief makkelijk, al dan niet na enige misleiding, vertrouwelijke informatie uit handen geven.
  6. Gebruik redundantie en diversiteit om risico’s te verkleinen. Het hebben van meerdere versies van software of data op meerdere plaatsen in een systeem maakt het systeem minder gevoelig voor falen.
  7. Valideer alle invoer die van buiten komt.
  8. Compartimenteer de toegang tot een systeem. Geef een gebruiker alleen toegang tot die delen van het systeem waar hij echt bij moet kunnen.
  9. Ontwerp voor gebruik. Houd rekening met de omgeving waarin een systeem gebruikt gaat worden.
  10. Ontwerp voor herstel. Zorg dat bij het optreden van een probleem gebruikers snel weer aan het werk kunnen.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Laat de klantenservice je terugbellen!