Log4j: Wat hebben we tot nu toe geleerd?

In een nieuwe blog bespreekt Hugo Leisink, specialist in informatiebeveiliging en privacy en senior adviseur bij NCSC, de recente ontwikkelingen rondom Log4J en de tot nu toe geleerde lessen. Zero Trust is onmisbaar voor een goede beveiliging, maar daar moeten nog grote stappen worden gemaakt. 

Ik hoor het mezelf nog denken op vrijdag 10 december. “Er zit een kwetsbaarheid in Log4j, maar er is ook al een patch beschikbaar. Wat is precies het probleem?” Nou, dat probleem werd al vrij snel duidelijk en dus mocht ik een groot deel van het weekend samen met collega’s aan het werk in het inmiddels opgerichte calamiteitenteam. Het waren lange en drukke dagen, ook voor velen buiten het NCSC. Maar met de gezelligheid van mijn collega’s en de goede zorg vanuit het NCSC had ik niets te klagen. Op de woensdag in de week erna mocht ik mijn zondag inhalen en gingen andere collega’s vanuit het calamiteitenteam aan de slag met de Log4j-uitdaging. Dat gaf mij tijd om eens rustig na te denken, want er is nu al heel wat te leren. 

Softwareontwikkeling

Eigenlijk best bizar, hoe een softwarefout tot zoveel gedoe kan leiden, maar tegelijkertijd verbaast het mij ook weer niet. 10 jaar geleden werkte ik in de softwareontwikkeling. Ik vind dat als je iets doet, je het goed moet doen. Met mijn hackers-mindset deed ik dan ook mijn uiterste best om veilige software te schrijven. Echter, ik merkte toen dat niet iedereen hier hetzelfde over denkt. Neem bijvoorbeeld het gebruik van open source repositories. Dit zijn websites waar je software-onderdelen kan downloaden om jouw applicatie met specifieke functionaliteit uit te breiden, bijvoorbeeld met log-functionaliteit. Dat scheelt tijd, want waarom code schrijven als anderen dat al gedaan hebben? Maar hoe veilig is die code van anderen eigenlijk? En welke ongewenste functionaliteiten sleep ik daarmee mijn applicatie in? Ik was dus zeer terughoudend in het gebruik van open-source software. Maar genoeg ontwikkelaars die deze kritische houding niet hadden en, zoals gezegd, vooral het gemak zagen. Gezien de grootte van het Log4j-gebeuren, is er in de afgelopen 10 jaar blijkbaar niet zoveel veranderd. De Log4j-kwetsbaarheid is een knaller van een klassieke injection, nummer 3 in de OWASP Top 10. Bizar dat dit al die jaren onopgemerkt is gebleven, toch?

Asset-management

Eerder schreef ik in expertblogs al over de noodzaak van het hebben van zicht en grip op de beveiliging van informatie. Informatiemanagement als noodzakelijke basis voor informatiebeveiliging. De noodzaak van het hebben van zicht geldt eigenlijk voor alles binnen de ICT. Log4j laat echter goed zien dat we met z’n allen niet zo goed zicht hebben op wat we precies aan software hebben draaien. De vraag ‘Word ik hierdoor ook geraakt?’ is de eerste en meest gestelde vraag. En het antwoord daarop is nog steeds niet voor iedereen volledig duidelijk. De gebruikte softwarebibliotheken in een applicatie zijn niet het enige interessante aan je software. Ook informatie over gebruikte protocollen en bestandsformaten, de programmeertaal waarin de software is geschreven en de gebruikte compiler kan in de toekomst nuttig zijn, want ook daar kan een kwetsbaarheid in zitten die in de nabije toekomst ontdekt wordt.

Als je hier meer over wil weten, zoek op het internet dan eens op Software Bill of Materials (SBoM).

Assume breach

Een van de belangrijkste conclusies uit veel risicoanalyses die ik heb uitgevoerd is dat organisaties wel het nodige doen aan het voorkomen van een incident, maar te weinig aan het inperken van de gevolgen daarvan. Om in informatiebeveiligingstermen te praten, ze doen wel het nodige aan kans-verlaging, maar te weinig aan impact-verlaging. De beveiligingsaanpak die genoeg organisaties hanteren is de zogenoemde kasteel-aanpak. Dikke muren en een slotgracht aan de buitenkant, maar eenmaal binnen kan je redelijk vrij en ongestoord rondwandelen.

Neem een webapplicatie als voorbeeld. Aan de voorkant hebben we een web application firewall (WAF) en de logbestanden van de webserver gaan in een SIEM. Maar hoe zit het aan de achterkant? Het is niet ongebruikelijk dat een webapplicatie een directe koppeling heeft met een database en dat de applicatie bepaalt welke database-opdrachten (SQL) er uitgevoerd worden. Heb je via een kwetsbaarheid zoals Log4j toegang gekregen tot de webserver waar deze webapplicatie op draait, dan is de kans zeer groot dat je daarmee vrije toegang hebt tot de database. De database-opdracht ‘geef mij alle data’ is dan mogelijk, terwijl dat een opdracht is die de applicatie zelf nooit zou geven. Waarom is dat dan mogelijk? Dat soort database-opdrachten gebeuren alleen maar bij datalekken of diefstal van gevoelige bedrijfsinformatie. Waarom zit er geen laag tussen de webapplicatie en de database die alleen dat mogelijk maakt wat nodig is? En als je dat goed doet, dan gebruik je voor die tussenlaag andere technologie dan die van de webapplicatie, zodat een hack op de webserver niet een hack op die tussenlaag betekent. Door middel van monitoring in die tussenlaag kun je je snel laten waarschuwen als de webapplicatie opeens buitensporig veel informatie opvraagt. Dit alles helpt voorkomen dat een incident ‘hack op de webserver’ uitmondt in ‘diefstal van volledige database met vertrouwelijke informatie’.

Deze aanpak, deze denkwijze, waarbij je uitgaat van dat interne systemen niet per se te vertrouwen zijn, is die van Zero Trust. Naar mijn idee is deze aanpak onmisbaar voor een goede beveiliging, maar ook dat we daar nog grote stappen in te maken hebben.   

Noodzaak

Aan de ene kant is er bij veel organisaties ruimte voor verbetering van hun cybersecurity. Aan de andere kant gaat het er bij goede beveiliging om of de te nemen maatregelen opwegen tegen het risico dat je ermee verlaagd. In de praktijk zal de kans op een incident daardoor nooit nul zijn en dat is prima. Dat betekent wel dat we ons naast het verbeteren van de beveiliging ook moeten voorbereiden op incidenten. Wat voor beiden hoe dan ook helpt is het hebben van zicht. Zicht op het netwerk, zicht op software, zicht op koppelingen, zicht op informatie en informatiestromen, zicht op welke bedrijfsprocessen afhankelijk zijn van welke informatie en vooral zicht op de risico’s voor de organisatie. Ja, dat is veel werk, vooral omdat we een inhaalslag te maken hebben, maar het is geen rocket science. Het is een absolute noodzaak en er is naar mijn idee geen goede reden om dat niet op orde te hebben.

Hugo Leisink