In het eerste deel van dit tweeluik kijken we naar de kansen die open source security software biedt en positioneren we een security architectuur framework waarin security software geclassificeerd kan worden. In deel 2 wordt ingegaan op verschillende open source security software projecten genoemd in de building blocks van het security architectuur framework.
Nu en dan laait er een discussie op tussen security-experts over de veiligheid van open source software versus die van gesloten software. Voorstanders van open source zeggen hoe meer ogen gericht op de broncode hoe veiliger de software. Tegenstanders zullen zeggen dat de openheid van de broncode juist de risico's verhogen. Kwetsbaarheden zijn echter net zo goed in gesloten software te vinden. Deze komen ook naar voren zonder over de broncode te beschikken, bijvoorbeeld via reverse engineering of fuzzing technieken. Daarnaast zijn er regelmatig incidenten (Verisign, Symantec) waarbij broncode van software wordt gestolen.
Persoonlijk vind ik de argumentatie dat gesloten software veiliger is, omdat de broncode geheim is, berust op ‘security through obscurity' oftewel een ‘closed world assumption'. Het belang of de motivatie van de leverancier voor het hanteren van een closed source licentiemodel is mijns inziens meer gedreven vanuit het in stand houden van het huidige business model dan vanuit security. Conventionele software-leveranciers moeten wennen aan een commercieel open source business model. De nadruk van een dergelijk business model ligt namelijk veel meer op dienstverlening dan op licenties. De mate daarvan is uiteraard afhankelijk van het gekozen open source software licentie-model.
Conventionele software-leveranciers proberen tegenwoordig een commercieel open source business model te adapteren door acquisitie van pur sang open source software-projecten. Bijvoorbeeld het bekende MySQL door Sun (nu Oracle), maar ook specifiek in de security software-markt, bijvoorbeeld Metasploit (pen-testing) door Rapid7, SSL-Explorer (web-based SSL VPN server) door Barracuda Networks en OSSIM (SIEM) door AlienVault.
Laten we aannemen dat beide verschijningsvormen van software net zo veilig zijn. Dit artikel is een verkenning van open source security software om technische infrastructuur en applicatie landschap te beveiligen en te kijken naar de kansen die open source voor de afnemende partij biedt. Open source biedt mogelijkheden, weliswaar afhankelijk van het open source licentie model, om licentiekosten te besparen en de keuze om wel of niet support af te nemen.
Een mooie keuze-vrijheid; in acht nemende dat ict-budgetten in deze tijden van crisis onder druk staan en security budgetten in het bijzonder. Hoewel in menig organisatie dit laatste ook in goede tijden niet altijd recht doet aan de noodzaak ervan. Ook in niet-crisis tijden biedt open source kansen, de besparing op licentiekosten en supportkosten kan ten gunste komen van het customizen en afstemmen van software op de bedrijfsprocessen.
Security architectuur framework
Als referentiekader voor de te bespreken open source security software positioneren we het security architectuur framework (rechts), met layers en building blocks (security technologiën), waarin de security software geclassificeerd kan worden.
Het mag duidelijk zijn uit nevenstaand plaatje dat de open source community heel wat te bieden heeft in zowel de breedte als in de diepte met betrekking tot security oplossingen. In de praktijk wordt open source security software nog maar weinig meegenomen in pakketselecties of proof-of-concepts, waarin ze gezien het volwaardig alternatief dat ze vormen voor commerciële security software wel thuis horen. De integratie tussen verschillende soorten open source security software is uiteraard wel een uitdaging, hoewel veel open source security software dezelfde onderliggende componenten gebruikt. Deze integratie is echter ook een uitdaging bij de keuze voor een commerciële best-of-breed oplossing t.o.v. een commerciële best-of-suite oplossing.
Open source-projecten staan veelal aan de basis van succesvolle innovatie. Wanneer ze een volwassenheidsfase bereiken, zal het community product meestal aangevuld worden door een commerciële organisatie, die als dienstverlening bredere support levert, documentatie beschikbaar stelt en opleidingen verzorgt , en daaromheen een business model ontwikkelt. De belangrijkste waarde blijft echter overeind en dat is die van keuzevrijheid! Beperkt de commerciële partij die keuzevrijheid, dan staat er meestal een nieuwe community klaar om een aftakking te starten.
“Het belang of de motivatie van de leverancier voor het hanteren van een closed source licentiemodel is mijns inziens meer gedreven vanuit het in stand houden van het huidige business model dan vanuit security”
Natuurlijk is dit zo. Maar een leverancier kan ook niet zo maar de code weg gegeven want daar leven ze juist van.
Ik denk dat Capgemeni ook niet zo maar hun IP (intellectual property) bekend gaat maken en gratis gaat weg geven.
Tevens is mijn ervaring met Open Source dat het nog wel eens ontbreekt aan standaarden. En juist standaarden zijn op het gebied van security erg belangrijk. Aan de andere kant is Open Source wel weer erg dynamisch wat weer een groot voorbeeld is.
Laat ik maar met de deur in huis vallen door de vraag te stellen of we het hier hebben over Open source of Open sores?
Je stelt zelf al dat integratie van alle prachtige en ook kwalitatieve open source oplossingen nogal een uitdaging is. Dat komt misschien wel mede door het feit dat er binnen het open source domein nogal vaak ‘gevorkt’ wordt, er wordt een aftakking gemaakt door verder te bouwen op een eerder project. Dit zie je vooral bij de gratis oplossingen omdat er natuurlijk geen droog brood te verdienen is met iets wat je weggeeft. Nu is open source niet per definitie gratis en de verschillende licenties zijn ook nogal verwarrend. Een volledige securitystack, inclusief bijbehorende onderhoud, training en ondersteuning is dan ook niet per definitie goedkoper maar geeft waarschijnlijk wel meer zorgen.
Het is dan ook beter om open standaarden na te streven zodat niet alleen integratie eenvoudiger is maar ook vervanging van de builing blocks in het security framewerk. Hierbij gaat het niet zo zeer om open of closed source maar het maken van een complete stack die als het kan als enkele entiteit onderhouden kan worden om zo hoge beheerkosten te voorkomen. Vaak blijken beheerkosten bij open source namelijk ook hoger te liggen omdat je uiteindelijk een stukje maatwerk bouwt, niet zelden met niche producten speciale kennis nodig is. Als ik snel een vergelijk maak van genoemde producten met andere meer commerciele versies dan lijkt keuze van producten dan ook niet altijd ‘best of breed’ in het framewerk.
Goed, open source biedt de mogelijkheid om de code te controleren op fouten maar dat impliceert dat je eigenlijk ook zelf je oplossing kunt programmeren. Praktijk is dan ook dat veel bedrijven open source software net zo’n blackbox vinden als closed source waarmee er toch eigenlijk weer een vorm van ‘security through obscurity’ is. Als je een klein beetje reversed engineering zou doen van de closed source leveranciers dan zul je trouwens ook stukjes open source terug vinden in hun oplossing. Ze ‘vorken’ dus ook in plaats van opnieuw het wiel uit te vinden maar schrijven niet altijd met een vork omdat hun verdien- en kostenmodel gewoon vaak transparanter is.
@EDekkinga
Veel open-source software componenten in de security tak zijn juist innovatief, toonaangevend en worden juist ook als referentie implementatie gebruikt. Mede daarom worden ze ook vaak gebruikt door grote bedrijven als IBM, Oracle ea om toe te voegen in een totaal oplossing.
Het zijn juist de IT security bedrijven zelf die veel meer belang hebben bij gesloten oplossingen waarbij zij veel meer werk blijven houden als er zaken aangepast moeten worden. De makers van gesloten software weten dit heel erg goed en ondersteunen dit soort bedrijven dan ook extra met kortingen en technische assistentie.
Bedrijven zelf hebben dan vaak ook niet de moed om deze impasse te doorbreken en alsnog voor implementatie van open standaarden te eisen.
@Jan
Open source versus open standaard is een heel andere discussie. Zoals ik in mijn commentaar aangeef veranderd het wel of niet hebben van de broncode en de rechten om deze aan te kunnen passen in de praktijk niet zoveel. De bedrijven die hier het meeste van profiteren zijn vaak de ‘closed source’ software leveranciers door stukjes van deze code op te nemen in hun eigen oplossing. Want hoeveel gebruikers passen daadwerkelijk zelf de software aan of controleren deze op fouten?
Kwaliteit en betrouwbaarheid van open source wordt vaak eerder bepaald door de community die tijd en moeite neemt om de code te controleren. Daar zit dan ook, weliswaar een klein maar toch een zeker risico want een anonieme programmeur kan ook een ‘backdoor’ opnemen in de code. Zoek zelf maar eens op de steekwoorden backdoor en open source en je zult vast wel enkele voorbeelden tegen komen. Bij gebruik van open source moet je dus vooral goed weten wat de bron van je download is.
Terugkomend op open standaard is het tegenovergestelde proprietary, een stuk code waarop auteursrechten rusten en die alleen tegen betaling gebruikt mogen worden of waar een exportverbod op ligt. Iets wat met open source ook omzeilt kan worden zoals de wijze waarop PGP verspreidt is, door de code te publiceren in boekvorm. Dit is trouwens iets wat vroeger heel gebruikelijk was en programmeer-, druk- of typefouten moest je toen nog echt zelf opsporen wanneer compilatie stuk liep. Dat we vervolgens gecompileerde code uit gingen wisselen is uiteindelijk misschien wel de reden geweest voor het onstaan van virussen.
Stellen dat bedrijven niet de moed hebben om de impasse te doorbreken lijkt me eerlijk gezegd dan ook nogal moeilijk als we min of meer zelf dit systeem gemaakt hebben. Een systeem waarbij kennis en informatie het ruilmiddel is voor geld wat op zich zelf natuurlijk al een ruilmiddel is voor voedsel, onderdak e.d. Hoewel het artikel en de discussie hier niet over gaat denk ik toch aan de verspreiding van muziek, film e.d. waarbij auteursrechten ook geschonden worden. Bij artiesten zal uiteindelijk ook de kachel moeten branden en deze kunnen alleen iets weggeven als ze er op een andere manier weer wat voor terug krijgen.
Open source en closed source discussie vind ik net als een discussie over het geloof. De voor en tegenstanders zijn vaak behoorlijk bevlogen in de verdediging en aanval. Grappig is dat het niet verder komt dan geloven net als met echte religie.
Zoals Ewout zich terecht afvraagt: “Want hoeveel gebruikers passen daadwerkelijk zelf de software aan of controleren deze op fouten?”
Kijk ook eens simpelweg naar de praktijk. Hoeveel tijd en budget heb je om daadwerkelijk de diepte in te gaan om te kiezen voor pakket A of B? De keuze is vaker die van het realisatie team die de keuze verdedigd naar de (intern of externe) opdrachtgever.
En zekerheden heb je nooit. Je kunt voor oplossing B kiezen, maar als die over genomen word door een andere partij kan het wel eens een verkeerde kant op gaan. De keuze om in het geval van Open Source zelf een vork te maken lijkt mij een heftige en in veel gevallen niet geschikt.
beter hou je in de architectuur al rekening met veranderen security producten.