Van vertrouwen tot constant in het oog houden: KubeCon trekt lessen uit Log4j

Opensource verenigt ontwikkelaars wereldwijd met elkaar. Dat geeft als voordeel dat mensen met diverse expertises en ideeën samen aan de best mogelijke code kunnen sleutelen, maar vraagt tegelijk veel vertrouwen. De Log4j-kwetsbaarheid eind vorig jaar toonde in extreme mate welke gevolgen een schending van dit vertrouwen heeft.   

Een programmeerfout in de populaire opensourcetool Log4j zette vorig jaar ondernemingen groot en klein in rep en roer. Waar de opensourcegemeenschap doorgaans een meedenkende groep ontwikkelaars bij elkaar is, werd met deze kwetsbaarheid nog eens duidelijk gemaakt dat ook in deze groep moedwillige mensen zich mengen.  

Nadat ze de kwetsbaarheid dichtten, blijven veel organisaties in het duister tasten over hoe dergelijke incidenten in de toekomst te voorkomen zijn. “We blijven natuurlijk alert voor nieuwe kwetsbaarheden maar voorspellen wat de toekomst ons zal brengen, is geen exacte wetenschap”, begint Kirsten Newcomer, Director DevSecOps Strategy bij Red Hat.

Daar valt iets voor te zeggen, maar uit fouten kan je wel leren. Al is het op KubeCon duidelijk dat bedrijven dat ook doen. Iedereen springt op de boot van veiligheid en wil zijn reddingsvest aanhebben om niet door een onopgemerkt gevaar te verdrinken. Beveiliging is het buzzwoord waar de DevOps-sector dit jaar rond werkt.

Er blijkt alleen geen eenduidig antwoord op de vraag hoe een nieuwe kwetsbaarheid met de omvang van Log4j kan worden voorkomen. Voorbereiden, ingebakken in het ontwikkelingsproces of achteraf ingrijpen: GitLab, Red Hat, HashiCorp en Deepfence houden er allemaal een andere visie op na.  

Pleisters op de blaren plakken

Red Hat leunt heel sterk op zijn opensourcegemeenschap om kwetsbaarheden aan te pakken. Volgens Newcomer is het niet zo moeilijk om veel vertrouwen in handen van deze groep ontwikkelaars te leggen: “Kijk hoeveel enthousiaste ontwikkelaars er hier rondlopen op KubeCon. Iedereen wil zijn steentje bijdragen aan de software waar zij van houden.”

Kijk hoeveel enthousiaste ontwikkelaars er hier rondlopen op KubeCon. Iedereen wil zijn steentje bijdragen aan de software waar zij van houden.

Kirsten Newcomer, Director DevSecOps Strategy bij Red Hat

Al weet Newcomer ook dat de Log4j-kwetsbaarheid nooit deze omvang had gekend als iedereen uit de opensourcegemeenschap even hard meewerkte. “De ontdekker van de Log4j-kwetsbaarheid plaatste zijn ontdekking vrolijk online in een tweet.” Zo werden de richtlijnen van responsible disclosure niet gevolgd en kregen hackers vrij spel.

Het vertrouwen heeft een deukje opgelopen, maar het begin van een slechtere verstandhouding met de gemeenschap bleek het in ieder geval niet te zijn. Nieuwe kwetsbaarheden blijft het bedrijf patchen na een seintje van de opensourcegemeenschap. Achteraf is het dan in snel tempo pleisters op de opgelopen blaren plakken. “Achteraf hebben we onze klanten wel kunnen helpen met Advanced Cluster Security om de codes te vinden die deze kwetsbaarheid bezaten.”

Constant monitoren

Al houden andere bedrijven er een andere aanpak op na. Kenny Johnston, Senior Director of Product bij GitLab, vertelt dat bij het bedrijf een gespecialiseerd team zich constant bezighoudt met het vinden van nieuwe bedreigingen. Op basis daarvan wordt de database constant bijgewerkt en kunnen ontwikkelaars veilig apps blijven uitrollen.

De visie van voortdurend monitoren draagt het bedrijf ook uit naar ontwikkelaars die met het platform aan de slag gaan: “Als een ontwikkelaar code schrijft, dan krijgt die iedere 10 à 15 minuten een melding of er beveiligingsrisico’s zijn gevonden. Die constante herinneringen zijn heel belangrijk want anders komt beveiliging pas in het laatste gedeelte van het ontwikkelen aan bod. Op dat punt weten ze al niet meer wat ze in de eerste uren codeerden.”

De beveiliging voortdurend in het oog houden, zorgt ervoor dat programmeerfouten een kleinere overlevingskans hebben. Dat is belangrijk om fouten zoals Log4Shell te voorkomen, waar in essentie een programmeerfout aan de basis lag van de problemen.

Met shift left-beveiliging leren ontwikkelaars zelf bij. Door een fout op het moment zelf te spotten, weten ontwikkelaars onmiddellijk dat het om een code-patroon gaat dat ze niet verder moeten gebruiken.

Kenny Johnston, Senior Director of Product bij GitLab

Volgens Johnston leveren ontwikkelaars bovendien niet in op snelheid door deze benadering. Zij kunnen zelfs meer plezier uit het coderen halen: “Bovendien leren ontwikkelaars iets uit de benadering om beveiliging op ieder moment in de gaten te houden. Checken ze de beveiliging op het einde van een project, dan weet je al lang niet meer in welke context dat kwetsbare stukje code is geschreven. Spotten ze de fout op het moment zelf, doordat ons systeem dat aangeeft, dan weten ze meteen dat het bijvoorbeeld om een code-patroon gaat dat ze niet verder moeten gebruiken. Dat noemen we shift left-beveilging.”

Roeien met de riemen die er zijn

Ontbreken de budgetten om dergelijke DevOps-tools bij gespecialiseerde bedrijven aan te schaffen, dan is het roeien met de riemen die er zijn. Owen Garrett, Head of Products and Community bij Deepfence, verzekert dat deze riemen ook voldoende kunnen zijn voor een goede beveiliging. “Het draait erom alle componenten en de software in productie op te lijsten zodat een ontwikkelaar terug kan zoeken als een kwetsbaarheid gevonden wordt.”

Dat klinkt in de bewoording van Garrett als een eenvoudige klus, maar met één keer noteren komen ontwikkelaars niet ver. “Ontwikkelaars noteren tijdens het bouwen. Dat heeft als nadeel dat de rapportering volledig verouderd is eens de onderdelen in productie gaan. Toch geeft deze methode een basis waarop ontwikkelaars kunnen verder bouwen als een kwetsbaarheid zoals Log4j wordt gevonden.”   

Dat zal dan wel ten koste gaan van de snelheid waarmee code wordt geschreven: een vervelende bijkomstigheid dat niet past in het DevOps-principe waar snelheid voorop staat.

Ademruimte geven

Erik Veld, Developer Applicate bij Hachicorp, ziet tot slot een rol weggelegd voor het zero trust-principe. Waar Log4j een tijdsgevoelige operatie was, geeft volgens Veld dit principe de nodige ademruimte aan ontwikkelaars om een programmeerfout te dichten. “Het zero trust-principe zou in ieder geval de impact van dit soort problemen heel erg limiteren want met Log4j was het zo dat je toegang kon krijgen tot andere systemen.”

“Traditioneel is het zo bij het opbouwen van een netwerk slechts een klein stukje de stempel van niet te vertrouwen krijgt. Alles achter die muur als het ware is vrij. Bij zero trust heb je geen muur waarachter alles te vertrouwen is, maar bouwt het netwerk eigenlijk op uit kleine kasteeltjes waarbij je altijd grenscontrole hebt.”

Log4j zal niet het laatste probleem zijn geweest dat in de opensourcegemeenschap opduikt, maar het incident zette de beveiliging wel opnieuw in de schijnwerper. DevOps-tools geven de beveiliging een meer prominente rol en ontwikkelaars zullen dat patroon moeten volgen.