IoT kontra traditionell pentestning – en jämförelse

Metodik: så genomför vi ett IoT-penetrationstest

Fas 1: Rekognosering och inventering

Innan vi rör en enda enhet behöver vi förstå vad som finns i miljön. Det låter självklart, men verkligheten är att de flesta organisationer saknar en komplett inventering av sina IoT-enheter. Opsios NOC-team har sett företag med tre gånger fler uppkopplade enheter än vad de själva trodde.

Praktiska steg:

• Passiv nätverksskanning med verktyg som Nmap (med IoT-specifika script) och Shodan för att identifiera exponerade enheter
• Firmware-identifiering – vilken version kör enheten, och finns det kända CVE:er?
• Protokollkartläggning – vilka kommunikationsvägar används? MQTT-broker, REST-API, BLE-advertisement?
• Dokumentationsgranskning – tekniska specifikationer, nätverksdiagram och eventuella säkerhetsdeklarationer från tillverkaren

Fas 2: Firmware-analys

Firmware-analys är ofta den mest avslöjande delen av ett IoT-penetrationstest. Här extraherar vi enhetens mjukvara och analyserar den i detalj.

Extraktion sker antingen genom nedladdning från tillverkarens uppdateringsserver, direkt avläsning av flash-minnet (via SPI eller parallell anslutning), eller genom JTAG/UART-gränssnitt. Verktyget Binwalk hanterar dekomprimering och filsystemsextraktion, medan Ghidra och IDA Pro används för djupare reverse engineering.

Vad vi letar efter:

• Hårdkodade lösenord och API-nycklar
• Kryptografiska brister – svaga algoritmer, återanvända nycklar, klartext
• Bakdörrar och debug-funktioner som glömts kvar i produktion
• Osäkra uppdateringsmekanismer (osignerad firmware, HTTP istället för HTTPS)

I en typisk analys hittar vi hårdkodade credentials i ungefär hälften av enheterna vi testar. Det är inte en överdrift – det är vad vi faktiskt ser.

Fas 3: Kommunikationsanalys

Här analyserar vi trafik mellan enheten, dess backend och eventuella mellanliggande system. Vi sätter upp man-in-the-middle-scenarion för att inspektera om data krypteras korrekt, om certifikatvalidering fungerar och om det finns möjligheter till replay-attacker.

MQTT – den mest använda protokollet i IoT – är ofta konfigurerat utan autentisering eller med standardlösenord. Vi ser detta regelbundet i Opsios SOC: enheter som publicerar sensordata till MQTT-brokers som vem som helst kan prenumerera på.

BLE och Zigbee kräver specialiserad hårdvara: Ubertooth One för Bluetooth-analys, och Killerbee-ramverket med lämplig radio för Zigbee. Målet är att identifiera om kommunikationen kan avlyssnas, manipuleras eller uppspelas.

Fas 4: API- och molnbackend-testning

IoT-enheter existerar inte i vakuum. Data lagras och bearbetas i molnet, och det är ofta här de allvarligaste sårbarheterna finns – inte på själva enheten.

Vi testar:

• Autentisering och auktorisering – kan en användare komma åt data från andra användares enheter (IDOR-sårbarheter)?
• API-säkerhet – input-validering, rate limiting, versionhantering
• Dataskydd – lagras personuppgifter krypterat? Uppfylls GDPR:s krav på dataminimering?

Burp Suite och OWASP ZAP är standardverktyg här, men vi kompletterar med manuell testning av enhetspecifika API-anrop som automatiserade verktyg inte känner till.

Molnsäkerhet

Fas 5: Fysisk säkerhetstestning

Om en angripare kan få fysisk åtkomst till en IoT-enhet – och det kan de ofta, eftersom enheter sitter i offentliga utrymmen, serverrum med bristfällig åtkomstkontroll eller på kunders anläggningar – öppnas helt nya attackvektorer.

Vi undersöker:

• Exponerade debug-portar (JTAG, UART) som ger direkt åtkomst till operativsystemet
• Möjlighet att extrahera flash-minne direkt från kretskortet
• Tamper-skydd – upptäcker enheten att den manipulerats?
• Boot-sekvens – kan vi avbryta boot-processen och få root-åtkomst?

Riskbedömning och prioritering

Att hitta sårbarheter är bara halva jobbet. Den verkliga utmaningen är att prioritera rätt. Vi använder en kombinerad metodik baserad på CVSS v4.0 och kontextuell riskbedömning som tar hänsyn till:

• Exploaterbarhet – hur lätt är sårbarheten att utnyttja i praktiken?
• Påverkan – vad händer om sårbarheten exploateras? Dataintrång, driftstopp, fysisk skada?
• Exponering – är enheten internetexponerad eller isolerad bakom brandvägg?
• Affärskritikalitet – är det en temperatursensor i ett konferensrum eller ett medicinskt implantat?

En sårbarhet med CVSS-poäng 7.5 på en isolerad sensor kan vara lägre prioritet än en sårbarhet med poäng 5.0 på en internetexponerad enhet i kritisk infrastruktur. Kontext avgör.

Regulatoriska krav som driver testning

NIS2-direktivet

NIS2, som trädde i kraft i EU:s medlemsstater under 2024–2025, ställer krav på att organisationer inom väsentliga och viktiga sektorer genomför regelbunden säkerhetstestning. IoT-enheter i sjukvård, energi, transport och vattenförsörjning faller direkt under dessa krav. Artikel 21 specificerar att riskanalys och säkerhetsåtgärder ska vara proportionella – men för uppkopplade enheter i kritisk infrastruktur innebär det i praktiken krav på penetrationstestning.

Cyber Resilience Act (CRA)

CRA, som börjar tillämpas stegvis från 2026, ställer krav på tillverkare av produkter med digitala element. Det innebär att IoT-enheter som säljs på EU-marknaden måste uppfylla grundläggande säkerhetskrav – inklusive sårbarhetsbedömning – redan innan de släpps. För organisationer som köper och driftar IoT-enheter ger CRA ett ramverk för att ställa krav på leverantörer.

ETSI EN 303 645

Denna europeiska standard specificerar grundläggande säkerhetskrav för konsument-IoT-enheter och fungerar som en konkret checklista vid penetrationstestning: inga standardlösenord, säkra uppdateringsmekanismer, krypterad kommunikation, minimal exponerad attackyta.

Managerade molntjänster

Verktygskedja för IoT-pentestning

Vad vi faktiskt hittar i produktion

Från Opsios SOC/NOC-erfarenhet med kunder som kör IoT-enheter i produktion – framför allt inom fastighetsautomation, sjukvård och logistik – ser vi återkommande mönster:

Standardlösenord som aldrig bytts. Det mest grundläggande, och fortfarande det vanligaste. Admin/admin, root/root, eller tillverkarspecifika standardlösenord som finns dokumenterade på internet.

Okrypterad MQTT-kommunikation. Sensordata som skickas i klartext – inklusive positionsdata, hälsodata och driftparametrar – till brokers utan TLS.

Avsaknad av nätverkssegmentering. IoT-enheter på samma VLAN som arbetsbelastningar med känslig data. En komprometterad kamera blir en brygga in i hela nätverket.

Firmware som inte kan uppdateras. Enheter utan OTA-kapacitet eller med brutna uppdateringsmekanismer, som kör firmware med kända sårbarheter.

Överdimensionerade molnbehörigheter. IoT-enhetens service account i AWS eller Azure har IAM-rättigheter långt utöver vad enheten behöver.

Managerad DevOps

Åtgärder efter testet

Ett penetrationstest utan åtgärdsplan är bara ett dyrt dokument. Så här strukturerar vi uppföljningen:

1. Omedelbar remediering (0–48 timmar) – kritiska sårbarheter med aktiv exploateringsmöjlighet: hårdkodade credentials, öppna debug-portar på internetexponerade enheter

2. Kortsiktig åtgärd (1–4 veckor) – nätverkssegmentering, krypteringsaktivering, behörighetsreduktion

3. Medellång sikt (1–3 månader) – firmware-uppgradering, implementation av övervakningsregler i SOC, leverantörsdialog om säkerhetsbrister

4. Långsiktig strategi – inköpspolicy som kräver ETSI EN 303 645-compliance, automatiserad IoT-inventering, integration av IoT-enheter i befintliga SIEM-plattformar

Cloud FinOps

Vanliga frågor

Vad skiljer IoT-penetrationstest från vanlig pentestning?

IoT-test omfattar betydligt fler attackytor: firmware, hårdvara, trådlösa protokoll (Zigbee, BLE, LoRa), molnbackend och API:er – utöver traditionell nätverks- och applikationstestning. Enheterna har dessutom ofta begränsade resurser, saknar patchmöjligheter och kör proprietära protokoll, vilket kräver specialiserade verktyg och metodik.

Vilka verktyg används vid IoT-penetrationstest?

Vanliga verktyg inkluderar Nmap och Shodan för rekognosering, Binwalk och Ghidra för firmware-analys, Burp Suite för API-testning, samt Ubertooth och Killerbee för Bluetooth- och Zigbee-analys. Ofta krävs också fysisk utrustning som JTAG/UART-adaptrar och logikanalysatorer.

Måste vi penetrationstesta våra IoT-enheter enligt NIS2?

NIS2-direktivet kräver att organisationer inom väsentliga och viktiga sektorer vidtar proportionella tekniska åtgärder, inklusive regelbunden säkerhetstestning. Penetrationstest av IoT-enheter i kritisk infrastruktur – exempelvis inom sjukvård, energi eller transport – faller tydligt under dessa krav.

Hur ofta bör IoT-enheter penetrationstestas?

Minst årligen, men även efter varje större firmware-uppdatering, nätverksförändring eller ny hotbild. Enheter i kritisk infrastruktur bör testas oftare – kvartalsvis eller vid varje change window. Automatiserad sårbarhetsskanning kompletterar men ersätter inte manuell pentestning.

Vad kostar ett IoT-penetrationstest?

Kostnaden varierar kraftigt beroende på antal enheter, komplexitet och testdjup. En enstaka enhetstyp med firmware-analys kan starta runt 80 000–150 000 SEK, medan en komplett bedömning av en IoT-miljö med flera enhetstyper, molnbackend och protokollanalys ofta landar på 300 000–600 000 SEK.