Det är dags att granska din kod eftersom det verkar som om vissa funktioner utan kod eller lågkod som används i iOS- eller Android-appar kanske inte är så säkra som du trodde. Det är det stora avdraget från en rapport som förklarar att förtäckt rysk programvara används i applikationer av den amerikanska militären, CDC, Storbritanniens Labour Party och andra enheter.
När Washington blir Sibirien
Problemet är att kod utvecklad av ett företag som heter Pushwoosh har distribuerats till tusentals applikationer från tusentals enheter. Dessa inkluderar Centers for Disease Control and Prevention (CDC), som säger att de förleddes att tro att Pushwoosh var baserad i Washington när utvecklaren faktiskt är baserad i Sibirien, förklarar Reuters. Ett besök på Pushwooshs Twitter-flöde visar att företaget säger sig ha sitt huvudkontor i Washington, DC.
Företaget tillhandahåller kodstöd och databehandling som kan användas i appar för att profilera vad smartphone-appanvändare gör online och skicka personliga aviseringar. CleverTap, Braze, One Signal och Firebase erbjuder liknande tjänster. Nu, för att vara rättvis, har Reuters inga bevis för att uppgifterna som samlats in av företaget har missbrukats. Men det faktum att företaget är baserat i Ryssland är problematiskt, eftersom informationen är föremål för lokala datalagar, vilket kan utgöra en säkerhetsrisk.
Så kanske inte är fallet, naturligtvis, men en utvecklare som är inblandad i att behandla data som kan anses vara känslig kommer sannolikt inte att vilja ta denna risk.
Vad är bakgrunden?
Även om det finns gott om skäl att vara försiktig med Ryssland just nu, är jag säker på att varje land har sina egna tredjepartskomponentutvecklare som kanske eller kanske inte prioriterar användarsäkerhet. Utmaningen är att veta vilka som gör och vilka som inte gör det.
Anledningen till att sådan Pushwoosh-kod används i applikationer är enkel: det handlar om pengar och utvecklingstid. Utveckling av mobilappar kan vara dyrt, så för att minska utvecklingskostnaderna kommer vissa appar att använda standardkod från tredje part för vissa uppgifter. Detta håller kostnaderna nere, och eftersom vi går mot utvecklingsmiljöer utan kod/låg kod ganska snabbt, kommer vi att se mer av den här typen av fysiska modelleringsmetoder för apputveckling.
Det är bra, eftersom modulär kod kan ge enorma fördelar för appar, utvecklare och företag, men det lyfter fram ett problem som alla företag som använder tredjepartskod måste vara medvetna om.
Vem är ägaren till din kod?
Hur säker är koden? Vilken data samlas in av koden, vart tar denna information vägen och vilken makt har slutanvändaren (eller företaget vars namn visas i appen) för att skydda, radera eller hantera denna data?
Det finns andra utmaningar: när sådan kod används, uppdateras den regelbundet? Är själva koden fortfarande säker? Vilket djup av rigor tillämpas när man testar programvaran? Innehåller koden hemlig skriptspårningskod? Vilken kryptering används och var lagras data?
Problemet är att om svaret på någon av dessa frågor är "vet inte" eller "ingen", är din data i fara. Detta understryker behovet av robusta säkerhetsbedömningar kring användningen av valfri modulär komponentkod.
Dataefterlevnadsteam måste noggrant testa dessa element – "minimal" testning räcker inte.
Jag skulle också säga att ett tillvägagångssätt där all data som samlas in är anonymiserad är väldigt vettigt. På så sätt, vid informationsläckage, minimeras risken för missbruk. (Risken med anpassade tekniker som saknar starkt skydd av information mitt under utbytet är att dessa data, när de väl samlats in, blir en säkerhetsrisk.)
Implikationerna av Cambridge Analytica illustrerar säkert varför fördunkling är ett måste i en sammanhängande tidsålder.
Apple verkar verkligen förstå denna risk. Pushwoosh används i cirka 8000 XNUMX iOS- och Android-appar. Viktigt är att utvecklaren hävdar att data den samlar in inte lagras i Ryssland, men det kanske inte skyddar den från exfiltrering, säger experter som citeras av Reuters.
På sätt och vis spelar det inte så stor roll, eftersom säkerhet bygger på att förutse risker, snarare än att vänta på att faran ska inträffa. Med tanke på det stora antalet företag som går i konkurs efter att ha blivit hackade är det bättre att vara säker än ledsen när det kommer till säkerhetspolicyer.
Det är därför alla företag vars utvecklingsteam förlitar sig på out-of-the-box kod måste se till att tredjepartskod är kompatibel med företagets säkerhetspolicy. Eftersom det är din kod, med ditt företagsnamn, och all missbruk av den informationen på grund av otillräcklig efterlevnadstestning kommer att vara ditt problem.
Följ mig på Twitter eller gå med mig på AppleHolics bar & grill och Apples diskussionsgrupper på MeWe. Också nu på Mastodon.
Copyright © 2022 IDG Communications, Inc.