Det internasjonale energibyrået advarte sin rapport i november 2023 at det gjennomsnittlige antallet av cyberangrep mot nettselskaper i verden mer enn doblet seg mellom 2020 og 2022. Rapporten pekte hovedsakelig på strømnett som i høyere grad er under digitalisering. På grunn av den geopolitiske situasjonen er man i større grad nødt til å beskytte strømnettet mot uønskede avbrudd, forårsaket av cyberangrep. I dette innlegget ser vi nærmere på hvordan vi i SINTEF Digital har utviklet en referansearkitektur for norske driftssentraler.
Hvorfor trenger vi en sikkerhetsarkitektur?
Integrasjon mot IT har ført til at vi har blitt mer sårbare for angrep utenifra. Vi digitaliserer i større grad strømnettet for optimal bruk om ved å bruke sensorer på lav- og høyspentnettet, samt trafostasjoner for å måle temperatur, frekvens og last på linja i sanntid. Denne dataen vil samles for å gi effektiv drift av strømnettet, som man får tilgang til igjennom driftssentralen. Det blir trolig også utbredt bruk av sky i driftssentralen for bedre tilgjengelighet og brukbarhet av informasjon. Eksempelvis er AMS-infrastrukturen allerede tilgjengeliggjort som en tredjepartskyløsning i IT delen av driftssentralen.
Advanced DMS har også blitt introdusert i driftssentralen til å kombinere flere enkeltstående systemer, som predikering av fleksibilitetsbehov og aktivering av fleksibiliteten, samt endring av endringer i nettkonfigurasjon (koblingsforslag) kan testes ut, eksempelvis ved avbruddshåndtering. Disse systemene vil være tett integrert mot SCADA-systemet hvor man utfører bryterendringene. Tett integrasjon mellom DMS og SCADA kan føre til uønsket tilgang og misbruk av sårbarheter, som krever mer fra nettoperatører for å sikre pålitelig nettdrift. Denne utviklingen gjør at driftssentralen blir mer påkoblet nettet utenifra, som synliggjør angrepsvektorer inn til “hjertet” av strømnettet. Dette fordrer bedre design og sikkerhetsstiltak som kan hindre uønsket tilgang av kritiske funksjoner av driften.
Hva er en sikkerhetsarkitektur?
Europeiske standardorganisasjoner definerer det som “en detaljert beskrivelse av alle aspekter i et system som relateres til cybersikkerhet, sammen med en liste av prinsipper til å veilede designet”. Målet er altså å systematisere tekniske sikkerhetselementer til å sikre robustheten til driftssentralens systemfunksjoner, uavhengig av uønskede hendelser.
Hvordan gjorde vi det?
Vi har tatt utgangspunkt i design science for utvikling av sikkerhetsarkitekturen. Vi startet med å gjennomføre et litteratursøk for å undersøke feltet og fremtidige systemer for nettoperatører, før vi gjennomgikk flere runder med å systematisere hvilke angrep- og tiltaksstrategier som var mest relevant for oss fra MITRE ATT&CK-rammeverket. Utifra visse inkluderings- og ekskluderingskrav kom vi frem til 47 høy og medium relevante strategier med 198 tilsvarende tiltaksstrategier.
Samtidig som vi utførte denne utvalgsprosessen hadde vi diskusjoner med andre smartgrid forskere, leverandører, nettoperatører og en representatnt fra Statnett. Videre hadde vi workshop med et nettselskap for å gå igjennom funnene våre så langt. Resultatet vi presenterer i dag er en vanlig arkitektur av driftssentralen, og deres tilkoblinger, samt en fremtidig sikkerhetsarkitektur av driftssentralen.
Figuren viser et oversiktsbilde av dagens arkitektur med hovedfokus på driftssentralen. Den svarte boksen blir omtalt som System Under Consideration (SuC) og er grunnlaget for trusselanalysen vår. I den sorte boksen er IT-delen og OT delen, definert som Enterprise og Operations inkludert, sammen med Demiliarized zone, hvor all informasjonsutveksling mellom IT og OT foregår.
Antakelser
Som nevnt ligger hovedfokuset på systemer direkte tilkoblet driftssentralen. Vi har også valgt å forenkle kommunikasjonen mellom smartmålere og AMI HES, fordi de ikke er en del av scope. Det samme gjelder feltenheter og microgrids. Antallet data historians er forenklet, men disse blir brukt til å lagre relevant data for kritiske systemer. Digitale tvillinger er også potensielt noe flere nettoperatører vil bruke i fremtiden, men vi antar at verktøyet vil ha samme plassering som ADMS og er derfor ekskludert i vår arkitektur. Nettverks Intrusion Prevention System og Instrusion Detection System vil trolig også eksistere for fremtidige, industrielle nettverk og er derfor inkludert.
Neste figur viser hvordan sonefordelingen ble gjort i henhold til IEC 62443. For å forklare det kort representerer soner en samling av systemer i SuC som har samme sikkerhetskrav, mens kanaler beskytter kommunikasjonen mellom soner. Kravene som blant annet har blitt tatt utgangspunkt i er å separere IT og OT systemer, SIS og fjernstyring bør stå separat, og trådløs kommunikasjon bør skilles fra kablet kommunikasjon. Siden alle systemene ikke nødvendigvis er implementert ennå, har vi kun tatt utgangspunkt i dataflyten mellom sonene, dvs. Informasjonen som (trolig) vil sendes imellom og ut av sonene.
Dette er den endelige sikkerhetsarkitekturen med alle sonene implementert med hver sin sikkerhetssone. Ikke alle kanalene er definert for å ikke komplisere figuren. Basert på tiltakene fra MITRE ATT&CK har vi valgt å implementere nettverkssegmentering, og redundans. Videre har driftssentralen sin egen Identity and Access Management (IAM) infrastruktur, som er adskilt IT-delen. Mange av tiltakene krever også riktig konfigurasjon av nettverkselementer, som fjerne tilgang til enkelte porter, fjerne enkelte applikasjonslagsprotokoller, opplæring av personell, programvare eller enhetsautentisering. Dette viser at selv om man lager en god sikkerhetsarkitektur, så vil ikke det alene kunne sikre driftssentralen mot uønskede hendelser.
Implikasjoner av sikkerhetsarkitekturen
- Realistisk sikkerhetsnivå av systemene. Vi har spesifikt valgt å sette lavere sikkerhetsnivå (dvs. 2 og 3) pga økonomi og manglende sikkerhetsekspertise. Et sikkerhetsnivå 4 krever beskyttelse fra avanserte nasjonalstater og grundig overvåkning av alle lag i arkitekturen.
- Ansvarsfordeling av skyløsninger. For eksempel vil en skybasert HES må data bli eksportert til driftssentralen, noe som gir en vei inn i mer privilegerte systemer. Dette kan føre til mer skade hvis de blir misbrukt. Hvem sitt ansvar er det å gjennomføre vedlikehold og patching av slike tjenester – er det skyleverandøren eller DSOen?
- Tilgangen til leverandører av sensorer og IoT enheter. For å få tilgang kan de forvente at denne skal gå igjennom driftssentralen. En slik tilgang kan misbrukes av leverandøren og hindre forsyningssikkerheten. For å forhindre direkte tilgang, kan man ha en proxy server imellom komponentene og systemene. Selv om dette kanskje går på bekostning av tjenesten, er det potensielt mer sikkert for nettselskapene.
Veien videre
Utviklingen av en sikkerhetsarkitektur for norske driftssentraler er ikke bare et teknisk prosjekt – det er et strategisk grep for å sikre samfunnskritisk infrastruktur i en tid med økende digitalisering og trusselbilde. Selv med en robust arkitektur, vil kontinuerlig oppdatering, kompetanseheving og samarbeid mellom aktører være avgjørende for å møte fremtidens utfordringer. Vi håper at arbeidet vårt kan bidra til å styrke bevisstheten og inspirere til videre utvikling av sikre og pålitelige løsninger for norske DSOer.
Forskningen bak artikkelen er utført i FME CINELDI (prosjektnr. 257626), og ble presentert på Norsk informasjonssikkerhetskonferanse (NISK) i Bergen i fjor: https://www.ntnu.no/ojs/index.php/nikt/article/view/6240
Photo by Ibrahim Boran: https://www.pexels.com/photo/close-up-photo-of-control-panel-3582392/