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.
Nou Pieter jij maakt je niet populair bij de gelovigen die in open source het wonder zien, ik zie mogelijkheden maar niet in al je suggesties. Zo zijn afhankelijkheden (dependencies) één van de uitdagingen in de toeleveringsketen welke we als stack zouden kunnen definiëren. Ik ben voorzichtig want definities kaderen iets en daarmee krijg je direct een loket welke als vesting verdedigd wordt. Tenslotte is applicatie X/Y vaak onderdeel van systeem Z welke draait op platform B welke door C beheerd en A van afhankelijk. Kortom, je hebt helemaal gelijk alleen hebben we in Nederland al jaren een beheermodel waardoor het hier in de polder net Venetië is met Machiavelli als gondelier.
Aangaande het verdeel & heers heb ik als eerste al een probleem met de lifecycle van services en servers doordat we met het beheermodel van Looijen techniek en logica uit elkaar getrokken hebben. Dev(sec)Ops idee om agile te werken is leuk maar als de organisatie traditioneel volgens de hiërarchie van boven druppelt het en beneden regent het ingericht is dan krijg je personeelsprobleem aangaande de teams. En leuk of niet maar m.n. de technische IT-er is vlottende activa op de balans geworden met het uitbesteden van de techniek. Het is klooien met Looijen want met open source koop je planken en spijkers en niet de ’turnkey’ boot.
“Het dreigingslandschap rond opensource”, Dont look now, in Venice
spannend hoor.
De auteur heeft echter ook oog voor de luchtige kant.
Gewoon move to the left, ff alle source code van te voren checken, hahaha.
Omdat de beveiligingsteams overwerkt zijn voegen we gewoon Sec toe aan DevOps.
En apis met pipelines, nou als dat niet helpt weet ik het ook niet meer.
Weet je wat het is, als je in het gehele stuk het woord open-source vervangt met closed-source, dan leest het vrijwel hetzelfde…. op een detail na, je kunt niets controleren en je zult het maar van je leverancier moeten geloven dat ze hun werk goed doen…
SWA,
Er is één-op-één een vergelijk te maken is met closed source omdat zoals Dino ook al aangeeft de business de code toch niet leest. De business wil vooral functionaliteit en volgens Pieter maken 90% van de organisaties daarom compromissen als het om beveiliging gaat. Of zoals demissionair minister Ferd Grapperhaus een halfjaar geleden ontdekte worden de meeste beveilgingsupdates gewoon niet aangebracht omdat er een afweging van de risico’s gemaakt wordt.
Leuk ook nieuwe wetgeving leveranciers van met name consumenten oplossingen (SOHO) dwingt om de sluitpost beveiliging op te lossen maar wat betreft het compromis prijs blijkt naar mijn mening korting koning. Uit veilig, gemakkelijk en goedkoop mag je er dus maar twee kiezen want ik hoor Dino wel brullen op z’n eiland maar de business gaat echt niet terug achter het hek als het om de vrijheid van keuzen gaat. Aangaande de governance ligt het probleem dan ok niet zo zeer in de code zoals Ferd Grapperhaus ook al constateerde toen bleek dat beschikbare beveiligingsupdates gewoon niet aangebracht werden omdat organisatie zelf wel de risico afweging maken.
Oja, log4j raakt ook een heleboel commerciële oplossingen omdat iedereen op de schouders van reuzen staat dus als ééntje wankelt dan kent dit een grote impact. Hoe groot is de vraag die afhankelijk is van afhankelijkheden in de ketens welke nog moeten worden onderzocht omdat vele breiwerkjes zonder de governance van zoiets als configuratie management tot stand zijn gekomen. En idee om een soort van register te maken klinkt goed maar is waarschijnlijk als de modellen van Jaap van Dissel want zoals we kunnen leren uit het duidingsrapport van het Hof van Twente zijn we te goed van vertrouwen als het om het temmen van de papieren tijgers gaat. En de problematiek van de niet gecontracteerde (Shadow) IT zal ook alleen maar groter worden nu we massaal het thuiswerken uit hebben gevonden.
Spelevarend gaat de business hierbij van eiland naar eiland als een soort ontdekkingsreizer waarbij met de argeloosheid van een toerist omgegaan wordt met de bedrijfsdata. De code is tenslotte relatief eenvoudig vervangbaar maar zoals we nu steeds vaker zien de data niet, de code om deze te versleutelen is trouwens wel vaak geheim.
@dat oude lid
sjeezus…. lees je je post zelf nog wel eens? wat een hoop gebakken lucht!
SWA,
Leef jij niet op je eigen academische eiland waar goedkope NAS oplossingen nog ongekend populair zijn met reuzen zoals FTP en S(a)MB(a) voor de toegang tot data? Blaas niet te hard van de toren want aangaande compromissen is de onderhandeling achteraf een ‘show back’ als het gaat om de A4-tjes met gevonden kwetsbaarheden van devices die NIET de laatste updates hebben omdat ze niet op de inventarislijst stonden.
Je kunt mijn stellingen eenvoudig controleren door thuis eens te kijken op je internet router/switch om te zien hoeveel apparaten je thuis hebt met een verbinding naar het Internet. Vervolgens moet je kijken welke een open source oplossing hebben. Het ‘smart’ maken van apparaten levert namelijk de updateritis op welke uiteindelijk om een onderhoudscontract met de leverancier gaat.
Business op eiland, swa en dino op eiland.
gelukkig behoudt oudlid nog het overzicht 😛
90% van de it beslissers sluit compromissen, als het overal om gaat.
die 10% ook, waaronder pieter de cto.
hier dapper schreeuwen maar op zijn werk is het natuurlijk ja en amen tegen de business die met hun swot analyes geen zin heeft om te wachten tot al die devsecbusops pipelines eindelijk beetje draaien.
wel herkenbaar want als ik op mn werk net zo irri was als hiero …
Wat betreft het trekken van de verkeerde conclusies heb ik niet gezegd dat ik het overzicht heb, allesbehalve zelfs want ik wijs juist op het feit dat je niet kunt beheren wat je niet weet. Repelsteeltje noemde dat dan ook het verschil tussen beheerbaar en beheersbaar oftewel onderhoud versus controle want governance gaat om de bestuurlijk/juridische kaders zoals contracten.
De Titel van Pieter is wat we FUD noemen.
Niet helemaal Jan want hoewel ‘Fear Uncertainty & Doubt’ het altijd goed doet als agitprop raakt Pieter daarmee zeker ook een aantal snaren als het om zorgen gaat. Wat betreft klepelmechanisme van Japie werkt contentmarketing van storytelling optimaal als je het orgel van de emotie weet te bespelen, aangaande de rode vlag ben je trouwens nog laat met je reactie.
Wel een voorspelbare reactie want de ‘updateritis’ is zeker relevant bij open source en of ik te goed van vertrouwen ben met de maandelijkse cyclus van Microsoft zoals SWA beweert versus de dagelijkse weet ik niet maar zijn stelling is vooral een mening die de onderbouwing van herkenbare voorbeelden mist:
https://veiliginternetten.nl/doejeupdates/
Ik gaf een pragmatische shortcut in reactie van ‘meten is weten’ op consumenten niveau als het om het belletje voor het verwittigen over updates gaat in met name embedded OSS in consumenten oplossingen. Wat betreft laag 8 van OSI model is het namelijk eerder de onwetendheid op het eiland – of planeet.