Volgens een Gartner rapportzou tegen 45 tot 2025% van de organisaties wereldwijd te maken hebben gehad met een aanval op hun softwaretoeleveringsketen. Dit soort aanvallen komt steeds vaker voor en is moeilijk te bestrijden als gevolg van veranderingen in de manier waarop softwareproducten tegenwoordig worden gebouwd.
Tegenwoordig hoeven software-ingenieurs geen applicaties helemaal opnieuw te bouwen. Zoveel als 90% van een app kan worden gebouwd met codes van derden, afzonderlijke bibliotheken en open source-software. Hoewel deze benadering van softwareontwikkeling helpt om het proces van het bouwen van apps te vereenvoudigen en een aanzienlijke hoeveelheid tijd te besparen, vergroot het ook de bedreigingen en kwetsbaarheden in de beveiliging, omdat kwaadaardige pakketten kunnen worden afgeleverd via codes en software van derden.
Uiteindelijk is het wordt steeds moeilijker om de integriteit van de softwaretoeleveringsketens te behouden. De recente toename van de risico's in de toeleveringsketen van software en de spraakmakende inbreuken die daardoor worden veroorzaakt, laten zien hoe ernstig het probleem van kwetsbaarheden in de toeleveringsketen is.
In lijn met deze trend is het voor organisaties absoluut noodzakelijk geworden om actie te ondernemen om de integriteit en veiligheid van hun software te waarborgen. In dit artikel onderzoeken we de algemene risico's voor de toeleveringsketen van software en de verschillende manieren waarop organisaties deze kwetsbaarheden kunnen beperken en hun software tegen aanvallen kunnen beschermen.
De bekende kwetsbaarheden in softwaretoeleveringsketens
Software van derden kan verschillende bedreigingen vormen voor de softwaretoeleveringsketen. Aanvallers kunnen op verschillende manieren misbruik maken van kwetsbaarheden in systemen die afhankelijk zijn van deze software van derden. Sommige van deze aanvalsmethoden omvatten het introduceren van kwaadaardige code in software, verwarring over afhankelijkheid, typosquatting, enzovoort.
Vanwege de complexiteit van softwareontwikkeling en de snelheid waarmee nieuwe apps moeten worden geleverd op de huidige zeer competitieve digitale markt, hebben software-ingenieurs echter geen andere keuze dan te vertrouwen op tools van derden en externe bibliotheken om applicaties zo snel mogelijk te creëren. .
Kwetsbaarheden kunnen in applicaties worden geïntroduceerd als gevolg van:
- De code die u schrijft: slechte beveiligingspraktijken in de aangepaste code die u zelf hebt geschreven
- Waarmee u bouwt: de softwareontwikkelingstools die worden gebruikt voor het bouwen van apps kunnen worden aangetast, waardoor uw software wordt blootgesteld aan beveiligingsproblemen
- Wat u koopt: sommige kant-en-klare Software-as-a-Service (SaaS)-applicaties die worden gebruikt voor app-ontwikkeling kunnen kwetsbaarheden bevatten
- Wat u gebruikt: veel applicaties zijn afhankelijk van open source-bibliotheken van derden die mogelijk de zwakke schakel in uw toeleveringsketen vormen.
Gezien de talrijke potentiële zwakke schakels in elke softwaretoeleveringsketen moeten organisaties proactief zijn op het gebied van preventie en herstel Kwetsbaarheden in de toeleveringsketen van software. Om dit te kunnen doen, moeten software-ingenieurs de potentiële risico's en bedreigingen begrijpen waarmee hun softwareprojecten mogelijk te maken kunnen krijgen. Enkele van deze bedreigingen zijn onder meer:
Ingebed pakket met kwaadaardige code
Een van de dingen die aanvallers doen bij een software supply chain-aanval is het infecteren van de getroffen eindpunten met kwaadaardige software. Deze malware kan een virus, ransomware, Trojaans paard of spyware zijn die grote schade kan aanrichten aan de getroffen software en computersystemen.
Aanvallers kiezen vaak doelen waarvan de systemen autorisatie op hoog niveau hebben op gebruikersapparaten. Een opmerkelijk voorbeeld van een dergelijke aanval is de cyberaanval van 2021 Kaseja, een ontwikkelaar van IT-oplossingen wiens klanten onder meer Managed Service Providers en zakelijke klanten waren.
Een van de belangrijkste IT-oplossingen van Kaseya is VSA, een uniforme tool voor monitoring en beheer op afstand. De VSA-server werd zeer vertrouwd op de apparaten van klanten en door deze te infiltreren konden de aanvallers de authenticatiecontroles op verbonden clients omzeilen. Op deze manier konden ze ongehinderd kwaadaardige ladingen uploaden. De Kaseya-aanval is vergelijkbaar met de Beveiligingsfiasco SolarWinds, waar aanvallers kwaadaardige updates naar duizenden klanten konden pushen, waardoor ze werden blootgesteld aan extra beveiligingsproblemen.
Exfiltratie van gevoelige gegevens
Elke aanval met als doel datadiefstal kan worden geclassificeerd als een data-exfiltratie-aanval. Er wordt gezegd dat gegevensexfiltratie plaatsvindt wanneer een kwaadwillende actor een ongeoorloofde overdracht van gevoelige gegevens van een doelsysteem naar een andere locatie uitvoert. Een opmerkelijk voorbeeld van een data-exfiltratie-aanval die plaatsvond als gevolg van een supply chain-aanval was de Aanval van november 2013 op Target, een van de grootste retailbedrijven in de Verenigde Staten.
De aanvallers kwamen de systemen van Target binnen met inloggegevens die ze hadden gestolen van een externe leverancier. Door deze aanval kregen ze ongeautoriseerde toegang tot de klantenservicedatabase van Target, waardoor ze de namen, telefoonnummers, e-mailadressen, betaalkaartgegevens en andere gevoelige gegevens van klanten konden vastleggen. De betaalkaartgegevens van 41 miljoen doelklanten werden naar de servers van de aanvaller geëxfiltreerd, terwijl de contactgegevens van meer dan 60 miljoen klanten openbaar werden gemaakt.
Uitvoering van externe code
Remote Code Execution (ook wel Arbitrary Code Execution genoemd) is een type cyberaanval waarbij een aanvaller toegang krijgt om op afstand de bediening van een apparaat of computer te besturen. Meestal injecteert de aanvaller kwaadaardige code in een bestand, tekenreeks of een heel pakket dat een slachtoffer op zijn systemen wil uitvoeren. Hierdoor kan de aanvaller een grootschalige aanval lanceren die een volledige webapp of webserver in gevaar kan brengen. Twee veelvoorkomende manieren waarop aanvallen op het uitvoeren van externe code kunnen plaatsvinden bij aanvallen op de softwaretoevoerketen zijn via typosquatting en afhankelijkheidsverwarring:
typosquatting
Om dit type aanval uit te voeren, creëren de kwaadwillende actoren doorgaans een gecompromitteerd pakket dat identiek is aan de afhankelijkheden die u wilt installeren. Meestal heeft het kwaadaardige pakket een iets andere spelling. Het is de bedoeling om voordeel te halen uit een mogelijke typefout bij een installatieopdracht. Het kwaadaardige pakket functioneert normaal gesproken net als de afhankelijkheid die de ingenieur wilde installeren, maar voert tegelijkertijd ook kwaadaardige code uit die erin is ingebed.
Afhankelijkheid verwarring
Verwarring door afhankelijkheid is een andere aanpak die aanvallers gebruiken om code op afstand uit te voeren in een software supply chain-aanval. Bij dit type aanval creëren de kwaadwillende actoren een pakket op een externe bibliotheek met dezelfde naam als een intern afhankelijkheidspakket. Omdat beide afhankelijkheden dezelfde naam hebben, kan de pakketbeheerder in plaats daarvan de schadelijke code installeren. Hierdoor kan de aanvaller de CI/CD-omgeving (Continuous Integration/Continuous Deployment) van de softwareapplicatie die wordt ontwikkeld, binnendringen.
Hoe kunnen we de risico’s in de software supply chain beperken?
De afgelopen jaren zijn aanvallen op de software-toeleveringsketen een van de grootste cyberbedreigingen geworden waarmee organisaties over de hele wereld worden geconfronteerd. Het beperken van de risico's van dit soort aanvallen is een belangrijk onderdeel geworden van cyberbeveiliging en risicobeheer in elke organisatie, vooral in organisaties die afhankelijk zijn van software van derden. In plaats van blindelings op platforms van derden en openbare opslagplaatsen te vertrouwen, is het beter om voorzorgsmaatregelen te nemen en de nodige controles uit te voeren op wat er in uw systeem wordt geïmporteerd. Bij het opstellen van uw risicobeheerplan voor de softwaretoeleveringsketen kunt u de volgende manieren gebruiken om de risico's van aanvallen op de softwaretoeleveringsketen te beperken:
Controleer uw software
Wat supply chain-aanvallen zo moeilijk te bestrijden maakt, is dat het risico verder reikt dan uw eigen systemen. Om het risico van deze aanvallen te beperken, moet u meer doen dan alleen uw eigen perimeter beschermen. In plaats daarvan moet uw strategie er meer op gericht zijn ervoor te zorgen dat de externe softwaresystemen die met die van u zijn verbonden, net zo veilig zijn.
Dit is echter vaak moeilijk te realiseren, vooral als u niet eens over voldoende informatie beschikt over de externe systemen waarmee u bent verbonden of over de codeafhankelijkheden die binnen uw applicatie worden gebruikt. De eerste stap bij het beperken van het risico op een aanval op de toeleveringsketen is het uitvoeren van een uitgebreide audit van uw softwaretoeleveringsketen.
Onlangs nog, na de SolarWinds-aanval van 2020, waarbij verschillende Amerikaanse overheidsinstanties werden getroffen, de federale overheid van de Verenigde Staten heeft software-audits tot een wettelijke vereiste gemaakt voor elk bedrijf dat software verkoopt aan een Amerikaanse overheidsinstantie. U moet hetzelfde doen voor al uw systemen. Het bijhouden van al uw softwareafhankelijkheden is de enige manier om te weten of uw systeem is blootgesteld aan het risico van aanvallen op de toeleveringsketen.
Naast het meteen controleren van uw softwareafhankelijkheden, moet u ook uw systeem opnieuw controleren bij elke nieuwe release van uw software. Mogelijk moet u ook verder gaan dan handmatige audits door grondiger audits uit te voeren waarmee u alle soorten afhankelijkheden kunt identificeren, inclusief tijdelijke afhankelijkheden.
Geautomatiseerde auditing
Naast het handmatig controleren van uw systemen, moet u de controle mogelijk ook op de automatische piloot instellen. Automatisering speelt een sleutelrol bij het opsporen van kwetsbaarheden in elk onderdeel van uw software. Geautomatiseerde scans helpen kwetsbaarheden in uw softwarecode snel te ontdekken, zodat deze kunnen worden verholpen voordat de code naar productie wordt gepusht. Het gebruik van code van derden bij de ontwikkeling van software zal blijven toenemen en kwaadwillende actoren zullen deze systemen voortdurend als zwakke schakel beschouwen om aanvallen op software in de waardeketen te lanceren. De enige manier om ze te stoppen is door voortdurend op de hoogte te blijven van de veiligheid van uw systeem door het voortdurend te controleren.
Bereid een softwarestuklijst voor
De softwarestuklijst (SBOM) is een van de belangrijkste manieren geworden om de veiligheid van uw software te garanderen en de risico's in de toeleveringsketen te beperken. Dit document is een formele, machinaal leesbare metadata die is ontworpen om de volledige inhoud van een softwarepakket te identificeren. Het beschrijft ook andere essentiële informatie, zoals de licentiegegevens en auteursrechten van alle componenten die worden gebruikt bij het bouwen van een softwareproduct.
Het concept van het opstellen van een stuklijst is niet geheel nieuw. Historisch gezien vindt het zijn oorsprong in de productiewereld. Hier krijgt elk vervaardigd product een stuklijst die dient als inventaris van alle items die in het productieproces van dat product zijn opgenomen.
Hetzelfde principe kan worden toegepast op het risicobeheer van de softwaretoeleveringsketen. De SBOM beschrijft het deel van uw applicatie dat u helemaal opnieuw hebt gebouwd, en vermeldt ook alle onderdelen die u van externe leveranciers heeft gekregen. Zo kun je, wanneer een kwetsbaarheid wordt ontdekt, eenvoudig de bron ervan achterhalen.
SBOM's zijn bedoeld om te worden gedeeld tussen verschillende organisaties die gebruik maken van een softwarecomponent. Dit biedt transparantie over alle componenten die iedereen in de softwaretoeleveringsketen gebruikt. Als organisatie die zich zorgen maakt over de veiligheid van uw software, moet u van SBOM's een prioriteit maken. Voordat u een component aan uw softwareproduct toevoegt, kan het helpen om een stuklijst van de leverancier te verkrijgen. Dit maakt het gemakkelijker om te reageren op uitdagingen en beveiligingsproblemen.
Ontwikkel een raamwerk voor risicobeheer
Bij het beperken van de risico's van aanvallen op de softwaretoeleveringsketen is het altijd beter om een proactieve aanpak te volgen dan te wachten tot er een aanval plaatsvindt. Door vooraf de mogelijke aanvalsscenario’s te schetsen, krijgt u inzicht in uw bereidheid om deze in de toekomst te bestrijden.
Als onderdeel van het risicobeheer van uw softwaretoeleveringsketen moet u een manier ontwikkelen om de waarschijnlijkheid te beoordelen dat een aanvaller uw systeem in gevaar brengt. Op deze manier kunt u bepalen welke preventieve strategieën u moet volgen om deze risico's te beperken, evenals het noodplan dat u moet opstellen om het risico aan te pakken.
Het trainen van iedereen in uw organisatie over hoe te reageren op supply chain-aanvallen is een ander essentieel onderdeel van uw risicobeheerraamwerk. Dit zal iedereen in staat stellen waakzaam te zijn bij het anticiperen op dergelijke aanvallen en op passende wijze te reageren als ze zich toch voordoen.
Conclusie
Aanvallen op de toeleveringsketen van software zullen organisaties blijven blootstellen aan verschillende vormen van risico's. Ingenieurs kunnen er dus niet langer van uitgaan dat de pakketten van derden die zij gebruiken voor het bouwen, implementeren en onderhouden van hun softwareapplicaties veilig zijn en goed worden onderhouden. De belangrijkste reden waarom aanvallen op de toeleveringsketen van software vaker voorkomen dan voorheen, is deels vanwege de toegenomen afhankelijkheid van codes van derden bij het bouwen van software-apps. Om deze risico's te beperken, moet u uw softwaretoeleveringsketen inventariseren en maatregelen nemen om de impact van deze bedreigingen op uw systeem te minimaliseren om grote inbreuken en de daarmee gepaard gaande gevolgen te voorkomen.