Produksjonsanlegg, energianlegg og logistikknutepunkter er under økende press for å koble driftsteknologi (OT) til bedriftens IT-nettverk. Forretningssaken er klar: sanntidsdata fra butikkgulvet gir bedre beslutninger, raskere vedlikeholdssykluser og slankere drift. Sikkerhetsrisikoen er imidlertid like reell og ofte undervurdert.
I motsetning til IT-miljøer, ble OT-nettverk designet for tilgjengelighet og determinisme, ikke konfidensialitet. Å patche en PLS midtskift er ikke det samme som å oppdatere en bærbar datamaskin. Nedetid måles i tonn, ikke helpdesk-billetter. Disse begrensningene gjør OT-miljøer strukturelt vanskeligere å sikre, og de forklarer hvorfor trusselaktører i økende grad retter seg mot dem.
De følgende fem feilene dukker opp gjentatte ganger i industrielle miljøer som har vært utsatt for brudd eller nestenulykker. Å unngå dem krever ikke å erstatte alle eiendeler på gulvet. Det krever bevisste arkitekturvalg på det punktet der OT-data først krysser inn i IT-domenet.
-
Kjører industrielle protokoller uten kryptering eller autentisering
Modbus, DNP3 og eldre varianter av OPC DA ble designet i en tid da luftgaping var den antatte sikkerhetsmodellen. De har ingen innebygd autentisering og overfører data i ren tekst. Når et nettverk er koblet til bedriftens infrastruktur eller skyen, selv indirekte, blir disse egenskapene forpliktelser.
Skiftet til OPC UA som et transportlag løser begge problemene. OPC UA støtter sertifikatbasert autentisering og TLS-krypterte sesjoner på protokollnivå, uten å kreve løsninger på applikasjonslag. Miljøer som fortsetter å bruke eldre protokoller på tilkoblede segmenter uten kompenserende kontroller, aksepterer en risiko som er både godt dokumentert og unngåelig.
Industrielle tilkoblingsplattformer spiller en kritisk rolle her. En riktig konfigurert tilkoblingsserver sitter mellom feltenheter og IT-nettverket, og oversetter eldre protokoller til autentiserte, krypterte økter før data forlater OT-sonen. Å velge og herde det laget er en av de sikkerhetsbeslutningene en OT-ingeniør kan ta med størst innflytelse. Kepware er blant de mest utbredte plattformene i denne rollen, og konfigurasjonen, spesielt rundt OPC UA-sikkerhetspolicyer og brukerautentisering, fortjener samme gransking som enhver nettverksenhet.
-
Flate nettverk uten segmentering mellom OT-soner
Et flatt OT-nettverk betyr at enhver enhet som kan kommunisere med én ressurs, i prinsippet kan kommunisere med dem alle. Dette er arkitekturen som tillot Oldsmar-vannbehandlingshendelsen i 2021 å fortsette så langt som den gjorde: en angriper med tilgang til én arbeidsstasjon hadde uhindret rekkevidde til SCADA-grensesnittet som kontrollerte kjemisk dosering.
IEC 62443-standarden og Purdue-modellen anbefaler begge å segmentere OT-nettverk i soner basert på kritikalitet og funksjon, med kanaler som kontrollerer trafikken mellom dem. I praksis betyr dette brannmurer eller industrielle DMZ-er som skiller nivå 1 (feltenheter) fra nivå 2 (tilsynskontroll) og nivå 3 (driftsstyring), med eksplisitt hviteliste over tillatte kommunikasjonsveier.
Segmentering er ikke et engangsprosjekt. Etter hvert som nye dataflyter legges til, enten det er historikerreplikering, skytelemetri eller fjerntilgang for leverandører, representerer hver enkelt en ny kanal som må vurderes og kontrolleres.
-
Leverandørens fjerntilgang er permanent åpen
Mange industrielle installasjoner ble satt i drift med alltid-på fjerntilgang konfigurert for OEM eller systemintegrator. VNC-porter som ble eksponert, RDP aktivert på tekniske arbeidsstasjoner, eller hoppservere med delt legitimasjon som aldri ble rotert etter overlevering.
Dette er en av de vanligste initialtilgangsvektorene i OT-hendelser. Angripere trenger ikke å kompromittere anleggsnettverket direkte hvis en vedlikeholdsvei er evig åpen på en offentlig rutebar adresse.
Korrigeringsmønsteret er godt etablert: Erstatt permanent tilkobling med øktinitiert, tidsbegrenset tilgang. Løsninger basert på krypterte tunneler som er meglerformidlet og krever eksplisitt godkjenning for hver økt eliminerer den vedvarende eksponeringen samtidig som leverandørstøtteevnen bevares. Multifaktorautentisering på hver fjerntilgangsvei til OT-systemer er ikke omsettelig.
-
Ingen aktivabeholdning, så ingen grunnlinje for oppdagelse av anomalier
Du kan ikke oppdage unormal oppførsel på et nettverk du ikke har regnet opp. Mange OT-miljøer mangler en nåværende, komplett beholdning av tilkoblede eiendeler, dels fordi enheter legges til trinnvis over år, dels fordi eldre kontrollere ikke reagerer på standard oppdagelsesonder, og dels fordi oppgaven oppfattes som en engangsøvelse snarere enn en kontinuerlig prosess.
Uten en grunnlinje har inntrengningsdeteksjonssystemer ikke noe referansepunkt. Trafikk som ser uvanlig ut for en menneskelig analytiker ser ikke ut til å skilles fra normal drift til et verktøy som aldri har sett normal drift.
Passive nettverksovervåkingsverktøy designet for OT, de som observerer trafikk uten å generere spørringer som kan forstyrre sensitive kontrollere, kan bygge aktivabeholdninger automatisk. Plattformer som Claroty, Nozomi Networks og Dragos er designet nettopp for dette. Resultatet er både et sikkerhetselement og et samsvarselement: NIS2 krever at organisasjoner klassifisert som essensielle eller viktige enheter opprettholder dokumenterte risikovurderinger av sine OT-miljøer. Hvis du er usikker på om organisasjonen din faller innenfor scope, gir NIS2 OT Security Check et strukturert utgangspunkt for å vurdere din klassifisering og beredskap.
-
Å behandle OT-sikkerhet som et IT-ansvar alene
Den mest vedvarende strukturelle feilen er organisatorisk snarere enn teknisk. IT-sikkerhetsteam forstår brannmurer, endepunktdeteksjon og identitetsadministrasjon. De forstår vanligvis ikke de operasjonelle begrensningene til en DCS, implikasjonene av en vakthund-timeout på et sikkerhetsinstrumentert system, eller hvorfor en patch som er triviell å distribuere på en Windows-server kan være utestbar på en kontroller som kjører en 15 år gammel fastvareversjon.
Når OT-sikkerhet er delegert i sin helhet til IT-sikkerhetsfunksjonen, er resultatet enten upassende kontroller som skaper tilgjengelighetsrisiko på gulvet, eller en dødgang der ingenting implementeres fordi IT-teamet mangler autoritet til å handle uten OT-sign-off og OT-teamet mangler mandat til å handle i det hele tatt.
Effektiv OT-sikkerhet krever en felles modell: IT-sikkerhet bringer trusselintelligens, verktøy og styringsrammeverk; OT engineering bringer prosesskunnskap, sikkerhetsbegrensninger og myndighet til å implementere endringer på gulvet. Programmet trenger en navngitt eier som sitter i skjæringspunktet mellom begge funksjonene, og utøvende sponsing som behandler OT-sikkerhet som et forretningskontinuitetsproblem, ikke et teknologiprosjekt.
Hvor du skal begynne
Organisasjoner uten et formelt OT-sikkerhetsprogram trenger sjelden å ta opp alle fem områdene samtidig. Et pragmatisk utgangspunkt er en nettverksarkitekturgjennomgang: kartlegg hva som er tilkoblet, identifiser hvor OT-trafikk krysser inn i IT- eller skyinfrastruktur, og vurder sikkerhetsposisjonen til disse kryssingspunktene.
Tilkoblingslaget, serverne og gatewayene som samler data fra feltenheter og eksponerer det nordgående, er nesten alltid det høyest prioriterte funnet. Å låse ned dette laget, håndheve autentiserte og krypterte protokoller, og sikre at det er passende segmentert fra både feltnettverket og IT-nettverket adresserer den største andelen av realistiske angrepsoverflater i de fleste industrielle miljøer.
De resterende elementene, leverandørtilgangskontroller, aktivabeholdning, avviksdeteksjon og styringsstruktur, kan sekvenseres over et program på seks til tolv måneder uten å kreve produksjonsstans eller kapitalutgifter på ny kontrollmaskinvare.
