Afhanklikhede van afhanklikhede: Die kritieke uitdaging van die bestuur van sagteware-voorsieningskettingrisiko
INHOUDSOPGAWE:
Sagteware bestuur die wêreld. Dit hou vliegtuie in die lug, hospitale aan die gang en verseker dat die globale finansiële stelsel nooit 'n rits mis nie. Maar toenemend word hierdie toepassings gebou met behulp van oopbronkode-komponente van verskillende uiteenlopende bronne. Kompleksiteit is die nuwe normaal, of dit nou eie sagteware of pasgemaakte tuisgemaakte toepassings is. En kompleksiteit is die vyand van sekuriteit.
Die komplekse verhoudings tussen komponente, en die gemak waarmee bedreiging-akteurs wanware in stroomop-kode kan invoeg, behoort sekuriteitsbestuurders tot kommer te wek. Wekroepe het die afgelope jare dik en vinnig gekom. Dit is tyd om 'n effektiewe manier te vind om bestuur sagteware voorsieningsketting risiko.
Hoe die sagteware-voorsieningsketting werk
Voorsieningskettings is die kritieke weë waardeur grondstowwe en komponente gerig word voordat dit saamgestel, verkoop en gebruik word. In die digitale wêreld word sulke komponente dikwels beter beskou as dienste wat van verskaffer tot kliënt gelewer word. Soos ons bespreek in 'n vorige artikel, is hierdie diensverskaffers 'n toenemend gewilde teiken vir aanval omdat bedreigingsakteurs 'n goeie RoI kan genereer. Val een besigheidsproses-uitkontrakteerder of IT-dienstereus aan, en hulle het die geleentheid om data van en/of 'n potensieel groot poel stroomafkliënte af te steel.
'n Sagteware-voorsieningsketting is soortgelyk, maar in hierdie geval bestaan die stelsel uit die komponente, kodebiblioteke, gereedskap en prosesse wat nodig is om sagteware te bou. Deur 'n enkele komponent, of selfs 'n hele toepassing, te kompromitteer, kan aanvallers moontlik enige ontwikkelaar of organisasie wat daardie sagteware/komponent gebruik, beïnvloed.
Waar is die risiko?
Sagteware bestuur dalk die wêreld, maar wat gaan presies in die bou van die toepassings wat alles van e-handelsplatforms tot kritieke besigheids-ERP-stelsels aandryf? Dit is toenemend oopbronkomponente. A Sonatipe verslag skat dat ontwikkelaars in 2022 alleen 3.1 triljoen versoeke vir sulke komponente van die top vier oopbron-ekosisteme gemaak het: Java, JavaScript, Python en .NET. Die trekpleister is dat deur hierdie voorafgeboude pakkette af te laai, ontwikkelaars tyd-tot-mark kan versnel en die besigheid kan help om vinniger te reageer op vinnig veranderende markvraag. Dit word beweer dat 80% van die kode in moderne toepassings afkomstig is van voorafbestaande oopbronsagteware.
Die uitdaging is dat hierdie komponente—of oopbron-“afhanklikhede”—dikwels kwesbaarhede bevat. Volgens Sonatype is 1.2 miljard kwesbare afhanklikhede verlede jaar elke maand afgelaai. As dit onbewustelik afgelaai word, kan dit die risiko inhou om later deur bedreigingsakteurs uitgebuit te word. Volgens die Linux Foundation, bevat die gemiddelde toepassingsontwikkelingsprojek 49 kwesbaarhede oor 80 direkte afhanklikhede.
Selfs erger is indirekte of oorganklike afhanklikhede, wat volgens Sonatype ses uit elke sewe projekkwesbaarhede uitmaak. Hierdie afhanklikhede is moeiliker om op te spoor, aangesien dit effektief die biblioteke en pakkette is wat direkte afhanklikhede noem—met ander woorde, afhanklikhede van afhanklikhede. Gevolglik is dit nie onmiddellik duidelik dat 'n spesifieke toepassing hulle gebruik nie. Dit kan kwesbaarhede onder 'n bykomende laag verduistering versteek.
'n Voorbeeld hiervan is die berugte Log4j kwesbaarhede. Log4j is 'n min bekende maar gewilde aantekeninstrument wat deur meer as 35,000 10.0 Java-sagtewarepakkette gebruik word. 'n Regmaak vir 'n kritieke (CVSSS 2021) kwesbaarheid in die nutsding is aan die einde van Desember 4 vrygestel. Maar as gevolg van die wydverspreide gebruik daarvan oor die Java oopbron-ekosisteem, was dit vir baie organisasies uiters moeilik om alle gevalle van LogXNUMXj definitief te vind en te herstel in hul omgewing. Volgens Google, die meeste geaffekteerde Java-pakkette was kwesbaar omdat Log4j 'n moeilik om te vind oorganklike afhanklikheid was.
"Hoe dieper die kwesbaarheid in 'n afhanklikheidsketting is, hoe meer stappe is nodig om dit reg te stel," het dit bygevoeg.
Ongelukkig het bedreigingsakteurs geen tyd gemors om die fout uit te buit nie. Volgens Verizon, 'n derde (32%) van die skandering vir die kwesbaarheid in blootgestelde stelsels verlede jaar het gedurende die eerste 30 dae na die publikasie daarvan plaasgevind.
Benewens die uitdaging om kwesbaarhede in oopbronkomponente te vind en te herstel, het organisasies die bykomende hoofpyn van kwaadwillige pakkette wat deur bedreigingsakteurs na oopbronbewaarplekke geplaas word. Sonatype beweer dat hy 'n jaarlikse toename van 633% in sulke pakkette in 2022 aangeteken het, tot meer as 88,000 XNUMX bekende gevalle.
Nog 'n bedreiging: eie sagteware
Sagteware-toevoerkettingrisiko is egter nie beperk tot oopbron nie. Eiendoms kommersiële produkte kan kwesbaarhede bevat wat aanvalle kan ontgin en gereeld is. Hulle kan ook karretjies insluit oopbronkomponente en gereedskap, soos Log4j. Trouens, baie min kode wat vandag bestaan, kan werklik beskryf word as “eiendom”, volgens Sonatype se direkteur van ontwikkelaarvoorspraak, Steve Poole.
"Gevolglik het verbruikers van oënskynlik eie toepassings 'n valse gevoel van sekuriteit, en kan dus onwetend kwesbaar wees," sê hy aan ISMS.online.
In meer gesofistikeerde aanvalle, soos die SolarWinds-veldtog, kan bedreigingsakteurs selfs die verkoper se eie IT-omgewing in gevaar stel en wanware in wettige sagteware-opdaterings invoeg. Dit het Russiese staatsoperateurs in staat gestel om verskeie Amerikaanse regeringsdepartemente te kompromitteer.
“Enige soort sagteware kan gekompromitteer word. Die hoofprobleem is 'n ongeregverdigde implisiete vertroue in daardie sagteware,” argumenteer Udo Schneider, veiligheidsevangelis Europe by Trend Micro.
Samuel Barfoot, sekuriteitspanleier by Checkmarx, sê die volwassenheid van die sagtewareverskaffer en ISO-akkreditasie is noodsaaklik.
"Terwyl die sagteware self nie ontwerp is om skade te veroorsaak nie, as dit geïnfiltreer word, kan dit gebruik word om inligting uit te lek," sê hy aan ISMS.online. “Wanneer hulle na die wolk beweeg, staar organisasies ook risiko's in die gesig wat verband hou met verskafferkontroles, ondersteuning, rugsteun en stelselbeskikbaarheid in die geval van 'n inbraak of onderbreking. Die volwassenheid van die verkoper is deurslaggewend om hierdie risiko's te versag deur paraatheid en voorsiening.
Sigbaarheid is die eerste stap in die rigting van die bestuur van risiko
Of dit nou met eie- of oopbronkode handel, organisasies wat risiko in die sagteware-voorsieningsketting wil verminder, moet eers insig kry in “slegte” komponente en subkomponente, volgens Trend Micro se Schneider. Dit kan bereik word deur 'n sagteware stuk materiaal (SBOM) aan te vra.
“'n SBOM vir 'n sagteware-artefak (biblioteek, uitvoerbare of selfs houer) bevat 'n afhanklikheidsgrafiek waar alle sagteware (sub-) komponente wat gebruik word, gelys word, insluitend 'n presiese weergawenommer. SBOM's kan direk vanaf bron binne a CI/CD pyplyn of later op 'dooie' artefakte soos uitvoerbare items of selfs houers,” verduidelik hy.
"Dit is veral nuttig vir eie sagteware waar die verkoper gewoonlik nie SBOM's verskaf nie. In jurisdiksies/vertikale waar verkopers 'n SBOM moet verskaf, kan hulle deurlopend gekontroleer word teen bekende kwesbaarhede, wat 'n bygewerkte basis bied vir moontlike optrede.
Sonatype se Poole voeg by dat organisasies ook verskaffersekuriteitsposisie moet assesseer, met besondere aandag aan die kwaliteit van hul kwesbaarheidsverslagdoeningsprosesse.
Vir oopbronkomponente behoort organisasies 'n program van deurlopende evaluering van oopbronkomponente te bedryf, wat stiptelik regmaak/bywerk waar nodig om vinnige uitbuiting te voorkom, voer hy aan. Software Composition Analysis (SCA) gereedskap kan ook help deur te ontdek wat binne produkte of komponente is.
"Die gesofistikeerdheid van die SCA-instrument moet egter ooreenstem met en oortref dié van die slegte akteurs, of die organisasie staar die werklike risiko in die gesig van 'n aanval via 'n onopgemerkte vektor," waarsku hy.
“Ten slotte, bring ontwikkelaars in die groep deur hulle op te voed oor hoe moderne kuberaanvalle plaasvind, en wat veilige koderingbeginsels is, en leer hulle oor hul verantwoordelikhede aan die begin van die sagteware-verskaffingsketting – hul onmiddellike keuses en optrede het gevolge.”
Begin met 'n ISMS
Trend Micro se Schneider voer aan dat 'n inligtingsekuriteitbestuurstelsel (ISMS) kan 'n goeie manier wees om sagteware-voorsieningskettingrisiko op 'n deurlopende basis te verminder.
"Deur data van SBOM-instrumente, verryk met verspreidingsdata, in 'n ISMS in te voer, is dit moontlik om die sekuriteitsposisie en dus die algehele risiko van die hele stelsel, waarvan sagteware slegs een deel is, beter te assesseer en te dokumenteer," verduidelik hy. "Wanneer dit gebruik word as 'n basis vir die versagting van risiko en die dokumentasie van die aksies wat geneem is, bied dit in beginsel baie beter sekuriteit as handmatige opsporing van sagtewarebates."
'n Kontrolelys vir die bestuur van sagteware-voorsieningskettingrisiko:
- Versoek 'n SBOM
- Evalueer eie sagteware verskaffers (veral hul kwesbaarheid verslagdoening)
- Gebruik SCA-nutsgoed om insig in sagtewarekomponente te kry
- Soek deurlopend vir kwesbaarhede en maak dit dadelik reg
- Leer ontwikkelaars oor die belangrikheid van sekuriteit deur ontwerp
- Oorweeg dit om SBOM-data in 'n ISMS in te voer vir holistiese risikobestuur
Vind uit hoe die ISMS.online-oplossing 'n eenvoudige, veilige en volhoubare benadering tot voorsieningskettingrisikobestuur en inligtingbestuur moontlik maak met ISO 27001 en meer as 100 ander globale raamwerke.
