Attackytan: Där IT möter OT

Den mest kritiska ytan i de flesta industriella nätverk är gränsen mellan IT och OT — den så kallade IT/OT-DMZ:n. Enligt Gartner har konvergensen mellan IT- och OT-nätverk ökat dramatiskt under de senaste åren, drivet av Industry 4.0-initiativ, fjärråtkomstbehov och IoT-sensorik. Den här konvergensen skapar attackvägar som inte existerade för tio år sedan.

Vanliga ingångspunkter vi ser i praktiken

Från Opsios SOC-verksamhet observerar vi återkommande mönster i hur industriella miljöer komprometteras:

Fjärråtkomstlösningar — VPN-tunnlar, TeamViewer-installationer eller leverantörsanslutningar som aldrig stängdes efter driftsättning. Många industriföretag har fortfarande flat-nätverksarkitektur där fjärråtkomst ger direkt åtkomst till SCADA-segmentet.

Historiker och databryggor — Historian-servrar (exempelvis OSIsoft PI) som sitter med ett ben i IT och ett i OT, ofta med generösa brandväggsregler åt båda håll.

Opatchade Windows-system — HMI-stationer som kör Windows 7 eller XP Embedded utan säkerhetsuppdateringar, eftersom leverantören inte certifierat nyare OS-versioner.

USB och portabla medier — Fortfarande en av de vanligaste vektorerna i luftgapade miljöer, trots decennier av medvetenhetskampanjer.

Trådlös kommunikation — Wi-Fi-accesspunkter i produktionsnätet, Bluetooth-anslutningar till instrumentering, eller felkonfigurerade LoRaWAN-gateways.

Metodik: Så genomför ni ett OT-pentest utan att störa produktionen

Ett OT-pentest måste följa en striktare process än ett standard-pentest. Nedan beskriver vi den metodik som ger maximalt värde med minimerad risk.

Fas 1: Kartläggning och avgränsning

Innan en enda skanning skickas behöver ni definiera scope med kirurgisk precision. Det handlar om att:

• Identifiera alla tillgångar — Många industriella nät har bristfällig dokumentation. Passiv nätverksanalys med verktyg som Grassmarlin eller SPAN-portar ger en bild av faktisk trafik utan att introducera risk.
• Klassificera kritikalitet — Vilka system får absolut inte störas? Vilka har redundans? Vilka kan testas under underhåll?
• Definiera testgränser — Tydliga regler för vad testaren får och inte får göra. Exempelvis: aktiv skanning tillåten i IT/OT-DMZ, enbart passiv analys i processegmentet, aktiv testning av PLC-logik bara i testbädd.
• Etablera nödstopp — En direkt kommunikationslinje till processoperatörerna och en överenskommen avbrytsprocedur.

Fas 2: Passiv rekognosering

I produktionsnätet börjar vi alltid passivt. Det innebär att lyssna på nätverkstrafik utan att injicera egna paket. Här kartlägger vi:

• Kommunikationsmönster mellan PLC, HMI och SCADA-servrar
• Protokollanvändning och versioner
• Autentiseringsmekanismer (eller bristen på dem)
• Nätverkssegmentering i praktiken — inte enligt nätverksdiagrammet utan enligt faktisk trafik

Redan i detta steg hittar erfarna testare kritiska fynd. Vi ser regelbundet Modbus-trafik som passerar osegmenterat genom hela nätverket, PLC-enheter som svarar på broadcast-förfrågningar de inte borde nå, och SNMP v1/v2c med publika community-strängar.

Fas 3: Aktiv testning i kontrollerade miljöer

Aktiva tester — portskanningar, exploateringsförsök, fuzzing — utför vi i tre kontexter:

1. Testbädd/lab — En speglad miljö med identisk hårdvara och firmware. Det är den säkraste varianten och ger störst frihet.

2. Icke-kritiska system — Exempelvis test- eller staging-versioner av HMI-applikationer.

3. Produktionsmiljö under underhåll — Med fulla avbrytsprocedurer, redundanssystem aktiva och operatörer i standby.

Fas 4: IT/OT-gränstestning

Det här är ofta den mest givande delen av testet. Vi testar systematiskt:

• Kan vi från IT-nätverket nå OT-segmentet? Via vilka vägar?
• Fungerar brandväggsreglerna som de ska, eller finns det "temporära" undantag som blivit permanenta?
• Kan vi pivotera från en komprometterad historian-server in i processnätet?
• Hur väl fungerar detektionsmekanismerna? Utlöser vår aktivitet larm i SOC:en?

Molnsäkerhet och SOC-övervakning

Regulatoriska krav: NIS2, CRA och IEC 62443

Det regulatoriska trycket på OT-säkerhet har intensifierats markant. Tre ramverk är särskilt relevanta för svenska industriföretag.

NIS2-direktivet

NIS2, som trädde i kraft i EU-medlemsstaterna, utvidgar kretsen av organisationer som omfattas och skärper kraven på riskhantering. Energi, transport, vatten, tillverkning och digital infrastruktur ingår bland de sektorer som klassas som väsentliga eller viktiga entiteter. Direktivet kräver bland annat regelbunden testning av säkerhetslösningar och incidentrapportering inom 24 timmar.

För industriella verksamheter innebär NIS2 i praktiken att ni behöver kunna visa att ni testar era system systematiskt — inte bara ert kontor-IT utan hela den operativa miljön.

Cyber Resilience Act (CRA)

CRA riktar sig mot tillverkare av produkter med digitala element, men påverkar även industriella slutanvändare. Produkter som säljs på EU-marknaden — inklusive industriella IoT-sensorer, gateway-enheter och styrenheter — måste uppfylla grundläggande cybersäkerhetskrav. Det innebär att er leverantörskedja kommer att behöva visa säkerhetsdokumentation, och att ni som köpare har anledning att verifiera dessa påståenden genom egna tester.

IEC 62443

IEC 62443 är den internationella standardserien som specifikt adresserar säkerhet i industriella automations- och kontrollsystem. Den ger ett ramverk för att definiera säkerhetsnivåer (Security Levels 1–4) och är den naturliga standarden att mappa era pentest-resultat mot. Många av våra kunder använder IEC 62443 som grund för sitt säkerhetsprogram och pentest-scopet definieras utifrån standardens zoner och kanaler.

Verktyg och tekniker som faktiskt fungerar i OT

Standardverktygen från IT-pentest fungerar sällan rakt av i OT. Här är vad som faktiskt ger resultat:

Passiv analys:

• Grassmarlin — Utvecklat av NSA, open source. Ger nätverkskartläggning utan aktiv trafik.
• Wireshark med industridissektorer — Stöd för Modbus, S7comm, DNP3, EtherNet/IP.
• Zeek (tidigare Bro) — Nätverksmonitorering med OT-specifika loggar.

Aktiv testning (i lab/testbädd):

• Redpoint Nmap NSE-skript — Skräddarsydda skanningsskript för industriella protokoll.
• ISF (Industrial Security Framework) — Open source-ramverk för OT-exploatering.
• Codesys-specifika testverktyg — För enheter som kör Codesys runtime.

OT-specifika sårbarhetsdatabaser:

• ICS-CERT Advisories (CISA)
• CVE-poster specifikt taggade med ICS-relevans
• Leverantörsspecifika säkerhetsbulletiner (Siemens ProductCERT, Rockwell Knowledgebase)

Vad ett pentest-rapport bör innehålla

En rapport som bara listar CVE:er och CVSS-poäng ger minimalt värde i OT-sammanhang. Det vi rekommenderar — och levererar — inkluderar:

• Attackkedjor — Inte isolerade sårbarheter utan kompletta sekvenser: "Från phishing-mail till manipulerad set-point i 4 steg"
• Affärspåverkan — Vad kan faktiskt hända? Produktionsstopp, miljöutsläpp, kvalitetsavvikelse?
• Prioriterad åtgärdslista — Realistiska rekommendationer som tar hänsyn till OT-livscykler. "Patcha omedelbart" är sällan realistiskt för en 15 år gammal PLC — men nätverkssegmentering kan implementeras snabbt.
• Regulatorisk mappning — Hur relaterar fynden till NIS2-krav och IEC 62443 Security Levels?

Managerade molntjänster för industri

Opsios perspektiv: Vad vi ser från SOC

Från vår 24/7-SOC i Karlstad ser vi en tydlig trend: attackerna mot OT-miljöer blir mer sofistikerade och mer riktade. Det räcker inte längre med perimetersäkerhet. Angripare som väl tagit sig in i IT-miljön har ofta relativt fri tillgång till OT-segmentet — inte på grund av avsaknad av brandväggar, utan på grund av regler som tillåter mer trafik än vad som egentligen behövs.

De tre vanligaste fynden i våra OT-pentester under det senaste året:

1. Överdrivet generösa brandväggsregler i IT/OT-DMZ — "Tillåt alla portar från historian-servern" är vanligare än någon vill erkänna.

2. Default-lösenord på nätverksenheter i OT-segmentet — Switchar, routrar och trådlösa accesspunkter med fabriksinställningar.

3. Avsaknad av monitorering i OT-nätet — Även organisationer med mogen IT-SOC har ofta noll insyn i OT-trafiken.

Managerad DevOps och säkerhetsautomation

Vanliga frågor

Kan pentest i OT-miljöer orsaka produktionsstopp?

Ja, om det genomförs felaktigt. Aggressiv portskanning eller fuzzing mot äldre PLC-enheter kan trigga oväntade tillstånd. Därför arbetar seriösa testare med passiva analysmetoder i produktionsnätet och sparar aktiva tester till isolerade testbäddar eller underhållsfönster. Det är en av de viktigaste skillnaderna mot traditionell IT-pentest.

Kräver NIS2 att vi utför penetrationstestning?

NIS2-direktivet kräver inte uttryckligen pentest, men det ställer krav på att väsentliga och viktiga entiteter vidtar proportionella tekniska och organisatoriska säkerhetsåtgärder, inklusive riskbedömning och testning av säkerhetslösningar. I praktiken blir pentest den mest konkreta metoden att visa regelefterlevnad.

Hur ofta bör vi genomföra OT-pentest?

Minst en gång per år som baslinje, men även vid större förändringar — exempelvis nya nätverkssegment, firmware-uppgraderingar eller integration av nya IoT-sensorer. Kontinuerlig passiv övervakning kompletterar de periodiska testerna och fångar konfigurationsdrift mellan tester.

Vad är skillnaden mellan en sårbarhetsskanning och ett pentest i OT?

En sårbarhetsskanning identifierar kända CVE:er automatiskt men testar inte om de faktiskt kan utnyttjas i er specifika miljö. Ett pentest går steget längre: testaren försöker aktivt exploatera svagheter, kedja ihop attacker och visa vilken faktisk affärspåverkan — exempelvis om en komprometterad HMI kan manipulera en fysisk process.

Kan vi köra pentest mot SCADA utan att stänga ner produktionen?

Det beror på arkitekturen. I välsegmenterade miljöer kan du testa nätverksgränser, IT/OT-DMZ och fjärråtkomstlösningar utan att röra produktionssystemet direkt. Tester mot själva SCADA-servrarna och PLC-logiken bör ske i en spegelmiljö eller under planerat underhåll.