De herinnering aan de catastrofale Log4J-kwetsbaarheid twee jaar geleden is nog vers. Iedereen moest koortsachtig op zoek naar alle plekken waar die kwetsbaarheid aanwezig was. Het was daarmee een wakeupcall over hoe niet voldoende gescreende opensource-componenten een hele omgeving en zelfs een volledige provide chain in gevaar brengen.
Het Log4J-incident staat niet op zich. Een ander voorbeeld was de Solarwinds-kwestie. In de software program van dat bedrijf zaten kwetsbaarheden die uiteindelijk naar honderden klanten uitgerold werden. Daardoor waren alle gebruikers van de software program plots een potentieel slachtoffer voor cybercriminelen. Ook de problemen rond Solarwinds legden de vinger op de zere plek: elk bedrijf heeft zoveel verschillende componenten in zijn software program zitten dat niemand nog weet waar die vandaan komen, laat staan hoe veilig die wel (of niet) zijn. Dat gebeurt dus zowel in de programma’s die de eigen ontwikkelaars schrijven, als in de software program van derde partijen die organisaties uitrollen.
Op die manier worden veel kwetsbaarheden in software program ingebouwd. Onderzoek van de Linux Basis bracht aan het licht dat het gemiddelde ontwikkelproject vijftig kwetsbaarheden bevat, en tachtig directe afhankelijkheden. Daarnaast zijn er nog veel meer indirecte en zo mogelijk nog moeilijker te detecteren afhankelijkheden.
Wanneer een kwetsbaarheid aan het licht komt, zoals Log4j of OpenSSL 3, dan moeten organisaties op zoek naar de speld in de hooiberg. Soms lijkt het op de matroesjka-poppetjes: zodra je een applicatie opendoet, blijkt er een andere afhankelijkheid onder te zitten.
Onoverkomelijke klus
“Soms lijkt het op de matroesjka-poppetjes: zodra je een applicatie opendoet, blijkt er een andere afhankelijkheid onder te zitten”
De oplossing voor deze uitdaging lijkt simpel: alle softwareontwikkeling documenteren. Makkelijker gezegd dan gedaan. Onderzoek toonde al aan dat een klein percentage van organisaties zijn processen documenteert. Retroactief gaan documenteren lijkt een onoverkomelijke klus. Een recente ‘government order’ van de Amerikaanse president Biden verplicht softwarebouwers om een zogeheten Software program Invoice of Supplies (SBoM) op te stellen. Daaruit moet blijken welke onderdelen in een softwareprogramma zitten, bijvoorbeeld welke opensource-bibliotheken. Een beetje zoals de Voedsel- en Warenautoriteit voedingsproducenten oplegt bij te houden welke ingrediënten verwerkt worden in bijvoorbeeld een blinde vink. Worden veel consumenten ziek, dan kan opgespoord worden waar het probleem ligt.
Ongezonde software program of ongezonde voeding: bij beide is het makkelijker problemen detecteren als je alle ingrediënten kent. Dan heb je geen blinde vlekken.
Opstellen
Bij het opstellen van een SBoM moet je om potentiële problemen zo snel mogelijk op te sporen een aantal zaken voor ogen houden,
- Denk aan realtime-remediëring
In de eerste plaats is een SBoM er om ontwikkelaars inzicht te geven in de bouwblokken waaruit gedeelde bibliotheken bestaan. Deze kennis hebben is één ding, maar belangrijker is om SBoM-software te gebruiken die meteen ook de problemen oplost, zonder manuele interventie. Door de vele bekende en onbekende kwetsbaarheden is snelle remediëring noodzaak.
- Gebruik ook knowledge van je endpoints
Het is bekend dat endpoints de meest kwetsbare onderdelen zijn in een volledige it-infrastructuur. Uit onderzoek blijkt dat twee derde van alle organisaties één of meerdere keren aangevallen werden through hun eindpoints. Wanneer je een SBoM gaat opstellen, is het een goed idee om eerst na te gaan welke software program op al die endpoints draait en hoe die samengesteld is. Dan weet je meteen hoeveel endpoints met een bepaalde kwetsbaarheid te maken kunnen krijgen. Zo kan je inschatten wat je te doen staat.
Om effectief te zijn, moet een SBoM bijzonder granulair te werk gaan. Een SBoM moet een gedetailleerde lijst opleveren welke gedeelde bibliotheken en componenten een applicatie bevat, inclusief alle versienummers van deze onderdelen. Duikt voor één specifieke versie een probleem op, dan kan je meteen gericht gaan patchen, zonder ook een replace uit te rollen naar endpoints die helemaal geen replace nodig hebben. Op die manier bespaar je veel tijd en manuele mankracht .
Gelukkig hoef je bovenstaande activiteiten niet helemaal vanaf nul te starten. Current is een SBoM-feature gelanceerd. De techniek bestaat eruit dat gezocht wordt welke software program draait op alle of bepaalde specifieke endpoints in een bedrijfsomgeving. Op die manier worden softwarebibliotheken en -pakketten geïnventariseerd. Vervolgens wordt de software program verder geanalyseerd op bestaande kwetsbaarheden en mogelijke toekomstige kwetsbaarheden. Wordt dan een zero-day-kwetsbaarheid ontdekt, dan weten it-medewerkers meteen waar te zoeken en waar te remediëren. Nu duurt het vaak twee weken of langer voordat alle kwetsbare stukken code ontdekt worden.
Price range
‘Software program is consuming the world’ is een citaat van Marc Andreessen. Maar kwetsbaarheden in je software program kunnen makkelijk de budgetten van een bedrijf gaan opeten. Zorg er dus voor dat je beschermd bent, en een SBoM is dan een prima start.