Het is nu ongeveer een jaar geleden dat Log4Shell de securitywereld op scherp zette. Een mooi moment voor een terugblik. Wat hebben we geleerd van Log4Shell? En hoe kunnen we de impact van zo’n ernstige kwetsbaarheid in de toekomst beperken?
In december 2021 kwam een serieuze kwetsbaarheid in de opensourcesoftware Apache Log4j aan het licht. Deze populaire loggingtool wordt veel gebruikt in webapplicaties en andere systemen. De kwetsbaarheid, Log4Shell genaamd, veroorzaakte een schokgolf in de securitygemeenschap. Securityexperts moesten snel handelen om hun kwetsbare applicaties te updaten, want Log4Shell werd al actief misbruikt voor cyberaanvallen.
Impact van Log4Shell
Op dat moment was echter onduidelijk welke applicaties onder de motorkap Log4j bevatten. Een hectische periode brak aan waarin organisaties hun gehele IT-landschap moesten nalopen op de aanwezigheid van Log4j. ”Er werd gevreesd voor een golf verwoestende cyberaanvallen”, vertelt securityonderzoeker Jordi Scharloo van KPN Security. “IT-professionals werkten dag en nacht door om hun organisatie hiertegen te beschermen.”
Een jaar later maken we de balans op. De doemscenario’s in de media zijn op het eerste oog niet uitgekomen. “Het aantal grote cyberincidenten lijkt mee te vallen, maar de totale impact is nog steeds moeilijk te overzien”, benadrukt Scharloo. “Zo weten we vaak niet hoe een cybercrimineel precies binnen is gekomen. Ook hebben we nauwelijks zicht op aanvallen via Log4Shell waarbij informatie is gestolen, maar die niet tot grote verstoringen hebben geleid.”
Lessons learned
De securityonderzoeker vindt het dan ook belangrijk dat Log4Shell niet vergeten wordt. “We zijn nog steeds sterk afhankelijk van opensourcecomponenten en het risico op ernstige kwetsbaarheden daarin blijft aanwezig.” Dit zijn volgens Scharloo de belangrijkste lessen die we uit Log4Shell moeten trekken:
1. CVE-systeem voor kwetsbaarheden werkt
Het CVE-systeem, een databank met informatie over kwetsbaarheden, bleek bijzonder effectief om organisaties in beweging te krijgen. “Aan Log4Shell werd de maximale score van 10 uit 10 toegekend. Dit duidt op een zeer ernstig veiligheidsrisico. Zo’n hoge score komt zelden voor, waardoor securityexperts direct in actie kwamen. Er is nog weleens discussie over het CVE-systeem, maar in dit geval droeg het absoluut bij aan een snelle respons.”
2. Solide basisbeveiliging betaalt zich uit
“Veel organisaties hadden wel een kwetsbaar systeem, maar dat kon niet uitgebuit worden omdat hun firewall op orde was. Zo zijn er nog meer basale securitymaatregelen die als neveneffect de impact van Log4Shell beperkten.” Scharloo denkt dat de AVG op dit vlak positief uitpakt. “Doordat de bescherming van persoonsgegevens verplicht is, zijn steeds meer bedrijven continu bezig met het verbeteren van hun IT-beveiliging. Dat verkleint ook het risico op incidenten die niks met persoonsgegevens te maken hebben.”
3. NCSC bewijst zijn toegevoegde waarde
Het Nationaal Cyber Security Centrum (NCSC) liet zich tijdens Log4Shell van zijn beste kant zien. “Het NCSC was heel proactief in de communicatie”, zegt Scharloo. “Zo kwamen ze vrijwel direct met praktische adviezen voor Nederlandse organisaties en hielden ze op GitHub een lijst bij met kwetsbare software. Internationaal gezien liep het NCSC echt voorop. Wat mij betreft heeft het NCSC hiermee zijn bestaansrecht definitief aangetoond.”
4. Inzicht in IT-omgeving is van cruciaal belang
“Log4Shell stelde ons reactievermogen op de proef. Sommige organisaties kwamen erachter dat zij geen goed overzicht van hun IT-infrastructuur hadden. Daardoor gaat tijdens een incident veel kostbare tijd verloren. In dat opzicht was Log4Shell een waardevolle oefening. Deze ervaring komt zeker van pas bij een volgende kwetsbaarheid. We zijn nu beter in staat om de impact te bepalen en kunnen ook sneller de juiste maatregelen treffen.”
5. Softwareleveranciers moeten ‘ingrediëntenlijst’ publiceren
Op een potje pastasaus staan alle ingrediënten vermeld. Ook voor software zou dit verplicht moeten zijn, vindt Scharloo. “Een Software Bill of Materials (SBOM) maakt het veel makkelijker om te achterhalen of software kwetsbaar is. De overheid kan dit afdwingen met wetgeving, maar organisaties hebben hierin ook een eigen verantwoordelijkheid. Zij kunnen via hun inkoopbeleid eisen dat softwareleveranciers transparant zijn over de technologie in hun producten. Eigenlijk zouden softwarebedrijven dit uit zichzelf moeten doen.”
6. Upgrade or remove it
Scharloo heeft nog een advies voor softwareleveranciers. “Kijk regelmatig naar de opensourcecomponenten in je software en update deze zo snel mogelijk. Is een stuk software niet meer nodig of krijgt het geen updates meer? Verwijder het dan of implementeer een alternatief. Het opschonen van deze technical debt is eenvoudiger dan bij zelf geschreven software. Ook kun je dit deels automatiseren, bijvoorbeeld door in het ontwikkelproces automatisch te controleren of er updates op GitHub staan.”
7. Meer steun voor opensource-ontwikkelaars
“Veel opensourceprojecten worden gerund door vrijwilligers. Zij stellen de software belangeloos beschikbaar en iedereen gaat ermee aan de haal. Een vreemde situatie, want die componenten worden gebruikt in cruciale bedrijfsapplicaties met een groot economisch belang. Het zou mooi zijn als er meer financiële steun komt voor deze ontwikkelaars waarmee zij hun technologie kunnen verbeteren. Daar profiteren we allemaal van.”
Wil je meer weten over cybersecurity? Meld je dan nu aan voor NLSecure[ID] op 26 september en laat je bijpraten over de meest actuele uitdagingen rondom cybersecurity.
NLSecure[ID]
