Software regeert de wereld. Het houdt vliegtuigen in de lucht, ziekenhuizen draaiende en zorgt ervoor dat het mondiale financiële systeem nooit iets mist. Maar steeds vaker worden deze applicaties gebouwd met behulp van open-source codecomponenten uit verschillende, ongelijksoortige bronnen. Complexiteit is de nieuwe norm, of het nu gaat om propriëtaire software of op maat gemaakte apps van eigen bodem. En complexiteit is de vijand van veiligheid.
De complexe relaties tussen componenten en het gemak waarmee bedreigingsactoren malware in de upstream-code kunnen invoegen, zouden beveiligingsmanagers zorgen moeten baren. De wake-up calls zijn de afgelopen jaren veelvuldig en snel gekomen. Het is tijd om een effectieve manier te vinden om dat te doen het beheren van de softwaretoeleveringsketen risico's.
Hoe de software-toeleveringsketen werkt
Toeleveringsketens zijn de cruciale routes waarlangs grondstoffen en componenten worden aangevoerd voordat ze worden geassembleerd, verkocht en gebruikt. In de digitale wereld worden dergelijke componenten vaak beter gezien als dienstverlening van leverancier aan klant. Zoals wij besproken in een vorig artikelzijn deze dienstverleners een steeds populairder doelwit voor aanvallen omdat dreigingsactoren een goede RoI kunnen genereren. Val één uitbesteder van bedrijfsprocessen of een gigant van IT-diensten aan en zij hebben de mogelijkheid om gegevens te stelen van en/of een potentieel grote groep downstream-klanten af te persen.
Een softwaretoeleveringsketen is vergelijkbaar, maar in dit geval omvat het systeem de componenten, codebibliotheken, tools en processen die nodig zijn om software te bouwen. Door een enkel onderdeel of zelfs een hele applicatie in gevaar te brengen, kunnen aanvallers mogelijk elke ontwikkelaar of organisatie beïnvloeden die die software/component gebruikt.
Waar is het risico?
Software bestuurt misschien wel de wereld, maar wat komt er precies kijken bij het bouwen van de applicaties die alles aandrijven, van e-commerceplatforms tot kritische zakelijke ERP-systemen? Het zijn steeds vaker open source-componenten. A Sonatype-rapport schat dat ontwikkelaars alleen al in 2022 3.1 biljoen verzoeken voor dergelijke componenten hebben ingediend vanuit de vier grootste open-source-ecosystemen: Java, JavaScript, Python en .NET. Het voordeel is dat ontwikkelaars door het downloaden van deze kant-en-klare pakketten de time-to-market kunnen versnellen en het bedrijf kunnen helpen sneller te reageren op de snel veranderende marktvraag. Er wordt beweerd dat 80% van de code in moderne applicaties afkomstig is van reeds bestaande open-sourcesoftware.
De uitdaging is dat deze componenten – of open-source ‘afhankelijkheden’ – vaak kwetsbaarheden bevatten. Volgens Sonatype werden vorig jaar elke maand 1.2 miljard kwetsbare afhankelijkheden gedownload. Als ze onbewust worden gedownload, kunnen ze het risico met zich meebrengen dat ze op een later tijdstip door bedreigingsactoren worden uitgebuit. Volgens de Linux Foundation, bevat het gemiddelde applicatieontwikkelingsproject 49 kwetsbaarheden in 80 directe afhankelijkheden.
Nog erger zijn de indirecte of transitieve afhankelijkheden, die volgens Sonatype verantwoordelijk zijn voor zes op de zeven kwetsbaarheden in projecten. Deze afhankelijkheden zijn moeilijker te traceren, omdat het in feite de bibliotheken en pakketten zijn die directe afhankelijkheden aanroepen, met andere woorden: afhankelijkheden van afhankelijkheden. Als gevolg hiervan is het niet meteen duidelijk dat een bepaalde applicatie ze gebruikt. Dat kan kwetsbaarheden verbergen onder een extra verduisteringslaag.
Een voorbeeld hiervan is de beruchte Log4j-kwetsbaarheden. Log4j is een weinig bekende maar populaire logtool die door meer dan 35,000 Java-softwarepakketten wordt gebruikt. Eind december 10.0 werd een patch uitgebracht voor een kritieke kwetsbaarheid (CVSSS 2021) in de tool. Maar vanwege het wijdverbreide gebruik ervan in het open source-ecosysteem van Java was het voor veel organisaties uiterst moeilijk om alle exemplaren van Log4j definitief te vinden en te patchen. in hun omgeving. Volgens Google, waren de meeste getroffen Java-pakketten kwetsbaar omdat Log4j een moeilijk te vinden transitieve afhankelijkheid was.
“Hoe dieper de kwetsbaarheid zich in een afhankelijkheidsketen bevindt, hoe meer stappen er nodig zijn om deze te verhelpen”, voegde het eraan toe.
Helaas verspilden de bedreigingsactoren geen tijd met het misbruiken van de bug. Volgens VerizonVorig jaar vond een derde (32%) van de scans op kwetsbaarheden in blootgestelde systemen plaats in de eerste 30 dagen na de publicatie ervan.
Naast de uitdaging om kwetsbaarheden in open-sourcecomponenten te vinden en te patchen, hebben organisaties ook te maken met de extra hoofdpijn van kwaadaardige pakketten die door bedreigingsactoren in open-sourcerepository's worden geplaatst. Sonatype beweert in 633 een jaarlijkse stijging van 2022% van dergelijke pakketten te hebben geregistreerd, tot meer dan 88,000 bekende gevallen.
Een andere bedreiging: propriëtaire software
Het risico van de softwaretoeleveringsketen beperkt zich echter niet tot open source. Bedrijfseigen commerciële producten kunnen kwetsbaarheden bevatten waar aanvallen misbruik van kunnen maken, en dat gebeurt regelmatig ook. Ze kunnen ook een buggy bevatten open source componenten en tools, zoals Log4j. Volgens Steve Poole, directeur van Developer Advocacy van Sonatype, kan in feite maar heel weinig code die vandaag de dag bestaat, echt als “eigendom” worden omschreven.
“Als gevolg hiervan hebben consumenten van schijnbaar propriëtaire applicaties een vals gevoel van veiligheid en kunnen ze daardoor onbewust kwetsbaar zijn”, vertelt hij aan ISMS.online.
Bij meer geavanceerde aanvallen zoals de SolarWinds-campagnekunnen bedreigingsactoren zelfs de eigen IT-omgeving van de leverancier in gevaar brengen en malware in legitieme software-updates inbrengen. Dit stelde Russische staatsagenten in staat verschillende Amerikaanse ministeries in gevaar te brengen.
“Elke vorm van software kan worden aangetast. Het grootste probleem is een ongerechtvaardigd impliciet vertrouwen in die software”, stelt Udo Schneider, veiligheidsevangelist Europa bij Trend Micro.
Samuel Barfoot, leider van het beveiligingsteam bij Checkmarx, zegt dat de volwassenheid van de softwareleverancier en ISO-accreditatie van cruciaal belang zijn.
“Hoewel de software zelf misschien niet is ontworpen om schade aan te richten, kan deze, als deze wordt geïnfiltreerd, worden gebruikt om informatie te lekken”, vertelt hij aan ISMS.online. “Bij de overstap naar de cloud worden organisaties ook geconfronteerd met risico's met betrekking tot leverancierscontroles, ondersteuning, back-ups en systeembeschikbaarheid in het geval van een hack of uitval. De volwassenheid van de leverancier is cruciaal bij het beperken van deze risico’s door middel van paraatheid en voorzieningen.”
Zichtbaarheid is de eerste stap naar risicobeheer
Of het nu gaat om propriëtaire of open-sourcecode, organisaties die de risico's in de softwaretoeleveringsketen willen beperken, moeten eerst inzicht krijgen in 'slechte' componenten en subcomponenten, aldus Schneider van Trend Micro. Dit kunt u bereiken door een software stuklijst (SBOM) aan te vragen.
“Een SBOM voor een software-artefact (bibliotheek, uitvoerbaar bestand of zelfs container) bevat een afhankelijkheidsgrafiek waarin alle gebruikte software-(sub-)componenten worden vermeld, inclusief een exact versienummer. SBOM's kunnen rechtstreeks vanuit de bron binnen een CI/CD-pijplijn of later 'dode' artefacten zoals uitvoerbare bestanden of zelfs containers”, legt hij uit.
“Dit is vooral handig voor propriëtaire software waarbij de leverancier doorgaans geen SBOM's levert. In rechtsgebieden/sectoren waar leveranciers een SBOM moeten verstrekken, kunnen ze voortdurend worden gecontroleerd op bekende kwetsbaarheden, waardoor een actuele basis wordt geboden voor mogelijke actie.”
Sonatype's Poole voegt hieraan toe dat organisaties ook de beveiligingssituatie van leveranciers moeten beoordelen, waarbij bijzondere aandacht moet worden besteed aan de kwaliteit van hun rapportageprocessen voor kwetsbaarheden.
Voor open source-componenten moeten organisaties een programma uitvoeren van voortdurende evaluatie van open source-componenten, waarbij waar nodig onmiddellijk patches/updates moeten worden uitgevoerd om snelle exploitatie te voorkomen, betoogt hij. Software Composition Analysis (SCA)-tools kunnen ook helpen door te ontdekken wat er in producten of componenten zit.
“De verfijning van de SCA-tool moet echter overeenkomen met die van de slechte actoren en deze zelfs overtreffen, anders loopt de organisatie het reële risico van een aanval via een niet-gedetecteerde vector”, waarschuwt hij.
“Betrek ontwikkelaars ten slotte bij het proces door ze voor te lichten over hoe moderne cyberaanvallen plaatsvinden en wat veilige codeerprincipes zijn, en leer ze over hun verantwoordelijkheden aan het begin van de softwaretoeleveringsketen: hun onmiddellijke keuzes en acties hebben gevolgen.”
Begin met een ISMS
Schneider van Trend Micro betoogt dat een managementsysteem voor informatiebeveiliging (ISMS) kan een uitstekende manier zijn om de risico's van de softwaretoeleveringsketen voortdurend te beperken.
“Door gegevens uit SBOM-tools, verrijkt met distributiegegevens, in een ISMS te plaatsen, is het mogelijk om de beveiligingspositie en daarmee het algehele risico van het hele systeem, waarvan software slechts een onderdeel is, beter te beoordelen en te documenteren”, legt hij uit. “Wanneer het wordt gebruikt als basis voor het beperken van risico’s en het documenteren van de ondernomen acties, biedt dit in principe een veel betere beveiliging dan het handmatig volgen van softwaremiddelen.”
Een checklist voor het beheren van risico's in de softwaretoeleveringsketen:
- Vraag een SBOM aan
- Beoordeel propriëtaire softwareleveranciers (vooral hun kwetsbaarheidsrapportage)
- Gebruik SCA-tools om inzicht te krijgen in softwarecomponenten
- Scan voortdurend op kwetsbaarheden en herstel deze onmiddellijk
- Informeer ontwikkelaars over het belang van security by design
- Overweeg om SBOM-gegevens in te voeren in een ISMS voor holistisch risicobeheer
Ontdek hoe de ISMS.online-oplossing een eenvoudige, veilige en duurzame benadering van supply chain-risicobeheer en informatiebeheer mogelijk maakt met ISO 27001 en meer dan 100 andere wereldwijde raamwerken.
