Open Source CMS versus een proprietary CMS voor de enterprise

Als het om beveiliging gaat, zijn er grote verschillen tussen een content management systeem van een CMS leverancier en een open source CMS. Laten we het eens beter bekijken.

Kijk je naar het nieuws en voel je je tegenwoordig minder veilig?

Als je het nieuws volgt, heb je misschien verhalen over gegevensbeveiliging - of eigenlijk het gebrek daaraan - in een alarmerend tempo horen stijgen. Deze aanvallen worden geïnitieerd vanuit meerdere hackers bronnen en hebben invloed op verschillende platforms. Ze variëren van zorgwekkend tot verwoestend tot gewoon griezelig.

Als je op zoek bent naar een content management platform, lees je deze verhalen met bijzondere aandacht terwijl je jouw keuzes overweegt.  Je weet dat er meerdere opties zijn, en je zult al snel worden meegezogen in een debat over de voordelen van open source CMS-platforms. Open source-opties bieden flexibiliteit, vrijheid en zijn goedkoper (althans voor het softwaregedeelte van de implementatie), maar de factor beveiliging moet ook zwaar wegen in de vergelijking.

Open Source is een vrij recente ontwikkeling

Open source ontstond in de late jaren 1990 en introduceerde samenwerking in het softwarecreatieproces. Het was een belangrijke afwijking van de traditionele ontwikkeling waarbij programmeurs werden betaald uit de winst van softwarebedrijven en broncode werd bewaakt als intellectueel eigendom. Het creëren van een gemeenschap van ontwikkelaars en het gebruik van de code voor iedereen met een inbelbreedbandverbinding leek voor sommigen roekeloos, maar er werd beweerd dat de pure transparantie zorgde voor verantwoording, bugs onthulde en goed gedrag verzekerde. Hoewel de software effectief gratis was, kunnen de producten die ermee zijn ontwikkeld op de markt worden gebracht en verkocht. Tegenwoordig worden veel producten op deze manier geproduceerd met onderhoud en diensten die inkomsten creëren voor veel organisaties.

Hoe veilig zijn open source CMS systemen?

Het is een eerlijke vraag en je krijgt heel verschillende antwoorden, afhankelijk van wie je het vraagt. Het debat richt zich op twee belangrijke verschillen tussen open source en propriëtaire systemen. De eerste die we hebben aangestipt: toegang tot de broncode. Het tweede verschil zijn de programmeertalen die worden gebruikt om open source-oplossingen te ontwikkelen. Ze zijn verdeeld over verschillende opties, dus als we kijken naar de beveiliging van open source-systemen, moeten we rekening houden met de inherente beveiliging van de programmeertalen zelf.

Wie heeft toegang tot de code?

Open source content management systemen zoals Drupal, WordPress, Joomla en anderen worden over het algemeen gemaakt door een enorme gemeenschap van ontwikkelaars. Niemand heeft specifiek de verantwoordelijkheid om het systeem te beveiligen, maar aangezien elke ontwikkelaar een belang heeft, is de redenering dat kwetsbaarheden zullen worden opgelost zodra ze worden ontdekt. De ontwikkelaars worden gemotiveerd door toewijding aan het project en de kans om een reputatie op te bouwen in de gemeenschap.

Deze toepassing van eigenbelang en stammentaliteit wordt als energieker beschouwd dan monetaire compensatie. Bovendien lijken deze interne motivatoren niet gevoelig voor tijdsschaarste, budgettaire beperkingen of personeelsbeleid.

Content management systemen van softwareleveranciers zoals Adobe, Sitecore, Optimizely, Progress Sitefinity en vele anderen, stellen hun eigen ontwikkelaars alleen in staat om de code te zien en te wijzigen. Deze bedrijven beschermen hun investering door getalenteerde interne teams in te huren om hun product te ontwikkelen en te testen. Praktisch gezien zijn deze teams kleiner dan de open source ontwikkelaarsgemeenschappen, maar als werknemers, ondersteund door de formele structuur en beveiliging van een bedrijfsomgeving, hebben ze de ruimte om zich fulltime op het project te concentreren en te profiteren van de synergie van een teamstructuur.

In de praktijk bestaat geen van beide modellen in de zuiverste vorm. Open source CMS-ontwikkelaars zijn vaak professionele programmeurs die door bedrijven worden ingehuurd om aan open source oplossing te werken. Ze dragen bij aan het werk van de gemeenschap en verzamelen tegelijkertijd een salaris. Sommige verlichte bedrijven geven ontwikkelaars zelfs de tijd om aan nevenprojecten te werken, professionele ontwikkeling te bevorderen en misschien verkoopbare resultaten voor het bedrijf te produceren. Voorspelbaar is dat sommige van deze projecten open source zijn.

En hoewel open source CMS web developers duidelijk worden gedreven door passie, is het alleen maar eerlijk om erop te wijzen dat ontwikkelaars in loondienst die voor propriëtaire CMS-softwarebedrijven werken, ook voldoening halen uit hun werk. De beste programmeurs hebben een grote speelruimte voor wie ze zullen werken en zullen op zoek gaan naar de beste projecten.

Motiverende factoren zijn altijd een mix van vele elementen. Inderdaad, open source-gemeenschappen dienen ook als professionele netwerken met leden die zich aansluiten in de hoop hun verdienpotentieel te vergroten.

Hoe zit het met de verschillende programmeertalen die worden gebruikt om de platforms te maken?

Open source-ontwikkelaars gebruiken een aantal programmeertalen, waaronder PHP, SQL, MySQL, Java, JavaScript en Python, terwijl ontwikkelaars bij een CMS leverancier eerder geneigd zijn om ASP.NET met C # of Java te gebruiken.

De meeste verhalen over open source-kwetsbaarheden hebben de neiging om te impliceren dat de talen die door open source-ontwikkelaars worden gebruikt minder veilig zijn, maar het is niet zo eenvoudig. Websitehacks komen over het algemeen voor als gevolg van kwetsbaarheden in plug-ins en thema's, niet de CMS-software zelf.

LEES OOK: Waarom uw open source CMS je kan blootstellen aan kritieke beveiligingsrisico's

Professionaliteit, best practices en veilige ontwikkelingsfuncties

Belangrijker dan de gekozen taal, is de zorg en professionaliteit van uw ontwikkelteam. De waarheid is dat de goede programmeerpraktijken een veilig project zullen opleveren en dat slechte programmeerprocessen het tegenovergestelde effect zullen hebben.

Dat gezegd hebbende, sommige omgevingen zijn beter geschikt om goede praktijken af te dwingen. Microsoft's .NET Framework en .NET Core bevatten bijvoorbeeld functies die zijn ontworpen om te helpen bij veilige ontwikkeling. Teams die effectief plannen en vertrouwen op deze functies hebben veel meer kans om een veilig product te maken. Dat is een van de redenen waarom bedrijven als Progress zich inzetten voor .NET-ontwikkeling.

Interessant is dat Microsoft in 2014 de broncode van het .NET Framework heeft geopend en dat hun ontwikkelaarsplatform nog steeds open source is met de release van .NET Core. Microsoft deed dit om goede zakelijke redenen, door zijn ecosysteem te promoten en platformonafhankelijke ontwikkeling aan te moedigen. Het lijkt ironisch, maar versterkt in feite het idee dat open source in de juiste context grote waarde heeft. Maar de context is, zoals altijd, erg belangrijk.

En dat is mijn punt

Op de juiste plaats bevordert open source-ontwikkeling creativiteit en samenwerking, maar juist daarom worden de content management systemen die met open source-ontwikkeling zijn gebouwd kwetsbaar.

Beveiligingspatches en software-updates moeten met toewijding en regelmaat worden toegepast om elke creatieve hacker voor te blijven die misbruik zou maken van een kwetsbaarheid. Dit geldt ongeacht of het product open source of propriëtair is.

Bij CMS vendor eigen systemen wordt, wanneer een kwetsbaarheid wordt ontdekt, de wijziging in de code aangebracht en wordt de update vrijgegeven met een uitleg van wat er is opgelost. De kwetsbaarheid wordt enigszins verborgen door de geheimhouding van de code. Bij open source-systemen wordt de gewijzigde code echter vrijgegeven met de oplossing of tijdelijke oplossing. De bron van de kwetsbaarheid wordt blootgelegd en er kunnen snode aanvallen worden uitgevoerd op iedereen die de patch nog moet toepassen.

Als eerder vermeld, het is zelden het CMS zelf dat kwetsbaar is voor aanvallen, maar de plug-ins en afhankelijkheden die een website blootstellen aan een hack. Integraties in een systeem op bedrijfsniveau vereisen veel vaker complexe connectiviteit. Implementaties met meerdere integraties en een wildgroei aan gevoelige gegevens zijn mogelijk geen goede kandidaten voor geautomatiseerde patching. Om deze reden bieden CMS vendor eigen systemen een betere dekking door de reden voor de patch verborgen te houden voor het publiek.

Alleen al om die reden is de veiligste manier om bij elke CMS-implementatie op bedrijfsniveau te kiezen voor een  propriëtaire CMS, terwijl een ijverig patch beheerplan wordt gebruikt.

Meer bronnen

• Bescherming tegen de 10 meest kritieke webbeveiligingsrisico's
• Sitefinity CMS-beveiliging en best practices

Meer informatie over Sitefinity CMS