Hur man gör mjukvaruförsörjningskedjor motståndskraftiga mot cyberattacker

Apono kommer från smyg för att omdefiniera behörighetshantering


Föreställ dig om någon bad dig att dricka ett glas vätska utan att berätta vad som fanns inuti eller vad ingredienserna kan göra. Skulle du dricka det? Kanske, om det gavs till dig av någon du litade på, men tänk om den personen sa att de inte kunde vara säkra på vad som fanns inuti? Du skulle förmodligen inte delta.

Att konsumera det ok√§nda √§r precis vad IT-avdelningar g√∂r varje dag. De installerar mjukvara och uppdateringar p√• kritiska system utan att veta vad som finns inuti eller vad det g√∂r. De litar p√• sina leverant√∂rer, men det som programvaruleverant√∂rer inte ber√§ttar f√∂r IT-avdelningarna √§r att de inte kan vara s√§kra p√• alla sina uppstr√∂msleverant√∂rer. Att skydda alla delar av en mjukvaruf√∂rs√∂rjningskedja, inklusive de som ligger utanf√∂r IT:s kontroll, √§r n√§stan om√∂jligt. Tyv√§rr drar d√•liga akt√∂rer full nytta av denna stora “attackyta” och g√∂r stora vinster i cyberintr√•ng.

Ett stort problem att bli större

Det mest kända exemplet var hacket från Austin, Texas-baserade affärsprogramutvecklare SolarWinds 2020. Angripare infogade skadlig kod i programvara som användes flitigt av industrin och den federala regeringen. IT-avdelningar installerade en uppdatering som innehöll skadlig programvara och stora volymer känslig och hemligstämplad data stals.

Andra attacker av mjukvaruf√∂rs√∂rjningskedjor har skett p√• f√∂retag som Kaseya, ett IT Management-programvaruf√∂retag d√§r hackare lagt till kod f√∂r att installera ransomware, och Codecov, en verktygsleverant√∂r vars programvara anv√§ndes f√∂r att stj√§la data. Och komprometterade versioner av “coa” och “rc” open source-paket har anv√§nts f√∂r att stj√§la l√∂senord. Dessa namn kanske inte √§r bekanta utanf√∂r IT, men de har stora anv√§ndarbaser att utnyttja. Coa och rc har tiotals miljoner nedladdningar.

Helt uppenbart har angripare kommit på att det är mycket lättare att hacka programvara som folk villigt installerar på tusentals system än att hacka varje system individuellt. Attacker i leveranskedjan för programvara ökade med 300 % från 2020 till 2021, enligt en Argon Security-rapport. Det här problemet försvinner inte.

Hur kunde detta hända?

Det finns två sätt som hackare attackerar mjukvaruförsörjningskedjor: de äventyrar programvarubyggande verktyg eller så äventyrar de tredjepartskomponenter

Mycket fokus har lagts p√• att s√§kra k√§llkodsf√∂rr√•den f√∂r byggverktyg. Googles f√∂reslagna SLSA-ramverk (Supply Chain Levels for Software Artifacts) till√•ter organisationer att j√§mf√∂ra hur v√§l de har “l√•st” dessa system. Det √§r viktigt eftersom det nu finns hundratals vanliga byggverktyg ‚Äď m√•nga av dem √§r l√§ttillg√§ngliga i molnet. Bara den h√§r m√•naden visade sig Argo CD-plugin med √∂ppen k√§llkod ha en betydande s√•rbarhet, vilket ger tillg√•ng till hemligheterna som l√•ser upp bygg- och sl√§ppsystem. Argo CD anv√§nds av tusentals organisationer och har laddats ner √∂ver en halv miljon g√•nger.

På SolarWinds kunde angripare komma åt var källkoden lagrades, och de lade till extra kod som i slutändan användes för att stjäla data från SolarWinds-användare. SolarWinds byggde sin programvara utan att inse att skadlig programvara inkluderades. Det här var som att ge en opålitlig person tillgång till ingredienserna i det glaset med vätska.

√Ąven om f√∂retag kontrollerar sina egna byggmilj√∂er skapar anv√§ndningen av tredjepartskomponenter enorma blinda fl√§ckar i programvaran. De dagar d√• f√∂retag skrev ett komplett mjukvarupaket fr√•n grunden √§r f√∂rbi. Modern mjukvara √§r sammansatt av komponenter byggda av andra. Vissa av dessa tredje parter anv√§nder komponenter fr√•n fj√§rde och femte part. Allt som kr√§vs √§r att en sub-sub-subkomponent inkluderar skadlig programvara och det slutliga paketet inkluderar nu den skadliga programvaran.

Exempel p√• komprometterade komponenter √§r f√∂rbluffande vanliga, s√§rskilt i v√§rlden med √∂ppen k√§llkod. “Namespace confusion attacks” √§r fall d√§r n√•gon laddar upp ett paket och helt enkelt h√§vdar att det √§r en nyare version av n√•got legitimt. Alternativt skickar hackare in skadlig kod f√∂r att l√§ggas till legitima paket, eftersom √∂ppen k√§llkod till√•ter vem som helst att bidra med uppdateringar. N√§r en utvecklare l√§gger till en komprometterad komponent i sin kod, √§rver de alla nuvarande och framtida s√•rbarheter.

Lösningen: Ett ramverk för behörigheter

Branschgrupper och statliga myndigheter som Commerce Department’s National Telecommunications and Information Administration (NTIA) arbetar p√• att utveckla en standard och planerar att anv√§nda en verkst√§llande order f√∂r att f√∂reskriva anv√§ndningen av en mjukvaruf√∂rteckning (SBoM) f√∂r statligt k√∂pt programvara. En SBoM √§r en programvaruingredienslista som hj√§lper till att identifiera vad alla komponenter √§r, men som tyv√§rr inte indikerar om de hackades och kommer att uppf√∂ra sig fel. Hackare kommer inte att lista sin kod i ingredienserna.

Utvecklare kan förbättra säkerheten för de byggverktyg som de kontrollerar och lista tredjepartsingredienser från sina leverantörer, men det räcker inte för att de eller deras användare ska vara säkra på att ingen av ingredienserna har äventyrats. IT behöver mer än en ingredienslista. Den behöver mjukvaruutvecklare för att beskriva hur kod och komponenter förväntas bete sig. IT-team kan kontrollera dessa deklarationer och säkerställa att de överensstämmer med programvarans syfte. Om ett program är tänkt att vara en miniräknare, till exempel, bör det inte innehålla ett beteende som säger att det kommer att skicka data till Kina. Miniräknare behöver inte göra det.

Naturligtvis kanske den komprometterade räknaren inte säger att den har för avsikt att skicka data utomlands eftersom hackare inte kommer att publicera att programvaran äventyras. Ett andra steg är nödvändigt. När programvaran körs bör den blockeras från att göra saker som den inte deklarerade. Om programvaran inte sa att den avsåg att skicka data till ett främmande land, skulle den inte vara tillåten.

Det låter komplicerat, men det finns redan exempel med mobilappar. När de är installerade ber appar om tillåtelse att komma åt din kamera, kontakter eller mikrofon. All oönskad åtkomst blockeras. Vi behöver ett ramverk för att tillämpa konceptet med mobilappliknande behörigheter på datacenterprogramvara. Och det är vad företag som mitt och många andra i vår bransch jobbar med. Här är två av utmaningarna.

En, om en m√§nniska godk√§nner att “s√§nda data utanf√∂r mitt f√∂retag”, menar de all data? Till n√•gonstans? Att lista alla typer av data och alla destinationer √§r f√∂r mycket detaljer f√∂r att granska, s√• detta blir en spr√•klig och taxonomisk utmaning lika mycket som en teknisk. Hur beskriver vi riskabla beteenden p√• ett s√§tt p√• h√∂g niv√• som √§r vettigt f√∂r en m√§nniska utan att f√∂rlora viktiga distinktioner eller de specifika detaljerna som en dator beh√∂ver?

Två, utvecklare kommer inte att använda verktyg som saktar ner dem. Det är ett faktum. Följaktligen kan Рoch bör Рmycket av arbetet med att förklara hur programvara förväntas bete sig automatiseras. Det innebär att man skannar koden för att upptäcka de beteenden den innehåller för att presentera resultat för utvecklare för granskning. Sedan är naturligtvis nästa utmaning för alla inblandade att avgöra hur exakt den skanningen och bedömningen är.

Dessa utmaningar är inte oöverstigliga. Det ligger i allas bästa att utveckla ett behörighetsramverk för datacenterprogramvara. Först då vet vi att det är säkert att ta den drinken.

DataDecisionMakers

Välkommen till VentureBeat-communityt!

DataDecisionMakers är där experter, inklusive tekniska personer som arbetar med data, kan dela datarelaterade insikter och innovation.

Om du vill l√§sa om banbrytande id√©er och aktuell information, b√§sta praxis och framtiden f√∂r data- och datateknik, g√• med oss ‚Äč‚Äčp√• DataDecisionMakers.

Du kan till och med överväga att bidra med en egen artikel!

Läs mer från DataDecisionMakers