Industrielle nettverk kalles ofte Operational Technology (OT)-nettverk, fordi de kontrollerer og overvåker fysiske maskiner, prosesser og sikkerheten tilknyttet disse. På en oljeplattform binder OT-nettverk sammen brann- og gassdeteksjonssystemer, nødstrømsforsyning, brannvannspumper og kontroll av olje- og gass-prosesseringen. Disse nettverkene er meget kritiske og er underlagt streng sikkerhet. Hvis det oppstår avvik kan det være livstruende.
OT-nettverk finnes i produksjonsindustrien, forsyningsbransjen og innenfor infrastruktur som tunneler og veier. Disse nettverkene har noe til felles. De er svært tett på kjernevirksomheten og på det en bedrift gjør for å skape verdi. Mange av de datanettverk som går under paraplyen «Norsk kritisk infrastruktur» består også av et OT-nettverk.
I ethvert større industriprosjekt, som for eksempel offshore-installasjoner, leier operatørene inn entreprenører til å håndtere det som kalles Engineering and Procurement (EP). I dette inngår design av installasjonen samt innkjøp av nødvendige systemer. Innkjøpene er delt opp i innkjøpspakker, og etter en anbudsrunde velges en leverandør til hver pakke. Et komplekst prosjekt kan ha opptil 60 eller 70 pakker som er sårbare for cybertrusler, og nærmere halvparten av disse leverer små industrielle nettverk som inkluderer svitsjer, brannmurer, kritiske kontrollenheter og servere, der alle er tilknyttet og drives fra et sentralt kontrollrom.
Utfordringen med arbeidsdeling
I prosjekter er det nær sagt aldri de samme menneskene som designer, dokumenterer og installerer disse installasjonene som de som opererer dem. Er designeren alltid bevisst på operatørens behov for en sikker driftsfase? Og omvendt, har operatøren forståelsen for helheten i designet av nettverket & kontrollsystemet? Hver del av systemet vil oppføre seg ulikt, da leverandørene har sine egne design og er kun ansvarlig for sikkerheten i sin egen løsning. Hvem sørger for at driftspersonalet fra første dag i produksjonen får verktøy som gir innsikt på tvers av nettverksinfrastrukturen og leverandørsystemene, slik at de kan reagere på avvik?
Så hva kan vi gjøre? Start med å inkludere de som skal drifte systemene i designprosessen og la deres stemme bli hørt i forbindelse med spesifikasjon av systemkrav. Erfaringen fra tidligere prosjekter er at operatørenes egne driftsorganisasjoner har verdifull input til entreprenørens design. Det mest egnede designet kan variere betydelig for ulike systemer basert på hvem som er ansvarlig for systemet, hvordan de er organisert og hvordan systemet driftes og vedlikeholdes. Erfaring har vist at hvis du gjør det mulig for entreprenøren å interagere med operatørenes driftsorganisasjon, kan det raskt høstes frukter i form av bedre tilpasset design og cybersikkerhet for kritiske komponenter.
I tillegg må entreprenøren være klar til å ta et større ansvar for å være en sann integrator for kritiske OT-nettverk og datasikkerhet. Den tradisjonelle ansvarsfordelingen mellom leverandører i prosjekter gir ikke nødvendigvis mening, særlig ikke for kritiske kontrollnettverk hvor mange leverandører blir knyttet til OT-nettverkene med nettverksutstyr, kontrollenheter og servere. Det er behov for en ny tilnærming for å sikre konsistente topologier, motstandsdyktighet og ende-til-ende overvåkning, samt innsikt i nettverkene mellom kontrollsystemene og det fysiske utstyret. Kontraktørene må være forberedt på å definere nye arbeidsfordelinger mellom leverandørene. Erfaring fra et stort, pågående offshore prosjekt har gitt en design med drastisk forbedring i robusthet, datasikkerhet og innsikt i kritiske OT-nettverk når disse endringene implementeres.
Utfordringer med etterlevelse
Etterlevelse (compliance) til datasikkerhet innebærer en lang rekke krav, men kun få av disse er relevante for det enkelte system. Operatører bruker internasjonale standarder som IEC62443 og NIST-CSF, men dette gjør ikke datasikkerhet lettere å håndtere for leverandørene. Brede rammer med vage formuleringer som imøtekommer alle brukersituasjoner gjør det vanskelig å avgjøre hva som er nødvendig for et EP-prosjekt. Og for en gitt leverandør med et lite, men kritisk system, er det bruk for kanskje kun 5 % av rammeverket. Hvilke 5 % bestemmes av mange faktorer. Med unntak av de større kontrollsystem-leverandørene er et fåtall av leverandørene kompetente innen datasikkerhet og nettverk. Dette er ikke deres kjernevirksomhet, og de komponentene de leverer som er sårbare for angrep konfigureres ofte av underleverandører som vet enda mindre om hva som er nødvendig for EP-prosjektet.
Her ligger det en utfordring; operatører, entreprenører og leverandører bruker mye tid på å tolke og diskutere hva som er godt nok for et gitt system. Hvilke krav skal implementeres og hvilke skal utelates? Og vage formuleringer som «skal være ordentlig sikret» eller «konfigurert på en robust måte» forsterker problemet. Hvem bestemmer hva som er «ordentlig sikret» og hva som er en «robust måte»? Når du har mange leverandører med forskjellige meninger (eller ingen i det hele tatt), ender du ofte med en lavere kvalitet enn hva du håpet på.
Så hva kan du gjøre? Vi oppfordrer operatører og entreprenører til å være veldig spesifikke på hva leverandørene skal konfigurere og ikke. Vage formuleringer må erstattes med konkrete, tekniske beskrivelser av hvordan man konfigurerer en bestemt tilkobling eller funksjonalitet. Mange teknologier brukes over flere år (til og med tiår), og slike tekniske beskrivelser blir ikke foreldet så raskt som man skulle tro – selv med et skiftende trusselbilde. Mens noen leverandører (typisk de som leverer store kontrollsystemer) er modne og kan håndtere kravene til etterlevelse, har de fleste andre leverandører behov for hjelp til å oppnå et tilstrekkelig sikkerhetsnivå for de mest kritiske komponentene.
I tillegg finnes det muligheter for å sentralisere sikring av ofte anvendte komponenter, som for eksempel servere og arbeidsstasjoner. Kontraktørene kan peke ut én ekspert leverandør, som kan levere herdede, sikre datamaskiner og operativsystemer og dermed løfter denne byrden bort fra leverandørene. En kan også få ansvar for enkelte OT-nettverk i prosjektet.
Vi foreslår to metoder å følge når man bruker en ekspert-leverandør. Det handler om:
- En egen nett- og sikkerhetsleverandør til infrastrukturen, som også har ansvaret i driftsfasen. Denne leverandøren vil være ansvarlig for utformingen av en sikker OT-infrastruktur som binder sammen leverandørsystemene og gir synlighet til driftsorganisasjonen fra dag 1.
- Hovedleverandøren av kontrollsystemet gis et større ansvar for å muliggjøre en ende-til-ende sikker infrastruktur hvor driftsorganisasjon får systemer som gir innsikt til trafikkflyt. I olje- og gass-sektoren kan dette være SAS-leverandøren (Safety & Automation System). Denne leverandøren er ofte kompetent innenfor industrielle OT-nettverk, og er også ofte involvert i driftsfasen.
Dette endrer ikke det faktum at operatøren og kontraktøren fastsetter strenge krav til hvordan nettverket skal betjenes sikkert. Forskjellen består i at implementeringen skjer i samarbeid med en enkelt leverandør istedenfor 30. Dette krever på den ene siden mer koordinering fra entreprenøren, men på den andre siden langt mindre tidsbruk på hver enkelt leverandør. Sluttresultatet for operatøren er en betydelig bedre datasikkerhetsrigg.
Elektrifiseringen i Oslo har ikke gått for raskt
Kritisk infrastruktur – vårt felles ansvar
Mye kritisk infrastruktur er bygget som en del av komplekse prosjekter. Datasikkerhet er på dagsorden, men er vanskelig å gjennomføre på grunn av de utfordringene vi har skissert her. Vår anbefaling er å bryte ned kompleksiteten. I alle industriprosjekter MÅ man vite hvilke kapabiliteter det er behov for når prosjektet er over, og driftsfasen begynner. Nøkkelen er å gi drift synlighet, samt nye arbeidsfordelinger definert av kontraktøren. Du kan ikke sikre det du ikke kan se. Hvis kontrollrommet er hjertet i dine kritiske prosjekter, er OT-nettverket blodårene. La oss sørge for at vi bygger dem opp til å være robuste og sikre. Vår felles kritiske infrastruktur er avhengig av det.
Russiske tap i Svartehavet: – Ingen konsekvenser
