4min

Tags in dit artikel

, ,

Door de recente Log4Shell-kwetsbaarheid kwam de open-source softwaregemeenschap ineens centraal te staan in de discussie rond cyberbeveiliging. De kwetsbaarheid die werd gevonden in de populaire Log4j-programming library, die wordt gebruikt in heel veel Java-applicaties en -software op internet, werd door sommigen bestempeld als “de ernstigste beveiligingsinbreuk ooit”.

Door toegang te verlenen tot code die op miljarden apparaten wordt gebruikt, gaf Log4Shell hackers een voet tussen de deur om talloze organisaties aan te vallen. Het engste deel? Log4Shell bestond al sinds 2013 en theoretisch zou iedereen met kwade bedoelingen de afgelopen negen jaar die kwetsbaarheid ontdekt kunnen hebben.

Hoewel Log4Shell misschien de de meeste aandacht krijgt als het gaat om open-source kwetsbaarheden, kunnen we er vergif op innemen dat er ook andere bugs sluimeren in de open-source gemeenschap. Ik zeg dit niet om angst aan te wakkeren, maar om deze geweldige open-sourcegemeenschap (waarvan ik al tientallen jaren deel uitmaak), te motiveren om samen te werken om onze security-standaard te verbeteren.

Dus, hoe gaan we het verbeteren?

Omarm de Software Bill of Materials

Een software bill of materials (SBOM)-lijst somt alle componenten in een bepaald stuk software op, met een speciale focus op open-source en componenten van derden in een codebase. SBOM’s zijn een efficiënte manier om veiligere open-source software te maken, omdat ze organisaties absoluut inzicht geven in de technologie die ze gebruiken en vertrouwen. Je kunt een component immers niet beveiligen als je niet weet dat deze in je software voorkomt. Met SBOM’s kunnen organisaties kwetsbaarheden (zoals Log4Shell) lokaliseren en tijdig aanpakken. Experts uit de sector zijn van mening dat het effect van Log4Shell nog jaren voelbaar zal zijn vanwege het gebrek aan patching, en we kunnen aannemen dat meer Log4j-libraries proactief hadden kunnen worden bijgewerkt als organisaties wisten dat de kwetsbaarheid bestond binnen hun technologie-stack.

Een bevel van president Joe Biden in mei 2021 vereist dat leveranciers die software aan de Amerikaanse overheid verkopen, voor elk product een softwarefactuur bijvoegen, om ervoor te zorgen dat de federale overheid precies weet wat er in de technologie gaat die ze gebruiken, tot op het laatste onderdeel. Ik verwacht dat andere organisaties, zowel publiek als privaat, dit voorbeeld zullen gaan volgen.

Als community moeten we de SBOM-vereisten uitbreiden zodat het alle open-source software omvat, want dan is het een stuk veiliger voor degenen die open-source software gebruiken (bewust of onbewust). Een grotere zichtbaarheid van open-source materialen resulteert in meer communicatie met betrekking tot die materialen. Hoe meer mensen zicht hebben op welke open-source componenten in bepaalde software worden gebruikt, hoe groter de kans dat kwetsbaarheden worden gedetecteerd, gepatcht en bijgewerkt.

Update, Update, Update

De open-source community heeft al veel te bieden op het gebied van beveiliging. De community zelf is erg actief, waardoor er vaak patches worden uitgebracht. De Log4Shell-kwetsbaarheid werd gemeld op 24 november 2021 en de patch werd uitgebracht op 9 december. Echter, als patches op een efficiënte manier worden uitgegeven, waarom zijn dan zoveel organisaties nog steeds vatbaar voor aanvallen die gebruikmaken van Log4Shell? Sommige organisaties werken hun software gewoon niet vaak genoeg bij om de patches te integreren.

Organisaties doen er verstandig aan om een ​​regelmatige cadans in te stellen voor het auditen en beoordelen van de open-source componenten in hun technologiestack. De audit- en reviewcycli worden eenvoudiger als organisaties een SBOM bijhouden. Wanneer je toestaat ​​dat slapende kwetsbaarheden ongepatcht blijven, kan dat catastrofaal zijn wanneer organisaties besmette open-source software gaan gebruiken. Zolang software-updates worden doorgelicht om ervoor te zorgen dat ze open source-problemen oplossen en niet leiden tot nieuwe kwetsbaarheden of problemen, zullen consistente updates de cybersecurity van een organisatie verbeteren.

Draag bij aan open source

Open-source projecten, zoals Postgres, combineren de bijdragen van zowel individuen die in hun eigen tijd eraan werken, als van bedrijven die in het succes van het project hebben geïnvesteerd. Om bij te blijven hoe kwaadwillenden evolueren en open-source software exploiteren, moet de open-source community zich in een vergelijkbaar – zo niet sneller – tempo ontwikkelen. Kortom, white hats moeten net zo hard werken als back hats.

De collaboratieve, proactieve geest van de community is wat open-source software uniek maakt, maar het deelnemende karakter ervan betekent dat als de community geen moeite doet om de software te controleren, het risico loopt dat deze uit elkaar wordt gehaald en wordt uitgebuit. Naarmate open-source projecten in populariteit toenemen, moet ook het aantal ontwikkelaars groeien die deze projecten onderhoudt. Een vuistregel: probeer net zoveel in de open-source community te investeren als je eruit haalt. Pluk er niet zomaar de vruchten van zonder ondersteuning te bieden. De kracht van open-source en open-source-beveiliging ligt juist in de bijdragers. De meeste IT-professionals zijn het erover eens dat open source software net zo veilig is als proprietary technologie. Dat betekent echter niet dat de open-source community er niet naar moet streven om zijn software nog verder te beveiligen. Open-source beveiliging is zo sterk als de open-source gemeenschap deze mogelijk maakt. Door deelname aan de gemeenschap aan te moedigen en door best practices op het gebied van cyberhygiëne zoals SBOM’s te promoten, samen met regelmatige updates, kan de developer community  een nieuwe Log4Shell-catastrofe vermijden en de security-standaard van open source verbeteren.

Dit is een ingezonden bijdrage van EDB. Via deze link vind je meer informatie over de mogelijkheden van het bedrijf.