Zes securitymythes opensource ontkracht…en acht nieuwe uitdagingen

Critici van opensourcesoftare wijzen vaak op de hulp van grote aantallen ontwikkelaars en de open broncode als mogelijke veiligheidsrisico’s. Maar dat is geen eerlijke inschatting, volgens Ian Levy, technisch hoofd van de CESG, een onderdeel van het Britse veiligheidsapparaat dat overheidsdiensten adviseert op het gebied van IT-beveiliging.

Volgens Levy is opensource niet beter of slechter dan gesloten software wanneer het aankomt op beveiliging. Tijdens de conferentie Open Source, Open Standards in London ontkrachtte hij enkele bekende mythes en toont ons waar de werkelijke problemen liggen.

Mythes

Mythe 1: Opensourcesoftware is veiliger/minder veilig dan gesloten software
“Ik heb veel werk verrricht rondom dit onderwerp en er is geen objectief bewijs te vinden dat de een veiliger is dan de ander. Over het geheel genomen is goede opensourcesoftware ongeveer even veilig als propriëtaire software en dat gaat ook op als we over slecht ontwikkelde software aan beide kanten spreken.”

[related_article id=”161920″]

Mythe 2: Meer handen vullen meer gaten
“Het idee bestaat dat opensourcesoftware veiliger is, omdat er meer mensen zijn die kwetsbaarheden in de broncode kunnen opmerken. Zo zou de beveiliging aan een meer kritische blik worden onderworpen”, zegt Levy.

Maar kijken naar de code betekent niet meteen dat je ook kunt oordelen of een project daadwerkelijk veilig is. “Wie denkt dat hij competent genoeg is om de security te beoordelen van de Linux-kernel?”, zegt hij. “21 miljoen regels code downloaden en dan zeggen ‘Ik heb de code en ik ben er doorheen gegaan’, alleen om jezelf te overtuigen dat het veilig is, komt vaak neer op klinkklare nonsens”, vindt Levy.

Mythe 3: Slechteriken kunnen de broncode ook zien, dus het is minder veilig
“Opnieuw klinkklare nonsens. Als ik zie hoe mensen software kraken, gebruiken ze daarbij niet de broncode. Als je kijkt naar alle bugs in gesloten softwareprojecten, hebben de slechteriken ook de broncode niet, maar ze hebben wel toegang tot IDA Pro. Dat soort software is er nu eenmaal en het zal werken voor zowel gesloten als open projecten”, aldus Levy.

Mythe 4: Iedereen kan bijdragen aan de code, dus is het slechte kwaliteit
“Hoewel dit van toepassing is op sommige opensourceprojecten, is het tegenovergestelde het geval bij veel anderen”, zegt de veiligheidsexpert. Om dit risico te vermijden, kom dan eerst meer te weten te komen over het project in kwestie en de achterliggende historie en oordeel dan pas of je er in wilt investeren, beweert Levy.

Mythe 5: Opensource betekent dat het vrij te gebruiken is voor jouw organisatie
“Als software opensource is, betekent dat niet per sé dat er geen beperkingen zijn. Dat kan in de licentie zitten, of misschien zijn er beperkingen die niet relevant zijn voor jouw organisatie, maar dat betekent niet dat ze niet bestaan”, aldus Levy.

En zelfs als licenties geen probleem vormen, kunnen bedrijven te maken krijgen met conflicten rondom intellectueel eigendom, voegt Levy toe.

Hij noemt daarbij het voorbeeld van Hadoop, dat wordt aangeduid als opensourceproject. “Het is een gepatenteerd algoritme. Vergeet de implementatie gewoon. Want de implementatie mag dan geen intellectueel eigendom bevatten, maar het algoritme is wel degelijk gepanteerd. En weet je zeker dat je het dan kunt gebruiken?”, zegt de specialist.

Mythe 6: Alle software moet worden doorgelicht op security
“Dat zou krankzinnig zijn en toch blijven we dit maar horen. In overheidskringen moet elk stuk software worden geëvalueerd voor we het kunnen kopen, en het is nonsens”, verklaart Levy. “Alleen de functies die veiligheid uitoefenen, moeten worden doorgelicht.”

Uitdagingen

Uitdaging 1: Softwaredistributie
De online distributiemethoden die veel opensourceprojecten gebruiken zijn kwetsbaar, omdat het risico bestaat dat authentieke binaries vervangen worden door malicieuze code, zegt Levy.

“Hoe kunnen we vertrouwen op online distributie, wanneer een SHA-1 hash en een PGP-sleutel op dezelfde server staan?”, vindt hij. “Er zijn gevallen bekend van aanvallen op distributieservers, waarbij de broncode met rust werd gelaten, maar waarbij de binary, de MD5, de SHA-1 en de PGP-code rondom wel degelijk werd aangetast.”

“Je hebt het project gedownload en de hash gecontroleerd, maar je hebt de hash op dezelfde plek gehaald als de binary. Hoe kan ik die situatie vertrouwen?”, aldus de Britse adviseur.

Uitdaging 2: Patchen
Hetzelfde probleem voor distributie geldt ook voor de verspreiding van patches voor opensourcesoftware.

Levy: “Als ik naar Windows Update ga, weet ik dat een patch digitaal ondertekend is, en ik heb een proces dat werkt binnenin Microsoft. Wat weet ik van Red Hat? Veel, en daarom is het vertrouwen op eenzelfde niveau.

“Maar wat weet ik van ‘Ian’s Honest HTTP Server’-software? Je zult daarom eerst moeten onderzoeken om jezelf te kunnen verzekeren dat uitgebrachte patches fatsoenlijk worden gecontroleerd.”

Uitdaging 3: Zichtbaarheid van exploits
Levy: “Opensourcepatches moeten ook de bron vrijgeven. Ze maken daarmee vanzelfsprekend het onderliggende probleem bekend. Dus als ik een kwetsbaarheid heb en ik breng een binaire patch uit, kost het veel werk om het te ‘reverse engineeren’ om te ontdekken waar het product kwetsbaar is. Als het opensource is, breng ik een sourcepatch uit die mijn aanvaller exact vertelt wat het probleem is.”

“Dat is niet per definitie slecht, als je tenminste een verstandig patchbeleid hebt. Want dan is de tijd waarin een exploit kan worden misbruikt een stuk korter dan wat anders het geval zou zijn”, voegt hij toe.

Opensourceprojecten hebben ook personen en groepen die actief op bugs in de broncode jagen, waardoor ongerepareerde bugs sneller zichtbaar worden.

Levy: “Maar als die bugs openlijk zichtbaar zijn voor de hele wereld heb je weer een ander probleem, omdat je ineens 0-dayexploits hebt omdat er nog geen patch is.”

Uitdaging 4: De distributieketen doorlichten
Levy: “Hoe weet ik wie mijn code heeft geschreven? Hoe weet ik wat zij hebben geïmporteerd? En hoe weet ik dat er geen verborgen rottigheid in zit.”

Als een organisatie bijvoorbeeld te maken krijgt met geïmporteerde softwaremodules, kan een commercieel bedrijf besluiten om een team advocaten die code te laten doorlichten op licentieconflicten, terwijl ingenieurs zich bezighouden met eventuele bugs.

Levy: “Maar wie geeft mij dezelfde zekerheden als ik te maken krijg met opensourcesoftware? Wat kan ik zeggen over de legaliteit? Hoe weet ik of iemand heeft gekeken naar de licenties van geïmporteerde modules en de juiste afwegingen heeft gemaakt?”

“Ik wil niet zeggen dat dit onmogelijk is, maar ik vraag me wel af hoe het gedaan moet worden. Het is een hele nieuwe uitdaging”, zegt het hoofd van CESG.

Uitdaging 5: Botsende persoonlijkheden
Levy: “Persoonlijke conflicten kunnen een veel grotere impact hebben op een opensourceproduct dan bij een commercieel product het geval zal zijn. Een commercieel project heeft merkwaarde, terwijl een een opensourceproduct wordt aangedreven door een groep mensen.”

“Je hoopt dat hun neuzen min of meer dezelfde kant op staan, maar er zijn in het verleden ruzies geweest waarbij radicale koerswijzigingen zijn opgetreden in opensourceprojecten.”

Uitdaging 6: Verhoudingen tussen ontwikkelaars
Als je in staat wilt zijn de veiligheid van software goed te kunnen beoordelen, hangt veel af van de kennis die je hebt van de ontwikkelaars, waarbij het help om inzicht te hebben in hun toekomstplannen, beweert Levy.

“De veiligheidsevaluatie draait rondom de relatie met de ontwikkelaar en heeft minder met de broncode te maken”, zegt hij.

“Iedereen die denkt dat een evaluatie elke steen omkeert in zijn zoektocht naar eventuele kwetsbarheden heeft het bij het verkeerde eind. Het gaat om de grote lijnen. Als ik spreek over een evaluatie, bedoel ik meer: heeft de ontwikkelaar wel een flauw idee van waar hij mee bezig is?"

“Hebben ze een langetermijnplan om dit project veilig te houden? Hebben ze een noodscenario achter de hand voor incidenten?”

“De ontwerpstructuur uit code halen is ongelofelijk moeilijk. Als je geen goede relatie hebt met de ontwikkelaar, kun je geen vragen stellen als: ‘Waarom heb je het op deze manier ontworpen?’ Is dat niet het geval, zul je vaak een derde partij moeten inhuren om als bemiddelaar op te treden. En dat is een extra risico dat je onder controle moet kunnen houden”, aldus Levy.

Uitdaging 7: Identiteit van ontwikkelaar is zwak punt
Terwijl een commercieel bedrijf verschillende lagen in huis heeft die de identiteit van een ontwikkelaar kunnen bevestigen, kan het bij opensourceprojecten vaak verdraaid lastig zijn om zeker te weten met wie je te maken hebt.

“Voor sommige projecten is de enige manier van contacteren een Gmail-adres. Wie wil zijn hele securitybeleid riskeren voor een enkel Gmail-adres? Er zijn manieren om hier uit te komen, maar het is zeker iets waar je vooraf over moet nadenken”, zegt Levy.

Uitdaging 8: Gebrek aan standaarden en eenduidige infrastructuur security
“Ik kan een bedrijf onderwerpen aan een controle en zeggen: ‘Je hebt deze standaarden en je past ze toe. En ja, je hebt incidenten, maar je handelt ze goed af.’ Maar hoe doe ik dat met een allegaartje van ontwikkelaars die allemaal hun eigen hardware in huis hebben?”, vraagt Levy zich af.