Log4Shell en de daaropvolgende kwetsbaarheden in Log4j resulteerden in slapeloze nachten. Deze loggingsoftware is vandaag de dag zo breed in gebruik dat de kwetsbaarheid nog maanden, of zelfs jaren, zal leiden tot dreigingen.
Als we niet snel actie ondernemen, dan kan Log4Shell het startschot zijn van een zeer onwelkome trend: een cyber-pandemie aangewakkerd door opensource-bugs. Het is een scenario dat tot nog veel meer zorgen kan leiden voor securityprofessionals, hun medewerkers en klanten. Log4Shell is zeker niet het einde van het verhaal.
De eerste van velen?
Log4Shell wordt gezien als een van de meest serieuze kwetsbaarheden in jaren, misschien zelfs allertijden. Zijn Common Vulnerability Scoring System (CVSS)-score van 10.0 stelt dat deze bug relatief makkelijk te exploiteren is. De bug werd gevonden in een veelgebruikte, op Java gebaseerde logging-tool. Deze tool kan lastig te vinden zijn in de eigen omgeving vanwege zogenaamde dependencies, die het uitvoeren van externe codes mogelijk maken. De initiële ontdekking werd snel opgevolgd door de ontwikkeling van vier extra kwetsbaarheden in hetzelfde pakket, allen met hun eigen, hoge kritieke niveaus.
De vraag is nu welke zero days zich in andere opensource-tools bevinden ? Neem opensource-gigant Apache, de beheerder van Log4j. Begin januari werd er een kritieke ‘Log4Shell-like’ bug gevonden in een populaire Java SQL-database, beter bekend als H2. Maar het lijkt erop dat in andere oplossingen ook kwetsbaarheden schuilgaan. Het aantal kwetsbaarheden dat wordt gevonden neemt nog altijd toe. 2021 was een recordjaar voor Common Vulnerabilities and Exposures (CVE’s). Dit is het vijfde achtereenvolgende jaar dat dat gebeurt, een zorgwekkende trend.
Devops-uitdaging
De uitdaging met opensource ligt in de manier waarop het gebruikt wordt. Software heeft de wereld overgenomen en tegenwoordig draait alles op code. Zonder code zouden de wereldeconomie en de samenleving zoals wij die kennen instorten. Dat betekent een almaar groter wordende druk op ontwikkelaars om snel nieuwe producten op de markt te brengen, vaak zonder deze uitvoerig te checken op security-gebreken. Het streven naar digitale transformatie zal deze trend doen versnellen.
Een manier om deze trend bij te benen, is via pre-built opensource-pakketten die beschikbaar zijn vanuit verschillende repositories. In 2021 vroegen ontwikkelaars meer dan 2,2 miljard opensource-pakketten op van de top vier ecosystemen: Java, JavaScript, Python en .Net. Het probleem is dat deze software soms al gebrekkige code bevatte, waardoor zij onwetend cyberrisico’s binnen de organisatie brachten via de achterdeur. Daarnaast is het zo dat opensource-toolsets over het algemeen minder vaak gepatched en geüpdatet worden dan commerciële software, wat hackers meer tijd geeft om kwetsbaarheden te vinden en te exploiteren. Dergelijke aanvallen zouden in 2021 jaar op jaar met 650 procent zijn gestegen.
Wat moet er gebeuren in 2022?
Een andere zorgwekkende trend is dat negentig procent van de it-beslissers claimt dat hun organisatie bereid zou zijn een compromis te sluiten op het gebied van beveiliging ten gunste van digitale transformatie, productiviteit of andere doelen. Dit moet echt veranderen. Het goede nieuws is dat organisaties helemaal geen compromissen hoeven te sluiten op de time-to-value vs. security. Met de juiste aanpak kunnen zij een veilige code hebben én hun producten op tijd leveren.
Een aantal suggesties om op dat punt te komen:
- Ken het software asset register, inclusief alle dependencies – welke database software draait er bijvoorbeeld achter applicatie X/Y?
- Begrijp het risico van elke applicatie – weet u echt wat de blootstelling van data per applicatie is, en wat de potentiële fallout is als gevolg?
- Wat is de laterale dreiging na een applicatie-inbraak? Kan het netwerk gesegmenteerd worden om het risico te verkleinen? Is een zero-trust-strategie zinvol om noodmaatregelen zoals reactieve netwerkremodellering te verminderen?
- Move to the left – beoordeel proactief code repositories aan het begin van de software lifecycle pipeline om zeker te weten dat u geen bekende kwetsbaarheden toevoegt. Zorg er daarnaast voor dat de beoordelingstools ook achteraf kunnen controleren op nieuw ontdekte kwetsbaarheden.
- Geautomatiseerde beveiliging in devops-pipelines integreren. Door integratie van beveiligingsmaatregelen in de devops-omgeving middels api’s is beveiliging onderdeel van de software ontwikkeling.
- Beveiligingsteams zijn al overwerkt, en het wereldwijde tekort aan talent voorspelt niet veel goeds gezien het toenemende aantal kwetsbaarheden, het toenemende cyberrisico en de overvloed aan tools.
De komende twaalf maanden worden waarschijnlijk drukker dan de twaalf maanden die achter ons liggen. Zolang het dreigingslandschap rond opensource zich blijft ontwikkelen, wordt het een wilde rit. Wel kunnen we actief aan de slag met het veiliger maken van onze systemen en de software die daarop draait.
@oudlid
Ewout, wie (F)OSS inzet voor zijn business moet zich toch minimaal informeren over de juridische randvoorwaarden, dat doet bijna niemand. Het graaien is erg gebruikelijk bij grote bedrijven en dan schreeuwen als het fout gaat omdat ze geen kontrolle gedaan hebben op die cruciale module die zo eenvoudig te kopieeren was.
(F)OSS is niet gratis, je betaalt met jou bijdrage aan de software, wie dat niet doet heeft het recht op mekkeren verloren.
Updateritis is een fenomeen dat bij bijna alle software voorkomt, van MS tot WordPress.
Dank Jan dat je het belang van contracten aangeeft, de civielrechtelijke kant speelt tenslotte ook bij open source als we kijken naar de governance van dit soort projecten betreffende de garantie. SLA’s, SLO’s en SLI’s zijn evenzeer contracten op sommige eilanden als ik kijk naar het doel van continuïteit in de toeleveringsketen. Hopende dat één plaatje meer zegt dan duizend woorden verwijs ik met de onderstaande link daarom naar 3 eilanden van Looijen die elk hun eigen perspectief hierin kennen:
https://www.computable.nl/artikel/opinie/beheer/3533724/1509029/klooien-plooien-of-looijen.html
Ik begrijp dat de inboorlingen op de eilanden graag de spiegeltjes en kraaltjes willen hebben maar hoe irritant Dino ook is hij heeft gelijk over de ‘devsecbusops pipelines’ doordat het uiteindelijk om een organisatorische paradigma verschuiving gaat. Tenslotte is er mede door een strikte opdeling tussen vragende (gebruikers) en aanbiedende (leveranciers) kant onbegrip ontstaan voor de problematiek in elk loket. En wat betreft de zeemeeuw die hard krijst, organisaties op de kop schijt en snel weg vliegt als het om het prespectief van onderhoud gaat is het hacken van de onlosmakkelijke koppeling tussen software en hardware bijzonder interessant als je kijkt naar de embedded oplossingen zoals kassasystemen;-)
Kortom, ik vind de titel prima en het verhaal prikkelend alleen de interactie van de auteur teleurstellend waardoor ik het idee heb dat hij ‘dood bier’ tapt.
@oudlid
Kassasystemen zijn tegenwoordig meestal windows-pc’s.
De “zeemeeuwen” vindt je ook bij kassa-systemen waar het belang van funktionerende backups “vergeten” wordt.
Jan,
Dat klopt, kasregisters en journalen moeten op de juiste wijze bewaard worden en ik denk dat je daarom een scheiding maakt tussen de data en het platform als we het over modulariteit en de frequenties hebben. Of de Windows PC nog dominant is als Point-of-Sale in de retail betwijfel ik omdat zo’n ‘fat client’ een overkill is als ik kijk naar draagbare RTOS oplossingen.