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.
