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 supply chain in gevaar brengen.
Het Log4J-incident staat niet op zich. Een ander voorbeeld was de Solarwinds-kwestie. In de software van dat bedrijf zaten kwetsbaarheden die uiteindelijk naar honderden klanten uitgerold werden. Daardoor waren alle gebruikers van de software 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 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 van derde partijen die organisaties uitrollen.
Op die manier worden veel kwetsbaarheden in software ingebouwd. Onderzoek van de Linux Foundation 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
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 ‘executive order’ van de Amerikaanse president Biden verplicht softwarebouwers om een zogeheten Software Bill of Materials (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 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 data 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 via hun eindpoints. Wanneer je een SBoM gaat opstellen, is het een goed idee om eerst na te gaan welke software 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.
- Onderzoek alle details
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 update uit te rollen naar endpoints die helemaal geen update nodig hebben. Op die manier bespaar je veel tijd en manuele mankracht .
- Gebruik SBoM-software
Gelukkig hoef je bovenstaande activiteiten niet helemaal vanaf nul te starten. Recent is een SBoM-feature gelanceerd. De techniek bestaat eruit dat gezocht wordt welke software draait op alle of bepaalde specifieke endpoints in een bedrijfsomgeving. Op die manier worden softwarebibliotheken en -pakketten geïnventariseerd. Vervolgens wordt de software 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.
Budget
‘Software is eating the world’ is een citaat van Marc Andreessen. Maar kwetsbaarheden in je software kunnen makkelijk de budgetten van een bedrijf gaan opeten. Zorg er dus voor dat je beschermd bent, en een SBoM is dan een prima begin.
