Elke beveiligingsleider bij een bank, verzekeraar of vermogensbeheerder heeft een versie van dit gesprek gehad: beveiliging wil een klasse van kwetsbaarheden elimineren. Engineering legt uit wat er nodig is om het platform waarop ze wonen te upgraden. Iemand prijst de regressietesten af. Iemand anders verhoogt de kalender voor het bevriezen van veranderingen. De bevinding krijgt een uitzondering, een compenserende controle en een datum van achttien maanden op de routekaart om dit aan te pakken.
Niemand in dat gesprek is onredelijk. De financiële dienstverlening beschikt om een aantal redenen over meer verouderde software dan vrijwel welke andere sector dan ook: tientallen jaren van opgebouwde infrastructuur, wettelijke verplichtingen die stabiliteit belonen, en toepassingen waarbij een uur downtime onaanvaardbaar is. In die omgeving moeten de veranderingen tot een minimum worden beperkt is risicobeheer. Elke afhankelijkheidsbubbel, elke basisimagewissel, elke migratie is een kans om iets kapot te maken dat transacties vereffent of geld verplaatst.
Het instinct om vast te houden aan de status quo was dus gezond. Het probleem is dat het instinct nu op het verkeerde probleem wordt toegepast.
Het hebben van een kwetsbaarheidsachterstand is niet langer “prima”
Jarenlang was het accepteren van een achterstand aan bekende kwetsbaarheden een gebruikelijke afweging die financiële dienstverleners maakten voor stabiliteit. De kwetsbaarheden waren bekend, maar sluimerend. Bovendien vereiste exploitatie vaardigheden, tijd, kosten en stimulansen. De kans dat een bepaalde algemene kwetsbaarheid en blootstelling (CVE) in een oudere applicatie tegen u zou worden ingezet vóór uw volgende geplande upgrade, was klein genoeg om eenvoudigweg te erkennen en verder te gaan.
Frontier-modellen hebben deze calculus drastisch veranderd. Systemen als Mythos kunnen code lezen, sluimerende zwakheden vinden en deze sneller aan elkaar koppelen dan mensen kunnen onderzoeken en patchen. De kloof tussen ‘publiekelijk bekende’ en ‘praktisch exploiteerbare’ kwetsbaarheden is aan het instorten, en dat gebeurt precies daar waar financiële instellingen uitgestelde risico’s hebben gedragen: de softwaretoeleveringsketen.
Voor het eerst in de geschiedenis heeft misbruik van kwetsbaarheden phishing ingehaald als de belangrijkste initiële toegangsvector voor inbreuken op de financiële dienstverlening. Bovendien beschikt meer dan de helft van de leveranciers van financiële diensten over ten minste één CVE met een hoge ernst. Voor een gereguleerde instelling betekent een gecompromitteerd pakket een operationele gebeurtenis, een gesprek over de regelgeving en een probleem met het vertrouwen van klanten.
Wat dit in de praktijk betekent: de achterstand was nooit statisch, maar de aannames die werden gebruikt om het dragen ervan te rechtvaardigen waren dat wel. Een uitzondering die achttien maanden geleden werd ondertekend, berust op een verouderd dreigingsmodel.
Het verschil tussen applicaties en de software supply chain
Als een beveiligingsteam zegt ‘we moeten moderniseren’, horen technische leiders dit modernisering van applicaties: herstructureer de monoliet, upgrade de runtime, migreer de datalaag, test alles stroomafwaarts opnieuw. Dat is een meerjarig, kapitaalintensief programma met meerdere teams en een reëel operationeel risico. Leiders in de techniek verzetten zich vaak tegen dit soort veranderingen – en hebben daar waarschijnlijk gelijk in.
Maar het risico dat grensmodellen met zich meebrengen, ligt niet in de eerste plaats in de applicatiecode. Het leeft in de softwareleveringsketen eronder: basisimages met veel kwetsbaarheden, open source-bibliotheken die uit openbare registers zijn gehaald zonder herkomst, en tools bouwen die nooit goed zijn geïnventariseerd. De invoer van de toepassing is blootgesteld.
En inputs kunnen worden gewijzigd zonder te herschrijven wat ze verbruikt.
Het actualiseren van deze gegevens is de voorzichtigere ‘modernisering’ waar veel financiële dienstverleners rekening mee houden. Het moderniseren van uw software supply chain vergt niet hetzelfde investeringsniveau als het moderniseren van uw applicaties. Wat je bouwt, kun je veranderen van lang voordat je verandert wat je bouwt.
Hoe dat eruit ziet zonder migratie
De aanpak van Chainguard is gebaseerd op het veiligstellen van wat u bouwt van. Geharde, minimale containerimages en open source-bibliotheken worden voortdurend opnieuw opgebouwd, zodat vermijdbare kwetsbaarheden überhaupt nooit in de omgeving terechtkomen. Minder componenten betekent dat er minder hoeft te worden gescand, minder moet worden beoordeeld en dat er minder aanvalsoppervlakte nodig is door middel van constructie in plaats van door herstel.
Voor software die nog niet klaar is om te worden geüpgraded, backporteert Chainguard beveiligingsoplossingen naar de versies die instellingen gebruiken Vandaag. Een team met een oudere taalruntime- of frameworkversie krijgt gepatchte en vertrouwde artefacten voor die versie. De compatibiliteit blijft behouden en het migratieplan blijft op zijn eigen schema.
Hoe dan ook, teams die oudere versies gebruiken, verminderen hun blootstelling aan kwetsbaarheden.
Voor platformteams is de operationele verandering kleiner dan verwacht. De meeste grote financiële instellingen beschikken al over een intern golden image-programma om de basis voor honderden applicatieteams te standaardiseren. Het onderhouden van deze beelden is traag en duur.
Maar wanneer platformteams de upstream-bron van die afbeeldingen vervangen, spiegelen ze verharde artefacten één keer en verspreiden ze deze als goedgekeurde bouwstenen via de registers en pipelines die teams al gebruiken. Als gevolg hiervan verschuift het kwetsbaarheidsbeheer van elk applicatieteam dat onafhankelijk basisimages onderzoekt en opnieuw opbouwt, naar één platformteam dat een vertrouwde set onderhoudt. Applicatieteams nemen de oplossing over in plaats van dat ze het werk zelf doen.
Bovendien bevat elk artefact ondertekende Software Bills of Materials (SBOM’s) en een verifieerbare herkomst, waardoor teams algemene auditvragen kunnen beantwoorden, zoals “Wat is er actief?” “Waar komt het vandaan?” of “Hoe wordt het onderhouden?” Door deze vragen te beantwoorden kunnen platform- en beveiligingsteams zich weer bezighouden met het opbouwen en onderhouden van hun kernactiviteiten voor hun klanten.
De verborgen kosten van het niet moderniseren
Het herdefiniëren van de modernisering van de softwaretoeleveringsketen is belangrijk omdat het ‘behouden van de status quo’ nooit een risicovrije optie is geweest. Het was gewoon de optie waarbij de kosten breed genoeg werden verdeeld om buiten het risicoregister te blijven.
Engineeringcapaciteit die wordt verbruikt door repetitieve CVE-triage in plaats van roadmapwerk is een reële kostenpost. Het uitvoeren van noodreactiecycli telkens wanneer een nieuwe campagne zich richt op een veelgebruikt pakket, neemt enorm veel tijd en bandbreedte in beslag. Auditbevindingen die steeds moeilijker te sluiten zijn, veroorzaken vermoeidheid en vertragen uw organisatie. En de hele moderniseringsinspanning kan tot stilstand komen als uw team het te druk heeft met patchen om daadwerkelijk nieuwe systemen te implementeren. Al deze vertraagde voortgang betekent dat uw technische team zich niet concentreert op wat het moet doen: functies bouwen die inkomsten genereren.
Tegenover deze kosten is het adopteren van een veilige softwarebasis een relatief kleine, omkeerbare, goedomvattende verandering. Het raakt de bouw, niet de bedrijfslogica. Het kan beginnen met één platformteam en een handvol afbeeldingen. Platformteams kunnen de softwarebasis centraal verbeteren en die vertrouwde artefacten uitrollen via de registers en pijplijnen die andere teams al gebruiken.
De tijdlijn blijft van jou
Het belangrijkste dat u moet begrijpen over modernisering voor financiële dienstverleners is dat u beveiligingsvoordelen ziet onderwegniet alleen als de inspanning ‘gedaan’ is. U kunt de beveiliging enorm verbeteren en toch veilig doorgaan met uw algehele moderniseringsinspanningen door te beginnen met de softwaretoeleveringsketen. Naarmate een groter deel van het erfgoed is gebaseerd op vertrouwde standaardinstellingen, verandert uw algehele beveiligingshouding in de loop van de tijd van het voortdurend reageren op kwetsbaarheden naar het niet overnemen van de meeste ervan. Dat is wat secure-by-default in de praktijk betekent.
Ontdek meer over hoe Chainguard u kan helpen de softwaretoeleveringsketen van uw financiële dienstverlener vandaag nog te beveiligen.
Opmerking: Dit artikel is vakkundig geschreven en bijgedragen door Matt Stead, Product Marketing Manager bij Chainguard
