Open source cms'en worden steeds populairder. Pakketten als Alfresco, Joomla, WordPress en Drupal worden steeds vaker ingezet voor interne en externe websites. Deze pakketten voldoen aan de criteria voor de volgende generatie cms'en, oftewel ze passen prima binnen Enterprise 2.0. Forrester (1) signaleerde in 2008 dat cio's serieus zouden moeten kijken naar met name Drupal en Alfreso. Een uitspraak die mede is gebaseerd op het feit dat de stabilteit en het aantal implementaties voldoende zijn om het als serieuze optie te overwegen, zoals later wordt toegelicht in een interview met CNET (2).
Zijn open source cms'en echter ook op security vlak enterprise waardig? Een artikel uit Informationweek dat vrijwel tegelijkertijd met het zojuist genoemde Forrester rapport uitkwam, zet een aantal kwetsbaarheden in verschillende pakketten op een rij voor onder meer Moveable Type, WordPress, Drupal en Joomla.
Toegegeven, niet elk lek is even ernstig, maar sommige toch zeker wel. Zo kwam er in Joomla 1.5.x vorig jaar augustus een lek aan het licht dat het mogelijk maakte om volledige controle te krijgen over het cms. Ook kon In versie 4 van Drupal relatief eenvoudig zelfgeschreven programmacode door internetgebruikers worden uitgevoerd dankzij een lek in basis van het systeem. Een analyse van de andere open source cms'en laat zien dat (ernstige) lekken daar net zo goed voorkomen.
Veiligheid in open source laat dus te wensen over. Vooropgesteld dat veiligheid geen exacte wetenschap is, kunnen er zeker een aantal nuances bij deze bewering worden geplaatst.
Zo is het aantal installaties van Drupal en Joomla aanzienlijk hoger dan van bekende closed source cms'en zoals Tridion, Green Valley of SiteCore. Daardoor wordt het een meer aantrekkelijke prooi voor hackers en raken lekken sneller bekend. Ook is het aantal modules bij open source veel groter. Voor Drupal zijn er duizenden modules en voor closed source cms'en gemiddeld minder dan vijftig. Doordat er meer modules zijn, is de kans dat er één een veiligheidslek bevat groter. Daarnaast is het gebruikelijk om veiligheidslekken snel bekend te maken bij open source, wat bij kleinere closed source cms'en ook minder aan de orde is.
Verder is het zo dat er een aspect is te benoemen dat zeer belangrijk is voor veilige (cms-) software. Dat betreft de integrale inbedding van reviews op code en anticipatie op mogelijke gevaren. Kortom: veiligheid is iets dat besloten moet zijn in de software ontwikkeling van een cms. Deze bevinding is ook te lezen in een rapport dat is geschreven over de veiligheid van Drupal. Hierin wordt gesteld dat securtiytraining van ontwikkelaars en het beschikbaar stellen van een eenvoudige api sleutelfactoren zijn voor een veilig systeem.
Nu lijkt het trainen van de ontwikkelaars lastig te organiseren voor de community van bijvoorbeeld Drupal. Dit is dus een punt van aandacht, wat dan ook geadresseerd is. Pakketten zoals Drupal en Joomla hebben een integrale controle op de veiligheid van alle modules door een verplichte review door een security team.
Na al deze punten op een rijtje te hebben gezet, kan denk ik worden gesteld dat een open source cms niet per se veiliger of onveiliger is dan een closed source cms. Immers, hoeveel veiligheidsissues lost Microsoft niet op in bijvoorbeeld Internet Explorer. En hoe veilig is SharePoint als cms nu eigenlijk? Als we hier op afgaan, lijkt het aantal security incidenten eerder een verband te hebben met de schaal waarop de software wordt toegepast , dan met het feit of het open of closed source is.
Met dat in het achterhoofd, is er toch nog een belangrijk verschil te benoemen. De verantwoorlijkheid ligt bij open source anders dan bij closed source. Waar bij closed source de verantwoordelijkheid voor de security meer bij de Vendor ligt, zal deze bij open source meer bij de implementerende partij liggen. Immers, de open source community kan moeilijk aansprakelijk worden gesteld als rechtspersoon. Dit kan met een system integrator echter wel.
Om deze verantwoordelijkheid goed te nemen zal de implementerende partij bij het gebruiken van cms-modules telkens extra moeten toetsen op security. Ook zal de integrator moeten controleren of modules zijn vrijgegeven door een security team, er een goede ondersteuning is en of er patches beschikbaar zijn.
(1) Forrester, 2008. http://forrester.com/Research/Document/Excerpt/0,7211,46162,00.html
(2) CNET, 2008. http://news.cnet.com/8301-13505_3-9973824-16.html
Ik ben het met de meeste reacties eens. Het is wel heel makkelijk om te zeggen dat open source niet veilig is. Vertel dat maar eens tegen die ict-afdelingen die apache http en linux op alle servers gebruiken.
Wat betreft CMS, tuurlijk zul je hier problemen vinden. Maar die vind je in closed source net zo goed. Veel van deze security problemen zijn gedeeltelijk te omzeilen door het CMS achter https te zetten of zelfs via vpn toegankelijk te maken.
Bij een CMS is er een groot verschil tussen de website die content uit de repository haalt en een CMS die voornamelijk gebruikt wordt om content in diezelfde repository te managen. Als je gewone gebruikers toegang geeft tot je volledige applicatie heb je altijd risico’s. De scheiding is bijvoorbeeld met een cms als Hippo (Nederlands en Open source) eenvoudig te realizeren.
Ik zou je stelling willen omdraaien, kun je veiligheid kopen middels een licentie? Of kun je veiligheid behalen door sources niet beschikbaar te stellen? Ik denk dat je beide vragen met een nee kunt beantwoorden.
Prima artikel. Het stelt dat open source pakketten een prima alternatief kunnen zijn, maar dat er een andere rolverdeling aan de orde is. Als je met degene die de implementatie doet geen expliciete afspraken maakt rond beveiligingstests e.d.(en dus ook aangeeft welke risico’s je wel en niet acceptabel vindt) en actie onderneemt op de resultaten daarvan, loop je risico’s. Deze zijn groter dan bij een ‘closed’ variant, aangezien de leverancier daar weet dat hij direct aansprakelijk gesteld kan worden als mocht blijken dat het pakket lek is.
“De verantwoorlijkheid ligt bij open source anders dan bij closed source. Waar bij closed source de verantwoordelijkheid voor de security meer bij de Vendor ligt, ”
Welk recht kan ik als klant ontlenen aan het feit dat een vendor ‘verantwoordelijk is’ als er iets fout gaat waardoor ik schade heb?
Volgens mij geen enkele en dit is dus een volstrekte wassen neus, schijnzekerheid voor onzekere IT-managers en inkopers. Behalve in specialistische medische en luchtvaart applicaties is er vrijwel geen software waar de leverancier aansprakelijk is voor de gevolgen van fouten. Hou dus op met dit soort onzin.
Wat een achterhaald artikel zeg.
Op 1 punt kan ik het met de schrijver eens zijn: Modules kunnen onveilig zijn, maar dat heeft niets te maken met OpenSource, maar simpelweg dat er niet goed genoeg naar gekeken is. De verantwoordelijkheid ligt dus bij de gebruiker, maar je mag er vanuitgaan dat dat een professional is die weet wat hij doet.
Helaas ontbreken een aantal goede systemen in dit lijstje;
metname Silverstripe (opensource) is een pakket dat bijvoorbeel een duur pakket als LiveLinkCMS (closedSource) heeft ingehaald op tal van punten.
Ook HippoCMS is best interessant (alhoewel wel ‘bloathed’)
– Alex
http://www.lxer.nl
Wie wel eens de moeite heeft genomen een licentieovereenkomst te lezen weet dat bij closed source de ‘vendor’ zelden of nooit aansprakelijkheid van enige betekenis aanvaardt. Juist op het gebied van leveranciersaansprakelijkheid wijken open en closed source niet noemenswaardig van elkaar af.
Alle open source software heeft een zekere mate van onveiligheid omdat er directe toegang is tot de broncode. Ofwel, het grootste voordeel is tegelijk ook het grootste nadeel.
Want tussen al die geweldige programmeurs die dag in dag uit aan een OS pakket werken, zitten ook kwaadwillende gebruikers.
Zo simpel is het. Hoe mooi het verhaal ook eromheen bedacht wordt, dit is een fundamenteel verschil!!!
Ook denk ik dat het verschil (kan) ontstaan door twee totaal verschillende typen opdrachtgevers. Zo zal een partij die kiest voor open source in de meeste gevallen meer voor budget gaan, dan een partij die kiest voor een closed source variant.
Partijen die veel geld neerleggen voor een closed source pakket, zullen doorgaans ook veel meer investeren in de veiligheid en het onderhoud en veeleisender zijn, wat ook volkomen terecht is.
Ter toevoeging op een reactie betreffende de CS licenties, is iedere leverancier in Nederland wettelijk verplicht een deugdelijk product te leveren. Ieder bedrijf of instelling kan een leverancier ten alle tijden aanklagen op grond van een wanprestatie, ongeacht de leveringsvoorwaarde die de leverancier hiertoe ook stelt. Vooral wanneer de licentiehouder hiervoor een X bedrag per periode in de vorm van licentie betaalt, zal deze zeer sterk staan.
@Michael,
Als een leverancier aansprakelijk zou zijn voor onveiligheden binnen een product, dan zou Microsoft allang failliet moeten zijn.
Bugs zitten in ieder product.
Michael heeft blijkbaar geen enkele kennis van open source producten en/of projecten, dan had hij namelijk wel geweten dat niet iedereen zomaar code kan inchecken wat ook nog eens ongetest in een volgende release terecht komt.
Waarom gebruikers van closed source software meer geld over zouden hebben voor beveiliging dan open source gebruikers, geen idee. Het is wel een feit dat bv. Windows vele malen onveiliger is dan Linux, onder windows heb je altijd superuser rechten, je bent wel verplicht om extra geld uit te geven.
Overigens zit het grootste veiligheidsprobleem achter de computer, de gebruiker. En die wordt zonder licentie geleverd.
Michael, ga je eens verdiepen in software en dan zowel open source als closed source. Verschil in licentie wil niet zeggen dat er zomaar een verschil is in veiligheid. Veiligheid kies je zelf voor en bij de meerderheid van de gebruikers (zakelijk en prive) ontbreekt iedere vorm van een veiligheidsbeleid. Denk jij nu echt dat de licentievorm van de software hier iets aan verandert?
@Paul Jongen:
Inderdaad. Herinner je het ’teardrop’ attack verhaal nog waarbij Linux binnen een paar uur gepatched was en dat het bij Windows zo lang duurde, dat providers routers maar de poort preventief dicht gingen gooien?
@Arjan Kamphuis:
Dit verhaal klopt ook helemaal. Rechtzaken kan je niet voeren als je bedrijf door de schade al failliet is verklaard. Die ‘verantwoordelijkheid’ is inderdaad een wassenneus en de beargumentering is zeer 90’s.
Daarnaast moet ik zelf een kant-tekening zetten, waarvoor wil je de CMS als bedrijf gebruiken?
Dit neemt niet weg dat een CMS veilig moet zijn.
Maar hetzelfde verhaal zou zijn; Theoretisch kan een werknemer via zijn desktop met de juiste exploits de meest gevoelige bedrijfsgegevens ontfutselen. Conclusie: Desktops zijn slecht! 🙂