2022 is het jaar van software supply chain security
Het versterken van de software supply chain moet prioriteit nr. 1 zijn in het nieuwe jaar. Hier zijn drie gebieden om op te focussen bij het verbeteren van de beveiliging van de softwaretoeleveringsketen.
Als 2020 het jaar was waarin we ons scherp bewust werden van de toeleveringsketen van consumptiegoederen, dan was 2021 het jaar dat de toeleveringsketen van software in ons collectieve bewustzijn opkwam.
In misschien wel de meest beruchte aanval van het jaar hebben duizenden klanten, waaronder verschillende overheidsinstanties in de VS, gecompromitteerde SolarWinds-updates gedownload. Helaas was SolarWinds niet de enige. De zwakke punten in onze softwaretoeleveringsketen waren inderdaad maar al te duidelijk met de recente Log4j-kwetsbaarheid. Log4j is een veelgebruikt open source Java-logging-framework, dus de kwetsbaarheid heeft tienduizenden applicaties (variërend van gegevensopslagservices tot online videogames) in gevaar gebracht.
Met vele slecht onderhouden code in productie, is de softwaretoeleveringsketen rijp voor exploits zoals de Log4j-kwetsbaarheid. Dit is een hot topic in open source omdat veel mensen licht onderhouden softwarebibliotheken gebruiken, ze in productie nemen en ze nooit meer patchen.
Hieronder volgen drie praktijken waarvan te voorspellen zijn dat ze in 2022 belangrijker zullen (en zouden moeten) worden naarmate organisaties werken aan het versterken van hun verdediging tegen aanvallen op de toeleveringsketen van software.
In het komende jaar en de komende jaren zouden bedrijven moeten nadenken over het standaardiseren en zorgvuldig inkorten van hun containerafbeeldingen, inclusief distro-elementen. Sommigen zouden zelfs zo ver gaan om te zeggen dat organisaties “distroloos” zouden moeten worden.
In het distroless-model zijn applicaties nog steeds verpakt in container-images, maar blijven alleen de minimale overblijfselen van het besturingssysteem over. Het idee is dat door zoveel mogelijk van het besturingssysteem te verwijderen (bijvoorbeeld door pakketbeheerders, bibliotheken en shells te verwijderen), het aanvalsoppervlak wordt verkleind.
Het is echter belangrijk om te begrijpen dat, net zoals er servers zijn in serverless computing, er distro’s zijn in distroless computing – er is gewoon minder een distro. En dit is misschien wel de echte waarde van het distroloze model, namelijk het bieden van het kader voor het zorgvuldig kiezen en kiezen van wat nodig is en wat niet, in plaats van lukraak te focussen op het verkleinen van een enkele containerafbeelding, terwijl ironisch genoeg het aanvalsoppervlak wordt vergroot vanwege een gebrek aan standaardisatie.
Software is nog nooit zo complex geweest als nu, en als je niet alles begrijpt wat je implementeert, krijg je problemen. Naarmate het gebruik van containers toeneemt, moeten organisaties goed nadenken over hoe ze container-images consumeren en implementeren. Met andere woorden, u moet een vertrouwd ding downloaden van een vertrouwde plaats.
Ik hoor je nu: “Maar dat zal me vertragen!” Ja, dat zal wel. Maar het idioom “een rotte appel” is van toepassing. Je kunt je kansen wagen, producten razendsnel uitrollen, en misschien komt alles goed. Of je kunt heel voorzichtig zijn, en langzamer, en vrij zeker dat je niet de volgende SolarWinds zult zijn (of Kaseya, of… je snapt het idee).
Sommige organisaties hebben zelfs een zeer gecontroleerde, bijna luchtledige omgeving als het gaat om het ophalen van software uit containerregisters. Andere bedrijven laten ontwikkelaars overal vandaan komen waar ze maar willen.
Als het gaat om de toeleveringsketen van containers, is het te gemakkelijk om een gehackt beeld naar voren te halen. Haal uw container-images bij een vertrouwde leverancier en/of zorg ervoor dat u elke afzonderlijke container-image in uw toeleveringsketen begrijpt (en helemaal opnieuw kunt opbouwen).
Verwacht is dat bedrijven SLSA gaan verkennen (en implementeren). Uitgesproken als “salsa”, staat SLSA voor supply chain-niveaus voor softwareartefacten. Het is een raamwerk voor het beschermen van de integriteit van de softwaretoeleveringsketen.
SLSA is gebaseerd op het interne Binary Authorization for Borg (BAB)-platform van Google, een interne controle op het afdwingen van de implementatietijd die is ontworpen om ervoor te zorgen dat productiesoftware en -configuratie correct worden beoordeeld en geautoriseerd. Google merkt op dat de acceptatie van BAB het risico van binnenuit helpt verminderen, aanvallen voorkomt en de uniformiteit van het productiesysteem ondersteunt.
Het doel van SLSA is volgens Google om de staat van de industrie te verbeteren door bescherming tegen bedreigingen, vooral in een open source-context. SLSA geeft softwaregebruikers ook gemoedsrust over de beveiligingsstatus van de software die ze gebruiken.
En gemoedsrust is tegenwoordig echt moeilijk te vinden. Als je hier nog niet nerveus over bent, bekijk dan dit citaat van Nick Weaver, een beveiligingsonderzoeker aan het International Computer Science Institute van UC Berkeley, en bereid je voor op koude rillingen over je rug: “Aanvallen van toeleveringsketens zijn eng omdat ze echt moeilijk zijn om mee om te gaan, en omdat ze duidelijk maken dat je een hele ecologie vertrouwt,” vertelde Weaver aan Wired. “U vertrouwt elke leverancier wiens code op uw computer staat, en u vertrouwt de leverancier van elke leverancier.”
Google heeft een SLSA proof of concept uitgebracht waarmee gebruikers herkomst kunnen creëren en uploaden naast hun build-artefacten, waardoor SLSA-niveau 1 wordt bereikt. Ik raad elk bedrijf dat software produceert – wat tegenwoordig vrijwel elk bedrijf is – aan om de proof of concept.
Organisaties hebben de afgelopen jaren veel meegemaakt en de toename van aanvallen op de toeleveringsketen van software draagt bij aan de uitdagingen als een waarschijnlijke uitbuiting van de door COVID-afgeleide toestand van organisaties. Terwijl bedrijven plannen hoe ze door en voorbij de pandemie zullen gaan, moet het beveiligen van de softwaretoeleveringsketen bovenaan de prioriteitenlijst staan.
Zonder die gemoedsrust kijken organisaties en hun klanten continu over hun schouder mee. Het hele idee van een keten is natuurlijk dat deze zo sterk is als de zwakste schakel, wat betekent dat geen enkele organisatie de softwaretoeleveringsketen alleen kan beveiligen.
Het zal het komende jaar belangrijk zijn om na te denken over strategieën en technieken, zoals hier beschreven, die u kunt toevoegen aan uw bestaande best practices. Dit soort continue gelaagdheid helpt organisaties om up-to-date te blijven in de strijd tegen software supply chain-aanvallen en om te voorkomen dat dergelijke aanvallen zelf onbewust worden verspreid.
We kijken altijd uit naar de volgende ‘zwarte zwaan’-gebeurtenis – de volgende onzichtbare dreiging die het systeem op zijn kop kan zetten en al het werk dat we hebben gedaan om het op te bouwen te vernietigen. Er is eigenlijk maar één algemene verdediging voor dit scenario: let goed op uw toeleveringsketen!
