OT Säkerhet

Översikt

Vad OT-säkerhet är, varför det finns som ett eget fält och vad som gör det fundamentalt annorlunda från att säkra traditionella IT-system.

Var du ser detta: Relevant i industriella miljöer, kritisk infrastruktur och överallt där IT-nätverk ansluter till operationsteknologisystem.

Vad det är

Operational technology-säkerhet omfattar skyddet av hårdvara och mjukvara som övervakar och styr fysisk utrustning, processer och händelser. Det inkluderar industriella styrsystem, SCADA-system, PLC:er, RTU:er och de nätverk som förbinder dem. Fältet finns till eftersom dessa system har unika arkitekturer, protokoll, begränsningar och hotmodeller som traditionell IT-säkerhet inte adresserar.

Nyckelpunkter
  • OT-system styr fysiska processer i realtid, där ett säkerhetsfel kan få omedelbara fysiska konsekvenser.
  • De flesta OT-miljöer kör äldre hårdvara och mjukvara som inte kan patchas eller uppdateras i normal takt.
  • Funktionssäkerhet och tillgänglighet är de primära operativa prioriteringarna, vilket fundamentalt formar varje säkerhetsbeslut.
  • IT-säkerhetspraxis kan inte tillämpas direkt på OT utan förståelse för hur industriella protokoll, arkitekturer och begränsningar skiljer sig.

Hur det fungerar i stora drag

  1. Förstå att OT-miljöer definieras av sin fysiska process. Säkerhetsmodellen följer av vad systemet styr och vad ett misslyckande skulle innebära.
  2. Kartlägg miljön med Purdue-modellen eller IEC 62443:s zon- och kanalansats för att förstå vad som är anslutet till vad och var gränser bör finnas.
  3. Identifiera vilka system som är funktionssäkerhetskritiska kontra produktionskritiska kontra enbart övervakande, eftersom risk och acceptabla kontroller skiljer sig för varje kategori.
  4. Tillämpa nätverkssegmentering för att isolera OT från IT, begränsa dataflöden till det nödvändiga och säkerställa att en kompromiss i IT inte direkt kan nå styrsystem.
  5. Bygg synlighet innan du försöker härda. Passiv övervakning av OT-nätverk är ofta säkrare än aktiv skanning, som kan krascha äldre enheter.

Konkret exempel

Ett energibolag ansluter sina understationsstyrsystem till ett företags-IT-nätverk för fjärrövervakning och faktureringsdata. Utan segmentering kan en angripare som komprometterar en företags-e-postserver potentiellt pivota till det operativa nätverket och interagera med utrustning som styr elnätet. OT-säkerhet adresserar exakt denna typ av risk, att definiera var gränsen går, vad som kan passera den och hur man upptäcker när något oväntat händer.

Varför det är viktigt

OT-system driver den infrastruktur som samhället är beroende av. En attack som korrumperar en finansiell databas är allvarlig. En attack som stänger ner ett vattenreningsverk, slår ut ett elnät eller gör att en kemisk anläggning beter sig oväntat är en helt annan kategori av problem. Allteftersom OT-system fick nätverksanslutningar och kopplades till IT-miljöer ärvde de IT-världens exponering utan decennierna av säkerhetshärdning som IT-system genomgått.

Säkerhetsperspektiv

  • I OT går tillgänglighet och funktionssäkerhet före konfidentialitet. En säkerhetskontroll som riskerar systemkrasch eller ett osäkert fysiskt tillstånd är vanligtvis fel kontroll.
  • Patchning är ofta omöjlig eller kraftigt försenad i OT. Kompenserande kontroller som nätverkssegmentering, applikationswhitelisting och övervakning blir de primära försvaren.
  • Hotaktörer som riktar in sig på OT-miljöer inkluderar nationalstatliga aktörer med långa uppehållstider och specifika fysiska mål som syfte, inte bara datastöld.

Vanliga fallgropar

  • Att tillämpa IT-säkerhetsverktyg direkt på OT-nätverk utan testning. Aktiva sårbarhetsscanners har krascht PLC:er och orsakat oplanerade driftstopp.
  • Att anta att luftgap fortfarande existerar. De flesta moderna OT-miljöer har någon form av IT-anslutning, ofta via underhållsdatorer, fjärråtkomst från leverantörer eller historiseringsservrar.
  • Att enbart fokusera på nätverkssäkerhet och ignorera fysisk åtkomst, som ofta är den mest realistiska attackvägen in i en OT-miljö.

FÖRDJUPNING

Varifrån OT-säkerhet kommer

Industriella styrsystem har funnits långt innan cybersäkerhet var ett begrepp. PLC:er introducerades i slutet av 1960-talet för att ersätta relälogik i tillverkning. SCADA-system växte fram för att hantera geografiskt spridd infrastruktur som rörledningar och elnät. I decennier opererade dessa system i isolering, fysiskt separerade från företagsnätverk och internet, med proprietära protokoll som bara specialister förstod.

Den isoleringen skapade en falsk trygghet som kallas security through obscurity. Antagandet var att om utomstående inte kunde nå ett system och inte förstod dess protokoll, var det säkert. Detta antagande började bryta ihop i takt med att organisationer anslöt OT till IT av legitima affärsskäl: fjärrdiagnostik, realtidsproduktionsdata, leverantörssupportanslutningar och integration med företagssystem.

Upptäckten av Stuxnet 2010 förändrade hur säkerhetsgemenskapen förstod OT-risk. Stuxnet var ett sofistikerat skadeprogram som specifikt riktade in sig på Siemens PLC:er i urananrikningscentrifuger. Det visade att industriella styrsystem kunde angripas med precision, att angripare kunde förstå OT-protokoll tillräckligt väl för att manipulera fysiska processer och att inte ens luftgapade system var immuna. Efter Stuxnet blev OT-säkerhet en seriös disciplin snarare än en nischfråga.

Den grundläggande spänningen: funktionssäkerhet mot cybersäkerhet

I IT är CIA-triaden (konfidentialitet, integritet, tillgänglighet) ett användbart ramverk för att tänka kring säkerhetsprioriteringar. I OT är ordningen nästan omvänd och ett fjärde bekymmer läggs till: funktionssäkerhet. Den primära skyldigheten för ett industriellt styrsystem är att styra en fysisk process tillförlitligt och säkert. Säkerhetsåtgärder som riskerar att störa den skyldigheten är inte acceptabla, oavsett hur effektiva de kan vara ur ett rent cybersäkerhetsperspektiv.

Detta skapar verkliga begränsningar. Du kan inte patcha en PLC som kör en kontinuerlig kemisk process under arbetstid. Du kan inte installera en endpoint-agent på firmware-baserad utrustning som leverantören inte stöder. Du kan inte svara på ett intrång genom att ta ett kritiskt system offline utan att förstå om det orsakar ett värre fysiskt utfall än själva intrånget. Varje säkerhetsbeslut måste ta hänsyn till den operativa verkligheten i det system det skyddar.

Det innebär inte att OT-system inte kan säkras. Det innebär att säkerhet måste designas in i arkitekturen snarare än monteras på endpoint-nivå i efterhand. Nätverkssegmentering, enkelriktade gateways, passiv övervakning och åtkomstkontroll vid perimetern uppnår säkerhetsmål utan att behöva röra enheterna själva. Den ingenjörsmässiga utmaningen är att förstå systemet tillräckligt väl för att designa kontroller som skyddar utan att störa.

Varför äldre system är det svåraste problemet

OT-miljöer är byggda för att fungera i decennier. En PLC installerad i ett vattenreningsverk 2002 kan fortfarande vara i produktion idag, med firmware som inte uppdaterats sedan installation. Leverantören kanske inte längre finns. Ingenjörsteamet som designade systemet kanske har gått i pension. Dokumentationen kanske är ofullständig. Och organisationen kan helt enkelt inte byta ut utrustningen eftersom det skulle kräva en fullständig anläggningsstängning och ett omingenjörsprojekt som kostar miljoner.

Denna livslängd skapar en säkerhetsutmaning utan någon ren lösning. Systemet kör ett operativsystem med kända, offentligt dokumenterade sårbarheter. Det talar protokoll utan autentisering. Det designades i en era då nätverksanslutning inte var en del av hotmodellen. Och ändå kan det inte patchas, kan inte ersättas och måste fortsätta fungera tillförlitligt.

Det praktiska svaret är att fokusera säkerheten på nätverks- och åtkomstnivå snarare än enhetsnivå. Om en sårbar PLC bara kan nås av behöriga ingenjörsarbetsstationer på ett segregerat nätverk, blir dess interna sårbarheter mycket svårare att utnyttja. Detta tillvägagångssätt, kompenserande kontroller runt icke-patchbara tillgångar, är det dominerande mönstret i mogna OT-säkerhetsprogram och adresseras explicit i standarder som IEC 62443.

IT/OT-konvergensproblemet

Moderna OT-miljöer är inte helt isolerade. Affärstryck har drivit integration av OT och IT av legitima skäl: insamling av produktionsdata för analys, möjliggörande av leverantörers fjärrsupport, integration med ERP-system och tillhandahållande av ledningsdashboardar. Varje integration är motiverad individuellt, men sammantaget skapar de en nätverkstopologi där separationen mellan företags-IT och operativa system är mindre tydlig än den verkar på papper.

Den typiska riskvägen är indirekt. En angripare komprometterar en företagsslutpunkt via ett nätfiskemail. Därifrån pivoterar de till system som har åtkomst till OT-miljön: historiseringsservrar som aggregerar produktionsdata, ingenjörsarbetsstationer med fjärråtkomstprogramvara eller leverantörers VPN-anslutningar med bred nätverksåtkomst. Inget av dessa system är det faktiska målet, men var och en är ett språngbräde mot kontrolllagret.

Att adressera detta kräver förståelse för faktisk anslutning, inte antagen anslutning. Organisationer upptäcker ofta att deras OT-nätverk är mer anslutet än dokumenterat, via underhållsdatorer som ansluter till båda nätverken, via trådlösa accesspunkter installerade för bekvämlighet eller via industriella routrar med standardkonfigurationer. Korrekt tillgångsinventering och nätverkskartläggning är startpunkten för varje seriöst OT-säkerhetsprogram.

Vem som attackerar OT och varför

Hotlandskapet för OT skiljer sig markant från IT. Ransomware-operatörer har upptäckt att kryptering av IT-system som är angränsande till OT-miljöer ofta räcker för att orsaka driftsstopp, även utan att direkt röra styrsystem. Colonial Pipeline-incidenten 2021 visade detta tydligt. Operatörerna stängde av rörledningen förebyggande eftersom de inte kunde bekräfta att deras OT-system var opåverkade.

Nationalstatliga aktörer representerar den mer sofistikerade änden av hotspektrumet. Grupper har visat förmågan att kompromissa OT-miljöer, förstå industriella protokoll och positionera sig för att orsaka fysiska effekter. Attackerna mot ukrainsk elnätsinfrastruktur 2015 och 2016 visade att dessa förmågor inte är teoretiska. De har använts för att orsaka verkliga strömavbrott som drabbade hundratusentals människor.

Implikationen för försvarare är att hotmodellen måste inkludera aktörer med tålamod, resurser och specifika fysiska mål. Långa uppehållstider, att leva av legitimt befintliga verktyg och noggrann rekognosering innan handling är kännetecken för avancerade kampanjer som riktar in sig på OT. Detektionsstrategier måste ta hänsyn till subtila avvikelser i processbeteende och nätverkskommunikationsmönster, inte bara uppenbara skadeprogramssignaturer.