Klokken 03:17 begynner trykket å stige. Ingen vet hvorfor.

Klokken 03:17 begynner trykket å stige. Ingen vet hvorfor.

Hvorfor det hjelper å lese et angrep baklengs, fra alarmen i kontrollrommet til den første kompromitterte PC-en.

Klokken 03:17 begynner trykket å stige. Ingen vet hvorfor. Operatøren hører alarmen, og ser deretter på trendene. Flere av dem har begynt å bevege seg litt rart. Et eller annet har endret seg i prosessen, men det er ikke åpenbart hva. Er det en instrumentfeil, en ventil som ikke står der den skal, feil i kontrollogikken, eller noe helt annet?

Bak alarmen og trendene: Hvis årsaken er et målrettet cyberangrep, startet historien neppe klokken 03:17. Da ser vi bare den delen av angrepet som til slutt har blitt fysisk.

Denne skjulte delen av isfjellet er noe av det som gjør cyberangrep vanskelige å forstå generelt, og kanskje særlig når angrepet beveger seg dypt ned i industrielle systemer. Her er ICS Cyber Kill Chain nyttig. Modellen gjør det mulig å arbeide seg bakover fra konsekvensen og se på hva en angriper faktisk måtte få til før trykket kunne begynne å stige. Det første angrepet handler om å etablere tilgang, lære systemet og posisjonere seg. Det neste handler om å bruke denne kunnskapen til å utvikle, teste og gjennomføre et angrep mot selve kontrollsystemet eller den industrielle prosessen.

Den stegvise modellen er etter min mening bedre å se på enn en lang liste med angrepsteknikker. En kompromittert PC kan være starten. Å få en bestemt fysisk prosess til å oppføre seg på den måten angriperen ønsker, ligger potensielt mange steg lenger frem.

Veien inn kan begynne langt fra prosessen

Første del av et målrettet OT-angrep kan dreie seg om helt vanlige IT-systemer. En ansatt sin laptop. Selskapet sin nettside eller webserver. Tilgangssystemet til bygget der de ansatte jobber. I denne delen av angrepet trenger angriperen ikke vite noe særlig om den industrielle prosessen. Først må man komme inn, finne ut hvor man har havnet og forstå hvilke muligheter denne tilgangen kan gi videre inn mot industrisystemene til bedriften.

Videre i forløpet gir Purdue-modellen et nytt kart. Den beskriver funksjonelle nivåer fra virksomhetssystemene på Nivå 4 (Level 4), gjennom produksjonsstyring og kontroll, og ned til Nivå 0 (Level 0), der den fysiske prosessen faktisk skjer. Nivå 1 (Level 1) omfatter funksjonene som måler og påvirker prosessen, mens Nivå 2 (Level 2) overvåker og kontrollerer den. Nivå 3 (Level 3) koordinerer produksjonsoperasjonene. Modellen ble opprinnelig utviklet for integrasjon av ulike styringssystemer og -funksjoner for den industrielle produksjonsprosessen til en virksomhet, og den er ikke i seg selv en oppskrift på hvordan et moderne OT-nettverk skal bygges. Den virkelige arkitekturen, med alle forbindelsene og tillitsforholdene, det er den som bestemmer hvilken vei angriperen faktisk kan ta.

Dermed blir også IT/OT-grensen mer konkret, eller kanskje mer uklar og uoversiktlig, enn en strek i et nettverksdiagram. Hvis for eksempel identiteter gjenbrukes på alskens ulike systemer på innsiden, og disse identitetene blir utnyttet eller kompromittert, kan angriperen ha løst flere av utfordringene sine samtidig. Grensen over til OT kan da være langt enklere å komme seg over enn arkitekturtegningen gir inntrykk av. Det samme gjelder eksterne forbindelser, service-PC-er og andre legitime veier inn. Segmentering har verdi når den skaper en reell grense og motstand i angrepet, ikke fordi arkitekturen ser ryddig ut på en tegning.

Å komme inn i OT er ikke det samme som å forstå prosessen

Når angriperen beveger seg videre, skiller ICS Cyber Kill Chain seg tydeligere fra modeller som først og fremst beskriver kompromittering av IT-systemer. Stage 1 kan gi et fotfeste og informasjon om miljøet. For et angrep som skal gi en kontrollert fysisk effekt, gjenstår likevel et vanskelig spørsmål: Hva må endres i den industrielle produksjonsprosessen for å få til det angriperen ønsker?

Anta at angriperen har fått tilgang til et engineering-miljø. Det betyr ikke automatisk at det er åpenbart hvilke signaler som betyr noe, eller hva som skjer dersom en verdi endres. En ventil kan inngå i sekvenser og forriglinger. En pumpe kan være beskyttet av annen logikk, redundante pumper eller mekaniske mekanismer som skal hindre at problemer utvikler seg videre. Kontrollsystemet kan avvise eller overstyre en kommando når andre prosessbetingelser ikke er oppfylt. Og bak kontrollsystemet kan det finnes sikkerhetsfunksjoner og mekaniske barrierer som fortsatt begrenser hva angriperen faktisk kan få til.

Det er denne typen problem Stage 2 i ICS Cyber Kill Chain forsøker å fange. Kunnskap som er samlet inn tidligere brukes til å utvikle og eventuelt teste selve angrepet mot det konkrete industrielle systemet. Forskjellen ligger mellom å ha kompromittert et ICS-miljø og å ha forstått nok til å kunne skape en ønsket fysisk effekt med noenlunde forutsigbarhet.

Stuxnet er det åpenbare eksemplet på hvor langt dette kan gå. Det interessante er mengden kunnskap som lå bak angrepet. Et målrettet angrep på en fysisk prosess kan kreve forståelse av kontrollsystemet, utstyret og prosessen som styres. På et tidspunkt slutter problemet å være rent cybersecurity. Angriperen driver i praksis med engineering, bare med et helt annet formål enn de som opprinnelig designet og driver anlegget.

Det er også her kombinasjonen av Purdue og kill chain blir nyttig. Purdue forteller noe om hvilken funksjon angriperen har nådd. Kill chain sier noe om hvor langt angriperen har kommet i å omsette denne tilgangen til en faktisk effekt.

Ikke alle cyberangrep trenger å komme så langt

En angriper trenger samtidig ikke gjennomføre hele ICS Cyber Kill Chain for å skape store problemer i en industrivirksomhet.

Ransomware er et godt eksempel. Produksjonen kan måtte stanses fordi systemer som trengs for sikker eller forsvarlig drift er utilgjengelige, selv om angriperen aldri har forstått prosesslogikken eller sendt en ondsinnet kommando til en kontroller. Det kan bli alvorlige konsekvenser for produksjonen lenge før noen har nådd Nivå 0 og tuklet der nede.

ICS Cyber Kill Chain blir særlig interessant når vi prøver å forstå målrettede angrep der angriperen ønsker en bestemt fysisk effekt og trenger en viss kontroll over resultatet. Da er tilgang alene ikke tilstrekkelig. Angriperen må lære nok om systemet og prosessen til å forstå hva en handling faktisk kommer til å gjøre.

Dette tankesettet påvirker også hvordan vi bør bygge og jobbe med forsvar. Hvis all oppmerksomheten ligger på å hindre den aller første delen av angrepet, legger vi mye av sikkerheten helt i starten av kjeden. En stjålet konto, en sårbar server eller en kompromittert klient bør likevel ikke være nok til å kontrollere en fysisk prosess. Hvert nytt steg bør møte ny motstand.

Da blir det lettere å diskutere hva defense in depth betyr for OT. Segmentering bør begrense hvor en kompromittert maskin kan kommunisere. Remote access bør gjøre det vanskeligere å bruke én kompromittert identitet til å gå videre. Engineering-endringer bør kunne oppdages og kontrolleres som engineering-endringer, ikke bare som generell nettverkstrafikk. Arkitekturen bør være laget slik at tilgang til ett system ikke automatisk gir samme tillit videre nedover. Her ligger det mye fornuftig i en Zero Trust-tankegang, selv om den må anvendes med en del andre ingredienser enn hva som er vanlig innen mer rene IT-systemer.

Når cyber blir fysisk

Mot slutten av et angrep som faktisk skal påvirke prosessen kommer angriperen frem til et grensesnitt som er vel så interessant som skillet mellom IT og OT. Det er grensesnittet mellom digital informasjon og fysisk handling.

En kontroller beregner en verdi og sender et signal. En aktuator tar imot signalet og får en ventil til å flytte seg. Strømmen gjennom røret endres, og trykket et annet sted i prosessen begynner å bevege seg. Først når vi forstår denne kjeden kan vi si noe presist om hvilken fysisk konsekvens et cyberangrep faktisk kan få.

Det påvirker også hvordan vi designer beskyttelsen. En brannmur kan stoppe trafikken. Tilgangsstyring kan stoppe en bruker. Kontrollsystemet kan avvise en kommando som bryter med logikken. Men dersom en legitim kommando likevel klarer å bringe prosessen mot en farlig tilstand, bør vi vite hva som er igjen av beskyttelsesmekanismer, om noen.

Nå møtes cybersecurity, engineering og process safety. Forriglinger, safety-funksjoner og fysiske barrierer blir interessante å se i sammenheng med hverandre fordi de kan begrense hvordan en digital handling utvikler seg til en fysisk konsekvens. Det er viktig at beskyttelsesmekanismene er tilstrekkelig uavhengige av hverandre, slik at én feil eller ett kompromiss ikke påvirker flere av dem negativt eller utløser en dominoeffekt gjennom systemet. Hvis flere beskyttelseslag i realiteten er avhengige av samme system, samme signal eller samme tilgangsvei, kan flere barrierer forsvinne samtidig.

Så går vi tilbake til klokken 03:17. Trykket stiger fremdeles, og operatøren forsøker å finne årsaken. Cyberangrepet har startet langt høyere oppe i arkitekturen og lenge før den første alarmen. Til slutt er det fysikken som bestemmer hva hendelsen blir.

Hvis en mekanisk sikkerhetsventil er den siste barrieren, trenger den ikke vite om trykket steg på grunn av en feil i kontrollsystemet, en menneskelig handling eller en angriper. Den åpner når trykket blir høyt nok.