Managed hosting door True

De kijk van Van Eijk: Kletskoek

 

'Hoewel open source goedkoop lijkt en een soort gelijkheidsideaal en standaardisatie uitdraagt, ligt de broncode op straat en daarmee ook de kwaliteit, robuustheid en beveiliging en dus privacy', brabbelde een niet nader te noemen vertegenwoordiger in de software-industrie onlangs in Computable. Laten we er even van uit gaan dat dit correct geciteerd is en hij deze kletskoek zelf heeft gebakken.

Ik zal u de demagogie toelichten. Een zin die begint met 'Hoewel appels goedkoper lijken dan peren' zal uiteindelijk beweren dat appels duurder of slechter zijn. De vertegenwoordiger probeert hier dus te suggereren dat open source gevaarlijk is voor de privacy. 'Nee, gevaren voor de privacy willen we niet!' hoor ik u al denken. Maar wordt die bewering ook hard gemaakt?

'De broncode ligt op straat en daarmee ook de kwaliteit.' Alles wat op straat ligt is blijkbaar slecht. Maar het lijkt me juist goed als de kwaliteit zichtbaar wordt voor wie dat wil weten. Als je zin hebt in een hamburger wil je toch ook weten waar de beste ingrediënten worden gebruikt, en het schoonste wordt gewerkt? In het geval van open source kunnen we dan zelf kijken of de software wel een beetje onderhoudbaar is, of dat er een prutser aan het programmeren is geweest.

Als de broncode openbaar is, is daarmee dan de beveiliging in gevaar? Het woord code in broncode betekent alleen maar onbegrijpelijk, in tegenstelling tot het woord code in pincode. Als de versleutelingstechniek bekend is, hoeven de sleutels dat nog niet te zijn. Trouwens, in de beveiligingswereld leeft de overtuiging dat openbare beveiligingsmechanismen juist veiliger zijn omdat iedereen dan kan zien dat er niet bewust of onbewust lekken in zijn gemaakt.

En al zou de beveiliging ‘in gevaar zijn' doordat we de broncode kennen, is daarmee dan de privacy in gevaar? Ik denk toch niet dat dat serieus speelt bij de meeste populaire open source software zoals Open Office, Firefox en contentmanagementsystemen.

Kortom, kletskoek!

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/3215000). © Jaarbeurs IT Media.

?

 

Reacties

De argumentatie van de kletskoekenbakker(s) lijkt veel op eentje die die ik in de tachtiger jaren vond bij mijn eerste stagebedrijf. Aldaar had een programmeur iets gebrouwen wat zo obscuur en moeilijk leesbaar was dat alleen hij er nog iets mee kon. Op mijn vraag hoe dat moest worden onderhouden antwoorde hij "als het voor een ander niet leesbaar is, dan is ons intellectueel eigendom beter beschermd"
Security by obscurity: als ik er niets van begrijp, dan moet het wel heel veilig zijn!!

Als de broncode openbaar is worden eventuele lekken vaak sneller gevonden omdat er meer mensen inzicht in hebben. Dergelijke lekken kunnen daarom relatief snel gedicht worden of vaak kan een work-around gebruikt worden om de gevolgen van het lek te beperken tot er een update uit is.
Als de broncode niet inzichtelijk is zal een lek dus veel langer onbekend blijven voor de buitenwereld en kunnen beheerders zich er dus ook niet tegen beschermen.
Totdat er een patch is zullen kwaadwillenden dus vrij spel hebben...
Wat zou veiliger zijn ?

In afgelopen zeg 5 jr heb ik regelmatig artikelen gelezen over open source versus closed source beveiligings issues. In open source zou door iedereen gemakkelijker fouten gevonden kunnen worden en ook worden opgelost en in closed sources zou alleen de leverancier dit kunnen. Nu zien we dat bij open source de code vaak alleen door een beperkte groep gewijzigd wordt en dat zeker niet iedereen deze kan lezen of in staat is deze te veranderen. Bij closed source zijn er behalve de leverancier (die niet gebaad is bij security bugs in zijn software) ook derde partijen die de source code in mogen kijken fouten vinden. Volgens mij is het daarom lood om oud ijzer... Microsoft maakt er al jaren een wedstrijdje van tov linux om zo min mogelijk security patches uit te brengen. Maar in een security patch lossen ze vaak meerdere bugs op... En fouten die niemand kant zijn op dat moment ook niet gevaarlijk... totdat iemand deze vind. Verder zijn er hoe dan ook fouten in code... bij 1 fout per 10000 regels code heb je dus bij een OS met 50 miljoen regels code 5000 fouten. Bij 1 fout per 1000 regels code is dat 50000. Volgens mij hebben we dus nog een lange weg te gaan... die "Security by obscurity" heb je dus hoe dan ook.
Het gaat erom hoe het totaal plaatje eruit ziet en als je meerdere lagen van security hebt is de kans op een inbraak een stuk kleiner.

>> die "Security by obscurity" heb je dus hoe dan ook.

Er is een groep programmeurs met kennis en toegang tot de vrij beschikbare code (open source) en er is een groep programmeurs met kennis en toegang tot de closed source. Welke groep zou groter zijn?

Heb niet de illusie dat programmatuur veilig is omdat er niemand bij de code kan komen, dat is grote onzin. Bij open source heeft helemaal niemand deze illusie, de code ligt tenslotte "op straat".

De snelheid van patchen verschilt per project/leverancier, daar zijn (helaas) geen richtlijnen voor te geven. Ik ken voorbeelden van slechts enkele uren tussen het vinden van een bug en het patchen van deze bug, maar dat is (helaas) niet de norm. En ja, dit betreft open source.

Dit is wel heel kort door de bocht. Een veronderstelde mening weerleggen in een eigen stukje zonder weerwoord?

Dat open source per situatie voor- en nadelen heeft, weet iedereen. Zo ook in bovenstaand stuk. De vertegenwoordiger zet zwart, de schrijver zegt wit. De waarheid is grijs, zwart of wit.

Meest gehoorde probleem om source open te kunnen maken, is de moeilijkheid van het verdienmodel en
(on)mogelijheden met het vastleggen en controleren van (digitale) rechten.

@Robert: Heb je wat meer informatie over "de (on)mogelijkheden met het vastleggen en controleren van rechten" ? Waar doel je hier op en waarom zou dit spelen bij open source?

Het verdienmodel is geen enkel probleem, projecten zoals Apache, Tomcat en PostgreSQL bestaan al vele jaren en velen verdienen daar hun boterham mee. Dit zal niet opgaan voor alle projecten, maar heeft meer met het succes van een product te maken dan met de licentievorm.

Zelf kijken in de code? Dit gaan bedrijven die een stuk software willen gebruiken toch niet doen? Die willen iets kopen en iemand aansprakelijk kunnen stellen als wat ze gekocht hebben niet voldoet aan de (veiligheids)eisen.

Ze "moeten" hoe dan ook vertrouwen op degene die de software uitlevert, en ik kan goed begrijpen dat ze hun vertrouwen liever baseren op een leverancier, dan een onbekende groep programmeurs die nergens aansprakelijk voor zijn.

Open source is een prachtig iets, maar een ongenuanceerde uitspraak proberen te weerleggen met: je kunt zelf in de code kijken dus het is harstikke veilig...tja...

Vandaag weer te horen gekregen: "iedereen gebruikt X dus is het zeker goed". Dat X 2000 EUR kost en het FOSS programma 0 EUR, en dat X nauwelijks mogelijkheden kent te verbinden i.t.t. het FOSS proogramma wordt nauwelijks gehoord. Het argument dat je met FOSS onafhankelijk van een leverancier bent blijkt in de praktijk een argumant dat te komplex is omdat je dan over een wat langere tijd moet kunnen denken.

Ik ben bang dat de FOSS-luitjes wel intelligent zijn maar geen goede verkopers . . . . . , die kunnen namelijk kletskoek bakken.

@Rin, als het daarom gaat kunnen bedrijven nog altijd hun software betrekken van een bedrijf dat OSS levert. Je betaalt niet per definitie voor de software zelf maar voor de support. Is de support niet goed dan heb je in elk geval een partij om de schuld op af te schuiven.

Blijft het feit, je *kunt* in de software kijken hoe het is opgebouwd. Of je het doet of wil doen staat daar los van. Inderdaad, de meesten zullen snel weer iets anders gaan doen omdat ze de inhoud niet kunnen lezen of begrijpen. Gelukkig zijn er ook mensen die het wel kunnen. Dat zijn de mensen die de software maken en/of onderhouden. En velen daarvan werken ook nog eens in software onderhoud, soms zelfs bij de bedrijven die OSS leveren aan partijen die dat zelf niet kunnen of willen onderhouden.

Het gaat vaak om heel veel centjes en dan wordt alles uit de kast gehaald om het eigenbelang veilig te stellen. Maar het grootste euvel is nog steeds het 'technisch' management wat vaak geen flauw benul heeft waar ze mee bezig zijn en laten zich van alles aansmeren. De grote commerciele spelers weten dit donders goed en weet ze vaak zat te paaien.

@Berry

Tuurlijk, maar support is wat anders dan de maker zijn van iets. Je kunt ze aanspreken op hun support, maar niet op problemen in de software zelf of de fequentie van patches.

Ik zeg absoluut niet dat open source niet geschikt zou kunnen zijn voor bedrijven, maar ik ben het eens met degene hierboven dat het "kletskoek"-argument erg zwart-wit wordt gesteld. Er zijn wat mij betreft wel degelijk argumenten aan te dragen om, ook voor veiligheidsredenen, te kiezen voor closed software.

@Rin: Kom maar met de argumenten!

Aanspreken op support en frequentie van patches horen daar in elk geval niet bij, zie de leveringsvoorwaarden die 99 van de 100 keer de leverancier alle vrijheid geven en vooral geen verantwoordelijkheid. Oracle is bv. bijzonder spaarzaam met het geven van informatie over gevonden bugs, je kunt moeilijk inschatten of deze gevolgen hebben (gehad) voor jouw systeem. Oracle heeft er ook een handje van om bugs nogal lang open te laten staan, zie de vele artikelen en klachten hierover. Al lijken ze hier van te leren, vandaag is er weer een Critical Patch Update.

Uiteraard is dit column zwart-wit, daar is het een column voor, maar jouw reactie is van dezelfde kletskoek gesneden als waar de column over gaat ;)

@Rin,

Wij spreken IBM aan op de kwaliteit van de linux machines (lees, bugs, fixes, reguliere patches). Zij regelen het zelf of nemen dit op met Novell en/of de linux community, maar IBM blijft verantwoordelijk. Ongeacht of IBM nu wel of niet de maker van de software is. Als bijvoorbeeld een kernel fix niet wordt opgenomen in de mainstream kernel dan blijft de leverancier (IBM dus) verantwoordelijk voor die aanpassing voor zolang als de support op dat level geldig is/blijft.

Natuurlijk is het niet zo zwart-wit. Er zijn zeker argumenten voor closed source, net zo goed als voor open source. Dat gaat dan vooral om beslissingen mbt functionaliteit van een bepaald product. Veiligheidsredenen vallen m.i. niet per definitie in het voordeel uit van closed. Bugs vinden is niet zo moeilijk, zie het gemak waarmee vulnerabilities worden uitgebuit in welke software dan ook. Om dan te zeggen dat je veiliger bent met closed software is denk ik de ogen sluiten voor de werkelijkheid. Closed source is net zo (on)veilig als open source. Alleen bij OSS zien we welke bugs erin zitten, bij closed source wordt dat angstvallig stilgehouden.

Hier nog leuk verhaal over patchbeleid:
http://www.krebsonsecurity.com/2010/01/firm-to-release-database-web-server-0days/

Wel opvallend dat het vooral de closed source leveranciers zijn die hier worden genoemd.

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.