IT'ers veel te traag met patchen open source-code
Toename zakelijk gebruik enorm, maar patches blijven liggen.
We zijn te slecht in het patchen van open source-gaten in zakelijke software, zo blijkt opnieuw uit onderzoek. Kwetsbaarheden bestaan gemiddeld zelfs zes jaar nadat een patch is verschenen.
IT'ers veel te traag met patchen open source-code
We zijn te slecht in het patchen van open source-gaten in zakelijke software, zo blijkt opnieuw uit onderzoek. Kwetsbaarheden bestaan gemiddeld zelfs zes jaar nadat een patch is verschenen.
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."
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