OT Säkerhet

IT vs OT

Hur informationsteknologi och operativ teknologi skiljer sig i syfte, designfilosofi och hotmodell, och vad dessa skillnader betyder för säkerhetsarbetet.

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

Vad det är

IT avser system som används för att bearbeta, lagra och kommunicera data: servrar, arbetsstationer, molninfrastruktur, företagsapplikationer och de nätverk som förbinder dem. OT avser system som används för att övervaka och styra fysiska processer: PLC:er, RTU:er, SCADA-system, distribuerade styrsystem och de industriella nätverk de körs på. Båda kategorierna involverar datorer och nätverk, men de designades med olika mål, olika begränsningar och mycket olika definitioner av vad ett misslyckande innebär.

Nyckelpunkter
  • IT-system prioriterar konfidentialitet och integritet. OT-system prioriterar tillgänglighet och fysisk säkerhet framför allt annat.
  • IT opererar på uppdateringscykler som mäts i år. OT-utrustning körs i decennier, ofta utan uppdateringar eller leverantörsstöd.
  • IT-säkerhetsverktyg och metoder byggdes för en annan miljö och kan orsaka allvarlig skada när de tillämpas på OT utan anpassning.
  • Konvergensen mellan IT och OT-nätverk växer, vilket för över IT-världens risker till miljöer som aldrig designades för att hantera dem.

Hur det fungerar i stora drag

  1. Innan du rör en OT-miljö, förstå vad den fysiska processen är och vad ett oplanerat avbrott skulle innebära i operativa och säkerhetsmässiga termer.
  2. Kartlägg vilka system som är IT och vilka som är OT, med fokus på var de två miljöerna ansluter, eftersom dessa anslutningspunkter är där risk överförs mellan världarna.
  3. Undvik att tillämpa IT-säkerhetsverktyg direkt på OT utan leverantörsbekräftelse och testning i en icke-produktionsmiljö först.
  4. Inse att ändringshantering i OT är mycket mer konservativ än i IT. Uppdateringar, omkonfigurationer och åtgärder följer planerade underhållsfönster och kräver tvärfunktionellt godkännande.
  5. Bygg separata övervakningsstrategier för OT som förlitar sig på passiv observation snarare än aktiv kommunikation med enheter.

Konkret exempel

Ett säkerhetsteam som ansvarar för både IT och OT på ett tillverkningsföretag beslutar att rulla ut endpoint-detektionsprogramvara i hela miljön. I IT går detta smidigt. När samma agent driftsätts på ett äldre Windows-baserat HMI i produktionsanläggningen orsakar den extra CPU-belastningen att gränssnittet blir oanvändbart, vilket utlöser ett oplanerat linjesstopp. Skillnaden var inte verktyget. Det var miljön verktyget driftsattes i.

Varför det är viktigt

Säkerhetsteam utbildade i IT stöter ofta på OT-miljöer och tillämpar välbekanta verktyg och tankesätt utan att inse hur annorlunda kontexten är. Att köra en portskanning mot en företagsserver är rutin. Att köra samma skanning mot en PLC på ett fabriksgolv kan krascha den. Att starta om en server för en patch är normal IT-praxis. Att starta om en styrenhet som hanterar en kemisk process är en operativ händelse som kräver noggrann planering och koordination. Dessa skillnader är inte undantag. De är regeln i OT, och att ignorera dem skapar risk snarare än att minska den.

Säkerhetsperspektiv

  • Rätt säkerhetskontroller för OT är ofta arkitekturbaserade snarare än endpoint-baserade: segmentering, åtkomstkontroll vid gränsen och enkelriktade dataflöden snarare än agenter och skannrar på enheterna själva.
  • Incidenthantering i OT måste ta hänsyn till den fysiska processen. Att isolera ett komprometterat system kan behöva vänta tills processen når ett säkert tillstånd, vilket är en begränsning som helt enkelt inte finns i IT.
  • Synlighet är den första prioriteten i de flesta OT-miljöer. Du kan inte försvara det du inte kan se, och de flesta OT-nätverk har mycket lite övervakning på plats.

Vanliga fallgropar

  • Att anta att ett verktyg eller en praxis som är säker i IT är säker i OT. Miljöerna är tillräckligt olika för att detta antagande aldrig bör vara startpunkten.
  • Att underskatta hur lång tid förändringar tar i OT. En säkerhetsförbättring som skulle ta dagar att driftsätta i IT kan ta månader i OT på grund av operativa fönster, leverantörsberoenden och säkerhetsgranskningar.
  • Att ignorera människodimensionen. OT-miljöer drivs ofta av ingenjörer och tekniker vars primära kompetens är den fysiska processen, inte cybersäkerhet, vilket påverkar hur säkerhetsprogram måste designas och kommuniceras.

FÖRDJUPNING

▾

Olika syften, olika designprioriteringar

IT-system finns till för att flytta och bearbeta information. Deras designprioriteringar återspeglar detta: tillförlitlighet är viktigt, men det är också flexibilitet, snabb iteration och förmågan att uppdatera och ersätta komponenter. När ett IT-system fallerar är konsekvensen vanligtvis operationell störning. Användare kan inte komma åt en tjänst, data är otillgänglig, en affärsprocess stannar. Dessa är allvarliga utfall, men de är återställningsbara och involverar normalt inte fysisk skada.

OT-system finns till för att styra fysiska processer i realtid. Deras designprioriteringar är tillgänglighet och determinism. En PLC som styr en motor måste svara på sina insignaler inom ett fast tidsfönster, varje gång, utan undantag. Ett SCADA-system som hanterar ett vattenreningsverk måste förbli operativt kontinuerligt eftersom alternativet inte är en olägenhet utan en folkhälsorisk. Det är därför tillgänglighet sitter högst upp i OT:s prioritetsstack på ett sätt som helt enkelt inte gäller för de flesta IT-miljöer.

Dessa olika prioriteringar producerar olika ingenjörskulturer. IT-team är vana vid att patcha ofta, driftsätta uppdateringar regelbundet och acceptera viss driftstid för underhåll. OT-team är vana vid att planera varje förändring noggrant, testa i parallella miljöer och behandla oplanerade driftstopp som allvarliga operativa misslyckanden. Ingen kultur är fel. De återspeglar de faktiska kraven på vad varje miljö är byggd för att göra.

Livslängder och patchningsproblemet

I IT kan en server ersättas vart tredje till femte år. Programvara uppdateras på månads- eller till och med veckobasis. Säkerhetspatchar tillämpas som en rutinmässig operativ uppgift. Antagandet inbyggt i de flesta IT-säkerhetsramverk är att tillgångar kan uppdateras när sårbarheter upptäcks och att uppdateringsprocessen är normal och förväntad.

I OT faller detta antagande nästan omedelbart samman. Industriell utrustning är dyr, djupt integrerad i fysisk infrastruktur och validerad som ett komplett system. En PLC som styr en turbin är inte bara en dator som kör programvara. Det är en certifierad komponent i ett säkerhetssystem. Att ersätta eller uppdatera den kräver omvalidering av hela systemet, vilket kan ta månader och betydande kostnader. Leverantörer kanske inte alls släpper patchar för äldre produkter. Vissa system kör operativsystem som har saknat leverantörsstöd i ett decennium.

Detta innebär att frågan i OT sällan är hur snabbt kan vi patcha den här sårbarheten utan snarare hur opererar vi säkert med den här sårbarheten närvarande under överskådlig framtid. Svaret är nästan alltid kompenserande kontroller på nätverks- och åtkomstnivå, att minska exponeringen av den sårbara enheten snarare än att fixa enheten själv. Detta är en fundamentalt annorlunda säkerhetsposition än IT, och att förstå det är avgörande för att göra realistiska säkerhetsplaner i industriella miljöer.

Protokoll byggda för tillförlitlighet, inte säkerhet

Protokollen som används i OT-miljöer designades i en era då industriella nätverk var fysiskt isolerade och säkerhet inte var en designfaktor. Modbus, utvecklat 1979, har ingen autentisering och ingen kryptering. DNP3, som används brett i kraft- och vatteninfrastruktur, designades för tillförlitlig kommunikation över bullriga serielänkar, inte för säkerhet i en nätverksmiljö. Många proprietära leverantörsprotokoll delar samma egenskaper.

Dessa protokoll antar att alla enheter på nätverket är auktoriserade att kommunicera. Det finns inget begrepp för identitetsverifiering innan ett kommando accepteras. En Modbus-master kan skicka ett skrivkommando till en PLC och PLC:n kommer att utföra det utan att fråga vem som skickade det eller om kommandot är legitimt. Denna design är inte ett misstag. Det var rätt ingenjörsmässigt val för isolerade industriella nätverk 1979. Det blir ett allvarligt problem när samma protokoll nu är nåbara från företagsnätverk eller internet.

Konsekvensen för säkerhet är att du inte kan fixa protokollet. Du kan bara kontrollera vem som har åtkomst till det nätverkssegment där dessa protokoll opererar. Nätverkssegmentering, åtkomstkontrollistor och industriella brandväggar som förstår OT-protokoll blir de primära säkerhetskontrollerna, eftersom protokollen själva aldrig kommer att tillhandahålla autentisering eller kryptering i äldre driftsättningar.

Var IT och OT ansluter, och varför det spelar roll

Den traditionella modellen för OT-säkerhet var luftgapet: en fullständig fysisk separation mellan det operativa nätverket och allt annat. I praktiken har verkliga luftgap blivit sällsynta. Organisationer ansluter OT till IT för att samla in produktionsdata för affärsanalys, möjliggöra leverantörers fjärrsupport, integrera med affärssystem och ge ledningen insyn i anläggningsoperationer.

Var och en av dessa anslutningar är affärsmässigt motiverad individuellt. Sammantaget skapar de en väg från IT-världen in i OT-världen. Risken är inte teoretisk. Attackmönstret i verkliga incidenter följer en konsekvent form: kompromissa ett sämre skyddat IT-system, pivota mot system med åtkomst till OT-miljön och därifrån nå kontrolllagret. IT-nätverket blir ingångspunkten och OT-nätverket blir målet.

Säkerhetsutmaningen är att de flesta av dessa anslutningar inte hanteras som säkerhetsgränser. En historiseringsserver som sitter mellan IT och OT, samlar in processdata från kontrolllagret och gör den tillgänglig för företagets rapporteringssystem, är ofta konfigurerad med åtkomst till båda nätverken utan strikta kontroller på vad som kan flöda i endera riktningen. Att identifiera och härda dessa bryggelement är en av de mest effektiva åtgärderna en organisation kan vidta för att minska IT-till-OT-risken.

Att få säkerhet rätt i båda miljöerna

Organisationer som hanterar både IT och OT väl tenderar att behandla dem som separata discipliner som kräver samordning snarare än sammanslagning. De har olika tillgångsinventerier, olika ändringshanteringsprocesser, olika övervakningsstrategier och olika handböcker för incidenthantering. Vad de delar är en förståelse för var miljöerna ansluter och hur risk kan överföras mellan dem.

Säkerhetsstandarder som IEC 62443 tillhandahåller ett ramverk specifikt designat för OT-miljöer, med begrepp som zoner och kanaler som kartlägger den fysiska och operativa verkligheten i industriella nätverk. Dessa standarder är värda att förstå eftersom de erbjuder ett vokabulär och en struktur som är lämplig för OT på ett sätt som IT-centrerade ramverk inte är.

Den mest praktiska startpunkten för varje organisation som opererar i båda miljöerna är en ärlig karta över vad som är anslutet till vad. Många organisationer förvånas av vad de hittar: odokumenterade anslutningar, leverantörers åtkomstvägar som skapades av bekvämlighet och aldrig granskades, och IT-tjänster som når längre in i OT-nätverket än någon insåg. Den kartan är grunden allt annat byggs på.