Med miljarder uppkopplade enheter börjar IoT verkligen ta fart och bli en del av inte bara vår vardag utan även våra företag. Men samtidigt som vi njuter av fördelarna med den uppkopplade världen är det viktigt att tänka på konsekvenserna av eventuella säkerhetsöverträdelser.
Olika användningsfall har olika krav och budgetar, vilket innebär att vissa IoT-distributioner kanske inte använder den mest kapabla hårdvaran - och den enhet du använder kan få verkliga konsekvenser för din distribution när det gäller säkerhet. Låt oss därför gå igenom några av de saker du bör tänka på när du utformar din driftsättning för att säkerställa att den är säker.
Typiska säkerhetshot mot distribuerade IoT-enheter
Många IoT-distributioner innebär distribution av stora volymer billiga enheter på grund av budgetbegränsningar, vilket vanligtvis innebär enheter med omogen eller otillräcklig säkerhet och härdning, vilket i sin tur medför tillhörande attackytor.
Här är några exempel på hot som du kan ställas inför med dessa typer av enheter:
- En säkerhetsbrist i en distribuerad enhet som kan användas av en angripare för att få åtkomst till enheten, till nätverket av enheter eller till och med till applikationsservern. Denna åtkomst kan sedan utnyttjas för att infoga felaktiga data, extrahera data eller injicera skadlig kod i systemet
- En enhet som är fysiskt osäker kan stjälas av en angripare och föras till en plats som är mer lämpad för ytterligare angrepp
- Genom att använda anslutning från en komprometterad enhet kan en angripare emulera en legitim enhet för att få åtkomst till nätverket av enheter eller till applikationsservern
- En felkonfigurerad enhet eller prenumeration som kan användas av en angripare för att få tillgång till tjänster som inte borde vara tillgängliga i den avsedda applikationen
Det är inte alla användningsområden som har budget för IoT-enheter med förstärkt säkerhet, eller enheter som har testats och validerats grundligt av tillförlitliga organisationer. Och många implementeringar förlitar sig framgångsrikt på enkel hårdvara. Men det är viktigt att förstå vilka konsekvenser en brist på stark säkerhet kan få för resten av din lösning under dess livstid.
Till exempel kanske en billig och enkel enhet inte har möjlighet att uppdatera firmware, och även om enheten har möjlighet att uppdatera firmware bör du fråga dig om du har råd att spendera den batterikraft som krävs för att utföra de åtgärder som är förknippade med detta. Om ett kritiskt fel upptäcks om några år, hur ska effekterna hanteras och mildras? Det finns lösningar, men konstruktionen för att hantera sådana frågor kan behöva implementeras från början.
Dessutom är det viktigt att hålla reda på vilka enheter som används, t.ex. var de befinner sig och vilken status de har. Med potentiellt tusentals enheter är det svårt att manuellt hålla reda på om en enskild enhet försvinner eller dyker upp igen - och du kan komma att leta efter svar på följande frågor:
- Vad orsakade att en enhet försvann från nätverket?
- Har den återanslutits på en annan plats?
- Har något annat förändrats medan den var borta?
Allt detta är tecken på manipulering som kan vara början på ett försök att bryta sig in i nätverket och det finns sätt att mildra dessa typer av hot.
Vår rekommendation är att använda någon form av funktion för att autentisera enheten, vare sig det är enhetscertifikat eller funktioner inbyggda i er Connectivity Management Platform (CMP) som använder autentiseringsfunktioner som redan finns på SIM-kortet, helst ikombination med spårning av enhetens plats och triggers för enhetsändringar (IMEI-ändringsmeddelande).
En angripare som har fysisk tillgång till en enhet kan få tillgång till SIM-kortet. Genom att använda den anslutning som SIM-kortet ger i en annan enhet kan angriparen få fler möjligheter att bryta sig in i nätverket. Angriparen kan också få tillgång till tjänster som inte var avsedda att användas men som lämnades aktiverade på abonnemanget.
Vid driftsättning av flera olika användningsfall tillhandahålls t.ex. röst- och datatjänster på alla abonnemang, men i verkligheten används röst endast av ett fåtal enheter i ett specifikt användningsfall. En angripare som får tillgång till ett SIM-kort i en sådan driftsättning kan potentiellt generera dyra röstsamtal eller på annat sätt orsaka ekonomisk skada.
Den huvudsakliga begränsningen som vi föreslår för dessa hot är triggers för enhetsändringar och tillhörande automatiseringsregler i Cisco IoT Control Center (IMEI-ändringsmeddelande), som automatiskt kan låsa abonnemanget och SIM-kortet om det sätts i en annan enhet. Andra riskreducerande funktioner inkluderar provisionering av rätt tjänsteuppsättning via API när en enhet har distribuerats, samt kontinuerlig övervakning av tjänsteutnyttjandet.
Andra hot mot din IoT-tjänst
Förutom hot mot enheter är överbelastningsattacker ett av de mer oroande hoten mot en IoT-tjänst. Om viktiga delar av infrastrukturen identifieras av en angripare kan en överbelastningsattack inledas, vilket kan leda till att hela din IoT-lösning blir helt offline. Detta blir möjligt när en lösning förlitar sig på internet för transport av data. Även om data är tunnlade och krypterade har gateways gränssnitt mot internet och är därmed utsatta för attacker om de skulle identifieras.
För att minska den här typen av risker måste överföringsvägen flyttas från internet till en privat domän. Genom att använda en privat interconnect, en privat molninterconnect eller till och med en virtuell privat interconnect skapas en separat väg hela vägen från enheten till kundens datacenter, där den aldrig passerar ett delat medium, vilket i sin tur gör det allt svårare för en angripare att hitta angreppsytor för överbelastningsattacker (denial-of-service).
Det handlar också om data- och nätverkssegmentering. Med en privat sammankoppling kan du inkludera IoT-enheterna på fältet i deras eget intranät, vilket ger samma säkerhetsprinciper som kundens övriga IT-tjänster, även om detta kanske inte alltid är den bästa lösningen.
Kanske finns det undergrupper av enheter som helst ska hållas utanför, och det är här segmentering kommer in i bilden. Med hjälp av privata APN:er kan kunden segmentera sina enheter i nätverkskategorier eller till och med separera data i dataklassificeringskategorier, var och en med separat adressering och slutpunkter påserversidan .När vi konfigurerar en ny kund går våra service managers vanligtvis igenom designen i detalj och väljer en konfiguration som är väl lämpad för kundens användningsbehov och krav .
Samverkande system
Tele2 IoT använder Cisco IoT Control Center som plattform för hantering av anslutningar. IoT Control Center är mycket kapabel när det gäller abonnemangskontroll, övervakning och automatisering och levereras med en omfattande uppsättning API:er för extern kontroll från kundens sida. En kund bör ställa krav på att även andra system som upphandlas har stöd för API:er så att styrsystemen kan interagera med varandra.
Ett exempel där den här typen av systeminteraktioner spelar in skulle kunna vara att en enhet (Enhet A) installeras och aktiveras på fältet med installatören som väljer användningsfall B som den angivna aktiviteten. Enhetshanteringsplattformen skulle sedan anropa CMP via ett API och begära att den tjänsteprofil som är associerad med användningsfall B tillhandahålls för enhet A. CMP kan sedan informera kundens applikation om att den kan förvänta sig att data associerade med användningsfall B kommer från prenumeration C som den har associerat med enhet A via länken som är associerad med APN D.
Om SIM-kortet flyttas till en annan enhet bryts relationen mellan enhet A och abonnemang C och CMP kan vidta åtgärder och informera både enhetshanteringen och kundens applikation. Båda kan innehålla logik för att begära att CMP vidtar åtgärder, eller om den konfigureras lokalt i CMP skulle den agera först och sedan informera de externa systemen för att förhindra ytterligare säkerhetsimplikationer.
Med rätt planering, utformning och konfiguration är en IoT-distribution mycket säker, även om begränsningar i användningsfallet, t.ex. budget, tvingar fram utformningsval där säkerheten inte är på den nivå som den borde vara enligt policyn.
Bästa praxis
- Håll koll på dina enheter:
- Var finns de, när placerades de där, kommer de att vara stationära eller röra sig, och hur är det tänkt att de ska kommunicera?
- Tänk igenom enhetens livscykel, inklusive underhåll av firmware
- Fysisk åtkomst, lösenord och tjänsternas tillgänglighet
- Automatiserad övervakning av tjänsteanvändning, ändring av enhetens plats och ändring av enhet, identitetsmeddelanden.
- Segmentering av nätverk och data, privata anslutningar för minskad exponering
- Möjliggör API-integration mellan komponenter för ökad kapacitet att genomdriva säkerhetspolicyer och agera vid överträdelser.
Om du vill veta mer om säkerhet och dataintegritet och hur du bäst skyddar din IoT-lösning är du välkommen att kontakta oss.
Jonas Hallman
IoT-arkitekt
Tele2 IoT
