Open vs. gesloten code: wat is veiliger?

Leidt het openstellen van de broncode van software tot veiligere of juist tot onveiligere software? Deze discussie keert steeds terug wanneer het over open source software gaat. Door code open te maken kan iedereen de code inzien en aanpassen. Dit biedt welwillende programmeurs de kans om de software te verbeteren, maar kan ook saboteurs - al dan niet in dienst van vijandige mogendheden - aantrekken die zwakheden in de code willen uitbuiten of kwaadaardige code aan de software willen toevoegen. Toch hebben onder andere de Amerikaanse defensie en veiligheidsdiensten juist vanwege veiligheidsredenen een voorkeur voor open source software. Waarom kiezen deze partijen, waarvoor veiligheid en vertrouwelijkheid bij uitstek cruciaal zijn, voor open software?

Om deze vraag te beantwoorden is het belangrijk om de verschillende veiligheidsstategieën van het open model en het gesloten model te begrijpen. Waar het open model uitgaat van een open competitief proces om fouten te ontdekken, vertrouwt het gesloten model op het verschil in kennis tussen ingewijden en de buitenwereld. Beide modellen hebben voor- en nadelen en vereisen de vervulling van randvoorwaarden om tot veilige software te leiden.

Open model

Zoals twee ogen meer zien dan één, zien duizenden programmeurs over de hele wereld meer dan de programmeurs van een enkel ontwikkelteam binnen een bedrijf. Het open model gaat uit van de veronderstelling dat het doorlopend controleren en testen van de code door een grote groep ontwikkelaars (peer review) tot het beste resultaat leidt. Op deze manier kunnen fouten snel ontdekt en gecorrigeerd worden, wat zowel de veiligheid als de betrouwbaarheid van de software vergroot. Hierdoor is het ook moeilijker dan bij gesloten code om ongemerkt kwaadaardige code aan de software toe te voegen. Ook gesloten code kan namelijk gemanipuleerd worden door hackers. Het open model geeft iedereen bovendien de mogelijkheid om extra toetsingen van de code uit te voeren en de toetsingscriteria zelf te bepalen of hiervoor een professionele partij in te schakelen.

Het open model brengt alleen veilige software voort wanneer aan bepaalde randvoorwaarden is voldaan. Zo moet de code van goede kwaliteit zijn en moet de community actief en van voldoende gewicht zijn, zodat er voldoende reviews en tests worden uitgevoerd door deskundige programmeurs. Ook is het belangrijk dat ontdekte fouten binnen een korte termijn worden hersteld, wat bij open software vaak het geval is. Vanzelfsprekend dienen gevoelige gegevens gescheiden van broncode te blijven en goed beveiligd te worden opgeslagen. Tot slot komt het - net als bij gesloten software - vaak voor dat er verschillende versies van de software in omloop zijn, waarbij het belangrijk is dat een stabiele en uitvoerig geteste versie wordt gekozen.

Gesloten model

Het gesloten model gaat uit van de veronderstelling dat afscherming van de code een goede manier is om de veiligheid van software te waarborgen en vertrouwt in de eerste plaats op de expertise van het eigen ontwikkelteam. Doorgaans zijn leveranciers van gesloten software commerciële bedrijven met eigen programmeurs in dienst die in meer of mindere mate gebonden zijn aan instructies van hun leidinggevenden. De leverancier heeft zelf in de hand hoe vaak de code gecontroleerd en getest wordt en door wie. Bovendien bevatten de licentievoorwaarden vaak bepalingen die het derde partijen verbieden om de veiligheid van de software te toetsen, bijvoorbeeld door reverse engineering en openbaarmaking van analyseresultaten te verbieden. Uiteraard hebben leveranciers van gesloten software er belang bij dat hun software veilig is om gebruikers tevreden te stellen en reputatieschade door uitgelekte zwakheden te voorkomen.

Hoewel kwaadwillenden door de afscherming van de code in eerste instantie onwetend worden gehouden, is deze afscherming geen garantie dat succesvolle aanvallen worden voorkomen. Hackers kunnen op verschillende manier toegang tot gesloten code krijgen, bijvoorbeeld door een lek in de organisatie te benutten of door de beveiliging te kraken. Ook is het mogelijk om fouten in de code te ontdekken door het systeem van de buitenkant te analyseren. Uit de praktijk blijkt dat ook onbewuste fouten in gesloten software vaak lang onopgemerkt blijven. Toen de broncode van een relationele database van Borland (InterBase 6) open werd gemaakt, vond de open source community binnen 5 maanden een ‘hard-coded backdoor’ die al zeven jaar bestond.

Ook bij het gesloten model gelden een aantal randvoorwaarden om van veilige software te kunnen spreken. Ook gesloten code moet van goede kwaliteit zijn en voldoende gecontroleerd en getest worden door deskundige programmeurs. En ook voor gesloten software geldt dat ontdekte fouten binnen een korte termijn hersteld moeten worden. Ook hier is het belangrijk dat een versie van software is gekozen die zich bewezen heeft op het vlak van stabiliteit en uitvoerig getest is. Bij gesloten software is het doorgaans niet mogelijk om te controleren of aan deze randvoorwaarden is voldaan. Indicatoren voor de veiligheid van gesloten software zijn vaak de reputatie van de leverancier, het aantal gebruikers en de mate van gebruikerstevredenheid.

Conclusie

Instanties zoals de Amerikaanse defensie en veiligheidsdiensten kiezen vaak voor open software vanwege de voordelen op het gebied van veiligheid, zoals grootschalige peer review, een korte gemiddelde reactietijd bij fouten, de kleine kans dat kwaadaardige code onopgemerkt blijft en - wat voor de genoemde instanties van fundamenteel belang zal zijn - de mogelijkheid om de code zelf te (laten) controleren.