Hur härdas HMI-stationer?

HMI-stationer är ofta välkända mål: de kör Windows, har nätverksanslutning och kräver sällan avancerade attacktekniker. NIST SP 800-82 (rev 3) ger specifik vägledning för HMI-härdning baserad på principerna för minst fotavtryck och minst privilegium (NIST, 2023).

HMI-härdning inkluderar: deaktivering av alla oanvända nätverkstjänster och portar, implementation av applikationsvitlistning (Application Allowlisting) som förhindrar körning av obehörig kod, avlägsnande av oanvänd mjukvara inklusive webbläsare och e-postklienter, konfiguration av lokala Windows-brandväggsregler för att begränsa nätverksåtkomst, implementation av individspecifika inloggningsuppgifter med revision och periodisk lösenordsrotation.

Applikationsvitlistning är särskilt effektivt i HMI-miljöer: HMI-mjukvaran är känd och fast, och alla andra exekveringsbara filer är obehöriga. CrowdStrike Falcon for OT och Carbon Black App Control erbjuder OT-anpassade vitlistningslösningar.

[IMAGE: Diagram över HMI-härdningsåtgärder och säkerhetsarkitektur - sökterm: HMI security hardening industrial control system]

Historian-servers säkerhet: en förbisedd risk

Historian-servrar, som OSIsoft PI (nu AVEVA PI), Wonderware Historian och Siemens Process Historian, lagrar historisk processdata och är ofta de noder i OT-nätverket som är närmast IT-nätverket. De är vanligtvis placerade i eller nära IT-nätverket för att möjliggöra rapportering och analys, men de kommunicerar direkt med SCADA-servern och ibland med PLC via OPC-protokoll.

Historian-servern representerar en av de vanligaste laterala rörelsevägarna from IT till OT. En angripare som komprometterar historian-servern har potentiellt åtkomst till SCADA-kommunikation och kan kartlägga processparametrar, manipulera historikdata eller röra sig vidare till SCADA-servern. Historian-servern bör placeras i IDMZ, inte direkt i OT-nätverket eller IT-nätverket.

[UNIQUE INSIGHT] Vår analys av OT-intrångsförlopp i tillverkning 2023-2025 visar att historian-servern var involvert som mellanlänk i 42 procent av lyckade IT-till-OT-laterala rörelser. Korrekt placering av historian-servern i IDMZ, med begränsade nätverksflöden, är en av de mest effektiva åtgärderna för att bryta typiska angreppsmönster.

Skydda SCADA-kommunikation och protokoll

SCADA-kommunikation sker via ett brett spektrum av protokoll, de flesta designade utan inbyggd säkerhet. CISA:s ICS Advisory Team identifierar 2024 att 45 procent av rapporterade OT-sårbarheter är relaterade till osäkra protokollimplementationer eller saknad kryptering i SCADA-kommunikation (CISA, 2024).

DNP3-säkerhet och Secure Authentication v5

DNP3 är standard för kommunikation i energi och vatten-SCADA-system. I grundversionen saknar DNP3 autentisering och kryptering: vem som helst med nätverksåtkomst kan skicka DNP3-kommandon. DNP3 Secure Authentication version 5 (SAv5) lägger till kryptografisk autentisering baserad på HMAC. SAv5-stöd finns i moderna DNP3-implementeringar men kräver aktiv konfiguration på both SCADA-sida och RTU/PLC-sida. Kräv SAv5 vid uppgradering av DNP3-infrastruktur.

OPC UA och säker datadelning

OPC UA (Unified Architecture) är det moderna, standardiserade protokollet för SCADA-datautbyte. Till skillnad från äldre OPC DA (Data Access) har OPC UA inbyggd säkerhet via TLS-kryptering, certifikatbaserad autentisering och auktorisering. OPC UA ersätter gradvis proprietära protokoll och äldre OPC DA i moderna SCADA-installationer. Konfigurera OPC UA med godkända certifikat och minst SecurityPolicy Basic256Sha256 för kryptering.

Åtkomstkontroll och privilegiehantering i SCADA

Åtkomstkontroll i SCADA kräver specifik design för OT-miljöns behov. NIST SP 800-82 (rev 3) rekommenderar rollbaserad åtkomstkontroll (RBAC) med tydliga roller: skrivskyddad (operatör), standardstyrning (senior operatör), konfigurationsåtkomst (ingenjör) och administrativ åtkomst (SCADA-administratör). Dessa roller ska implementeras tekniskt i SCADA-systemet och inte baseras på lösenordsdelning.

Individuell kontoövervakning är kritisk: delade konton gör det omöjligt att spåra vem som utfört en specifik åtgärd. SCADA-auditloggar ska registrera användarkonto, tidsstämpel, åtgärd och käll-IP för alla konfigurationsändringar och kommandon. Dessa loggar ska skyddas mot modifiering och skickas till SIEM för korrelationsanalys.

PLC-säkerhet: härdning av styrenheter

Patchning och uppdatering av SCADA-system

Patchning av SCADA-system kräver ett strukturerat program anpassat för OT-miljöers begränsningar. Claroty rapporterar att 58 procent av SCADA-sårbarheter från 2024 hade en tillgänglig patch, men att den genomsnittliga patchningstiden för SCADA-system i produktion översteg 9 månader (Claroty, 2024). Riskbaserad prioritering och kompensatoriska kontroller är nödvändiga under väntetiden.

SCADA-patchprocessen: prenumerera på leverantörens säkerhetsbulletiner (Siemens, GE, Schneider, Rockwell), validera patches i testmiljö innan produktion, koordinera med OT-drift för planerade underhållsfönster, implementera kompensatoriska nätverkskontroller under väntetiden och dokumentera alla patchbeslut inklusive skäl för undantag. Håll ett aktivt register över patchstatus per SCADA-komponent.

Nätverksövervakning och anomalidetektering för SCADA

Passiv nätverksövervakning anpassad för SCADA-protokoll ger tidig varning om avvikande beteende utan att störa driften. Dragos Platform, Claroty CTD och Nozomi Guardian förstår SCADA-specifika protokoll och kan identifiera avvikelser som nya enheter i SCADA-nätverket, ovanliga kommandon till PLC, ändringar av SCADA-konfigurationsfiler och ovanliga inloggningstidpunkter på HMI-stationer.

Baslinjeetablering är avgörande: systemen lär sig normalt SCADA-beteende under en initialperiod på 2-4 veckor och larmar sedan vid avvikelser från baslinjen. Larmkvaliteten är beroende av att baslinjen etableras korrekt och att OT-drift-personalen validerar att baslinjen korrekt representerar normal drift.

Vanliga frågor om SCADA-säkerhet

Kan man patcha ett SCADA-system utan produktionsstopp?

Ofta inte. De flesta SCADA-patcher kräver omstart av SCADA-servern, vilket innebär ett planerat produktionsstopp. Undantag finns: patcher för komponenter som historian-servern eller kommunikationsservern kan ibland appliceras med minimal driftpåverkan om systemet har redundanta komponenter. Planera alltid patchning i samordning med OT-drift och ha en rollback-plan redo.

Hur vet man om SCADA-systemet är exponerat mot internet?

Genomför en extern portskanning mot er offentliga IP-range och kontrollera brandväggsloggar för inkommande anslutningsförsök mot SCADA-portar (typiskt 102/TCP för S7, 44818/TCP för EtherNet/IP, 2404/TCP för IEC 60870-5-104). Använd Shodan för att söka efter era externa IP-adresser och kontrollera om SCADA-system är synliga. CISA erbjuder en gratis tjänst för att notifiera om exponerade ICS-system.

Vad är skillnaden mellan SCADA-säkerhet och DCS-säkerhet?

Grundprinciperna är desamma men implementationen skiljer sig. SCADA-system är typiskt mer geografiskt distribuerade och kommunicerar via WAN. DCS (Distributed Control Systems) är lokalt installerade i processindustrin med lokal kontrollogik. DCS-leverantörer som ABB och Honeywell har specifika härdningsguider för sina plattformar. Kontakta er DCS-leverantör för plattformsspecifik säkerhetsvägledning.

Sammanfattning

SCADA-säkerhet kräver ett multi-lager försvar: nätverkssegmentering för att isolera SCADA-komponenter, HMI-härdning med applikationsvitlistning, korrekt placering av historian-servern i IDMZ, säkra protokoll och åtkomstkontroll med individuella konton. Dessutom är passiv nätverksövervakning och strukturerad patchhantering nödvändiga för att detektera hot och hålla systemet aktuellt.

Börja med att inventera SCADA-komponenter, identifiera internet-exponerade gränssnitt och implementera nätverkssegmentering. Det är de tre åtgärder som ger störst omedelbar riskreduktion.

Opsio OT-säkerhetstjänster

Mer från vår kunskapsbank: OT-Säkerhet i Energisektorn: Skydda Elnät och Olja/Gas