Black Duck Software maakt auditing-software voor open source-beveiliging en volgens diens jongste risico-analyserapport zijn bedrijven erg slecht in het patchen van open source-software. Het bedrijf vond open source-componenten in 96 procent van de vorig jaar gescande bedrijfsapplicaties, met een gemiddelde van 257 open source code-elementen in elke applicatie.
Open source groeit flink
Het gemiddelde open source-aandeel in de codebase steeg vorig jaar verder van 36 naar 57 procent, een behoorlijke toename in een jaar tijd. Veel applicaties bevatten nu meer open source dan propriëtaire code. Het nadeel is dat 78 procent van de onderzochte code ten minste één kwetsbaarheid bevatte en er was een gemiddelde van 64 bekende exploits per codebase.
In Internet of Things is 77 procent van de code open source, en de audit vond gemiddeld 677 kwetsbaarheden per applicaties. Er werden meer dan 4800 gaten in open source-software gemeld in 2017, maar dat is over het hele spectrum van open source applicaties, library's en besturingssystemen.
Patching laat te wensen over
De schrijvers van het rapport merken een belangrijk verschil op tussen hoe patches worden behandeld binnen commerciële producten en open source software. In de eerste worden updates gepusht naar gebruikers. Bij open source is dat vaak niet het geval en dienen gebruikers handmatig te zoeken naar updates, of een updateprogramma in te zetten om te zoeken naar patches.
Omdat er zoveel belangrijke open source-producten in bedrijf zijn, denk aan ontwikkeltools, kan het een uitdaging zijn om alles wat je gebruikt in de gaten te houden. "Open source wordt toegevoegd aan codebases op verschillende manieren", staat te lezen in het rapport. "Niet alleen via third party leveranciers en externe developers, maar ook via interne ontwikkelaars."
"Als een organisatie zich niet bewust is van alle open source dat wordt gebruikt, kan het zich niet goed beveiligen tegen aanvallen op bekende kwetsbaarheden in die componenten."
Zo vond de software bijvoorbeeld open source webtoolkit Bootstrap terug in 40 procent van de onderzochte applicaties, gevolgd door jQuery in 36. Ook Lodash, een JavaScript-library, werd bveel gebruikt. "Lodash is het meestgebruikte open source-component in applicaties voor zorg, IoT, internet, marketing, e-commerce en telecom", zo schrijven de auteurs.
Gaten gedicht
Betekent dit dat jouw open source-applicaties bezaaid zijn met kwetsbaarheden? Als je patches goed bijhoudt waarschijnlijk niet. Het probleem dat dit rapport constateert is niet dat er geen patches zijn, maar dat ze niet worden toegepast in bedrijven en dat dit jaren zo doorgaat. Volgens Black Duck is de gemiddelde kwetsbaarheid zes jaar oud. Vier procent van de codebase bevatte nog steeds het high-profile Heartbleed-gat, dat vier jaar geleden volop in het nieuws was.
Black Duck verdient natuurlijk aan het verkopen van auditing-software, dus het is wat dat betreft geen verrassing dat het aan de bel trekt over kwetsbaarheden. Maar dat neemt niet weg dat er een duidelijk probleem wordt geconstateerd: niemand zou een applicatie zes jaar ongepatcht moeten kunnen laten in een zakelijke omgeving.
Iedereen moet wel kijken
Deze houding komt wellicht van het idee dat open source-software een eenmalige tijdsinvestering is: zet het in en vergeet het dan. Er was ook lange tijd een idee dat open source-code inherent veiliger is dan propriëtair, omdat iedereen er naar kan kijken. Maar Heartbleed bewees dat mensen dat dan ook wel moeten doen, want bedrijven hadden massaal code ingezet waar maar weinigen de moeite voor had genomen om deze grondig door te nemen om de twee jaar eerder verschenen bug te ontdekken.
Nou Andy, je hebt het zoals zoveel journalisten niet begrepen.. daar kun je niets aan doen want je hebt blijkbaar nog nooit met je enkels in het bluswater van de IT gestaan, maar doe dan ook niet van dit soort boude uitspraken.
Om het verhaal even recht te trekken, moet er onderscheid gemaakt worden in soorten van patching en soorten van applicaties.
1. Applicaties die door een commerciële leverancier worden aangeboden aan een klant. Het zou de klant en de IT'ers bij die klant niet uit mogen maken of daar wel/niet open source componenten in zitten. De applicatie wordt als bundel aangeboden, de leverancier is verantwoordelijk voor de integrale werking en veiligheid van het geheel. Daar eigenmachtig in gaan zitten patchen, is een recept voor rampspoed. Wie is in dit geval nalatig als de software lek blijkt te zijn: de aanbieder van de applicatie, niet de IT'er bij de afnemer. Doen alsof gebrekking patching in dit soort gevallen wél bij de IT van de afnemer hoort, is een levensgevaarlijke denkfout.
2. Open source applicaties zelf. Installeer je in je rol als IT'er een open source applicatie, noem eens een voorbeeldje: Apache. Dan neem je daarmee de verantwoordelijkheid voor de hele levenscyclus van die applicatie in jouw bedrijf op je. Dat heet beheer en is een functiegebied in het bedrijfsleven dat al sinds de jaren '80 een volkomen opgelost probleem is. Natuurlijk, er zijn bedrijven die weigeren erin te investeren en dat is laakbaar, maar élke applicatiebeheerder met ook maar de minste cursus in dit vakgebied achter zijn kiezen weet: het echte werk begint pas nadat de applicatie in productie is genomen en stopt pas wanneer het laatste exemplaar ervan is afgevoerd. Wie is er verantwoordelijk voor gebrekkig patchen van dit soort applicaties? In eerste lijn de beheerder die daartoe is aangesteld, en bij gebrek daaraan: de business-owner van het bedrijfsproces waarin de applicatie wordt gebruikt. Hierbij is overigens geen enkel onderscheid tussen open source of closed source, behalve dan de hogelijk theoretische optie die je hebt om als in-house IT'er zélf de code van een open source applicatie aan te passen. Het in productie draaien van dergelijke homebrew forks brengt je zo mogelijk nog sneller op de weg naar de hel, doe het niet! Breng je wijzigingen aan, zorg dan dat die upstream geadopteerd worden en installeer de upstream-versie met daarin jouw patches.. Homebrew-forks kun je alleen veilig doen wanneer je daartoe de volledige backing van hogerhand (en dus álle vereiste middelen en tijd) hebt om ze in stand te houden. Niet weggelegd voor een doorsneel IT-beheerafdeling.
Tot slot doet de auteur het voorkomen alsof patches een soort natuurwet zijn. Uitspraken als: "niemand zou een applicatie zes jaar ongepatcht moeten kunnen laten in een zakelijke omgeving." zijn nogal ongenuanceerd, om niet te zeggen wat dommig. Het is helemaal niet erg om een applicatie jarenlang ongepatcht te laten. Als er -ondanks veelvuldig testen- geen bugs in worden gevonden, waarom zou er dan aan een applicatie geprutst moeten worden? Dergelijke applicaties vind je in de machinekamers van veel grote bedrijven met regelmaat, en met de huidige push naar microservices ga je ze nog wel meer tegenkomen. Microservices doen op netwerkgebied hetzelfde als wat de UNIX-filosofie met OS'en deed in de jaren '70: kleine componentjes die heel goed zijn in wat ze doen. Op enig moment komt het voor dat dergelijke componenten functioneel voltooid zijn en geen bugs meer bevatten omdat alle permutaties van input/output bekend zijn. Dat software zonder bugs niet zou kunnen, is één van de grootste misvattingen die ik in de IT ben tegengekomen, meestal gepropageerd door lieden die zelf nog nooit een regel code in productie hebben geschreven. Vraag daarop door en er blijkt een vorm van 'magisch denken' achter te zitten, iets wat absoluut geen plaats heeft in dit vakgebied.
Reageer
Preview