Category Archives: Swedish Written

Skyddar du fjärravlästa sensorer och mätare från obehörig hantering?

På senare tid har det legat mycket säkerhetsfokus på fjärravlästa sensorer och mätare. Inlägget riktar sig till den som äger och är intresserade av att insamling från- och administrering fungerar och har stabil funktionalitet. Finns det redan punkter på agendan i stil med “är vår information säker?”, “har vi en plan om våra sensorer blir hackade?” på den månatliga agendan för dina utvecklare och arkitekter? Arbetar detta forum med en löpande plan med punkter på förbättrings- och som följs upp? Isåfall kan du kan sluta läsa här, för jag tror att du redan är på rätt väg.

[This article will be available in English during august 2017]

Vems ansvar är det att lösningarna är säkra? Vems ansvar är det att garantera att det finns kunskap och en dagsaktuell definition om vad säkerhet är?

Tillåt mig konifiera detta till tre tänkbara orsaker att säkerheten inte är på agendan. Kanske finns det höga tankar om att säkerheten redan är okej. Kanske är inte ämnet det är viktigaste på agendan mot för defekter och nyutveckling? eller tänker man att det inte kan hända något allvarligt. Sensorer och mätare installeras varje dag någonstans, kort sagt överallt och i allt. Exempelvis följa krav och normer för att bevisa energiutnyttjande eller timavläst konsumtion. I andra fall för att göra fastigheter mer attraktiva för uthyrning. I ytterligare fall i rent proaktivt syfte för att kunna förutse och åtgärda händelser innan de blir allvarliga. Med IoT har ett uppsving skett med nya sorters sensorer och för nya sorts användningsområden. Som en krydda på det goda, följer en liten svans av genomförd design och påhittade funktioner som inte genomgått ett riktigt säkerhetsarbete.

De sensorer och mätare jag syftar på kommunicerar över nätverk. De blir inte avlästa visuellt. Kommunikation sker vanligtvis över det öppna Internet med TCP eller UDP till centrala insamlingspunkter eller till datainsamlingssystem. Senare hamnar de i olika sorts lagringssystem (datawarehouse, bigdata..) för debitering, felsökning, analys och trendsökning. Påfallande ofta är informationen som skickas fullt läsbar under tiden den transporteras mellan nätverken. Är den inte i läsbar klartext såsom XML, CSV eller JSON, följer den troligen en väl etablerad och dokumenterad industriell standard, som exempelvis OPC ModBus. Därmed lättsamt att avkoda med standardprogram eller ett par timmars eget programhack med stöd av tillgängliga dokument. Sensorer kan i förekommande fall även administreras på distans. Men sensorer har funnits länge och skickat data och fungerat för debitering i åratal. Det fungerar ju bra, varför krångla?

“If it ain’t broke, don’t fix it”

Det finns öppna säkerhetshot – just nu

Det finns ett säkerhetshot i detta, på riktigt. Vad tycker du är det större hotet mellan avsaknad på säkerhet eller brist på att bekosta och prioritera säkerhet? Hot mot uppkopplade styr- och reglersensorer nämns ständigt. nyligen i SVT, så ytterligare evidens för påståendet behövs inte just nu. Medvetenheten kring dessa system och vilken påverkan de kan ha, ökar och breddar ut sig över världen. Ett enkelt exempel är fjärrstyrning av värmeanläggningar. Ibland är dessa system helt vidöppna på Internet, med publika tillgängliga IP adresser.

“Förbjud” försäljning och bindning av avtal som på något sätt knyter ihop säkerhet med en kostnad eller prissättning. Låt all form av säkerhet vara inkluderad, så ingen börjar dobbla bort säkerhet på grund av att låta kostnader och intäkter kunna påverkas av det

Det skapas dagligen någon sorts programvara med syftet att automatiskt söka svagheter och sårbara uppkopplade enheter och system. I några bättre fall ligger sårbara mätare och sensorer bakom ett NAT, vilket till viss del ökar säkerheten mot sådan spårning. En mer riktad attack kan däremot komma igenom svagheter i NAT-ningen och därefter komma åt uppkopplade enheter. Det är påfallande ofta som NAT-lösningar nedprioriteras, antingen undviks de eller så används amatörutrustning. Utövare av sensoravläsning kanske klagar över krångligare konfigurationer, att bättre hårdvara innebär högre kostnader för installationer. Kostnader som i sin tur skiktar upp kunder i olika segment. Påföljden, generaliserat, att det kostnadsmedvetna segmentet hittar på egna lösningar som de tycker passar sin kostnadsprofil. På den motsatta sidan finns större “drakar”, som tycker sig ha råd att bygga egna lösningar. I det senare fallet tilltar istället risken för lösningar som projektstyrts med agilt och funktionellt fokus. Om säkerhetstänket då var “momsen som drogs av i slutet på budgeten/tidsplanen”, är det hundratusentals mätare och sensorer som kan påverkas i samma hack.

Ute i verkligheten kan det saknas inloggningsmekanismer och det finns mätare som “rings upp” och tillfrågas en och en. Kanske det också saknas krypterade anslutningar, eller med certifikat som är ogiltiga eller gjorda med tveksamma utfärdare. Inte sällan görs nya installationer av mätare och sensorer tillgängliga med standardinställningar, publika långt innan de tas under kontroll av fjärravläsnings-systemen. En del hårdvara kan innehålla funktioner att svara på hur de fungerar. Skulle inte systemen gå att tillfråga, kan trafikanalys eventuellt avslöja vilken tillverkare och modell det rör sig om. Väl identifierad har tillverkaren troligen en manual utlagd på sin webb, eller någon partner lagt ut den, i god tro.

Vad kan göras bättre då?

Känner du dig osäker? Jag kan antagligen ge dig en genomlysning med fokusområden och förslagsplan efter några timmars instudering och med lite information om leverantörer, system och hårdvara. Men mycket kan göras på egen hand, utan att hämta sådant stöd. Först och främst: Prata om säkerhet på den egna agendan, ta reda på vad teamet anser om Informationssäkerhet generellt och det egna arbetsområdet i synnerlighet. Vad är definition avsäkerhet? Bygg ihop en lista på skillnaderna mellan nuläge och definitionen. Brainstorma om scenarion som kan uppstå om det inträffar olika saker. Vilken påverkan har det? Hur återhämtar man sig? Sen tillsätt och prioritera konkreta aktiviteter för att identifiera vad som faktiskt är svagheter och hur de ska åtgärdas.

Det kan idag löna sig att dra ned på innovationstakten, till förmån för att säkra upp med ett bottenvarv

Informationsäkerhet är något tvärfunktionellt som gäller mer än i det tekniska. Hur arbetar anställda med företagets information internt? Hur lagras och förnyas lösenord? Hur skickas de till kunder och medarbetare? Finns det moment i arbetsmiljön som försvårar säkerhetsmekanismker, så man arbetar runt dem (postit-på-skärmen-syndrom)? Finns det andra öppna system, API’er och tjänster som leder in på bolagets nätverk?

Den sista retroaktiva frågan kanske känns utanför “informationssäkerhets”-området, men se det indirekt med följande exempel: Ponera att en svepattack träffar bolagets nätverk Z1. Den exponerar en instans av MongoDB som råkade ut för en global svepattack & hackats. Den instansen kan sedan ha släppt ut information såsom ip-adresser till hundratusentals sensorer för vida världen. Kanske det även låg närtids-mätvärden på den databasen, så hackaren kan dessutom se vilka sensorer som tycks leva och vad de producerar. Det här är inte långsökt. Det hände senast i dagarna.

Som tur är fick hackingen ingen demografisk data, eftersom det låg i en annan databas och teknik – MongoDB admin

Det är givetvis ett stort frågetecken varför det lämnas internet-öppna databaser utan lösenord för admin. Men ibland är svaret att nyfikna utvecklare gör sitt jobb och testar andra tekniker, kanske utanför sitt expertisområde. Visar demonstrationer med kopior på riktig information. Kanske slarvar med att stänga ned tjänsterna efter att de testas. För att sluta cirkeln med ämnet publika (tillgängliga) sensorer och mätare:

  • Kräv som en del i det vardagliga arbetet att penetrationstester görs på information som går till och från sändare och mottagare. Utred vad för information som sprids och varför. Även principiellt, inte bara tekniskt.
  • Se till att någon eller några i teamet kan paketanalys samt dissekering av data på de protokoll som mätarna eller sensorerna använder.
  • Lägg säkerhetsarbete som leverabel i varje testbar funktion som programmeras samt även på övergripande nivå med design och arkitektur.
  • Om en säkerhetsmekanism prioriteras bort till förmån att hinna få ut en ny funktion eller legalt krav inom tid: Vad är planen att ta igen det senare? Vad kommer det kosta, när kommer det göras? Ha alltid en plan.
  • Anlita externa granskare för säkerheten för att avlägga rapport och förslag. Sätt en tidspunkt i horisonten där det görs en avstämning.
  • Någon eller några ur den egna personalen ska kunna förstå, nyutveckla och föra underhåll av säkerhet.
  • Närmare samarbete med partners och leverantörer av sensorer/mätare för att få bättre möjligheter att ge input som påverkar dem att konstruera säkrare enheter.
  • “Förbjud” försäljning och bindning av avtal som på något sätt knyter ihop säkerhet med en kostnad eller prissättning. Låt all form av säkerhet vara inkluderad, så ingen börjar dobbla bort säkerhet på grund av att låta kostnader och intäkter kunna påverkas av det.

Delmål alla system borde uppnå

Målet som säkerhetsarbete bör sikta mot är att skydda sensorer mot otillåten åtkomst. Allra minst ett grundläggande “skalskydd” som krav. Om det innebär att arbetet tar lite längre tid, inkludera mertiden som en kostnad för att senare effektivisera.

Det ska vara svårare att se informationen som överförs. Förutom att ha SSL anslutning, finns gott om metoder att också shiffrera datat under tiden det är i transport. Mycket grundläggande är XOR kryptering eller base43, men självklart är mer moderna krypteringsalgoritmer som AES att föredra.

Information om sensorer och var de finns geografiskt behöver skyddas. Dels hur datat lagras i systemen men även i den information som skickas under överföringen, förutom lagrade mätdata.

Integriteten i den information som skickas från mätare och sensorer ska kunna verifieras som intakt, av det insamlande systemet. Är den inte det, hur agera? Om den är det, har den mellanlandat på obetrodda källor innan ankomst? Hur verifiera på det, och sen agera på det? Tänk på att varje länkbyte har en levande nätverksadministratör.