Malware i maskinrommet: Avvik fra normaltilstand

Kritisk infrastruktur som vann, varme, strøm, og kollektiv transport er utsatt for en reell trussel. -Risiko 2025 - Nasjonal sikkerhetsmyndighet
Og vi som enkeltpersoner må også være forberedt på å være uten essensielle midler. - Planlegg din egenberedskap

Hvordan kan vi som jobber med operasjonell teknologi vite om miljøet er eller blir utsatt for unormal digital påvirkning?

• Vi må kartlegge hvordan normal drift ser ut i nettverket.

• Vi må søke etter, og bli varslet om, avvik fra normaltilstand.

Vi finner ikke det vi ikke søker etter!

OT Miljø – Oversikt

For å gjøre dette håndfast, og knytte det til virkelighet, har jeg satt opp en enkel simulert operasjon. Operasjonen består av tre forskjellige beholdere der vann tilførsel og avløp er styrt av en kontroller (PLC).

Her er også et forenklet diagram av miljøet. Og til info så er protokollen mellom PLC og HMI "Modbus TCP". Modbus er en av de eldste og mest brukte protokollene for seriell kommunikasjon.

Hva kan gå galt?

Det er et grunnleggende spørsmål å stille.

Fra en digital vinkling så kan det oppstå nettverksbrudd mellom HMI og Switch, eller Switch og PLC. Det kan også forekomme data korrupsjon i kommunikasjonskanalen, men her det som regel CRC-mekanisme for å verifisere innkommende data.

Hva om det blir sendt funksjonskoder og verdier til PLC som er utenfor programmert oppførsel?

Du vet kanskje hvor jeg vil – Det er en risiko for at miljøet blir utsatt for ondsinnet aktivitet på en digital måte. Det er flere historiske eksempler og rapporter på hvordan trusselaktører har angrepet infrastruktur og gjort skade på utstyr, i tillegg til at det har påvirket menneskers liv i en eller annen form.

Normaltilstand

Hvordan ser normaltilstanden ut?

Det er jo unikt for hvert miljø, så her må vi samle inn trafikklogg og se på statistikken.

Til info: I test miljøet mitt har jeg en server som «Polling Period» på 100 millisekunder.

Detaljert graf som viser pakker per sekund.

• Her ser vi at maks antall pakker ikke overstiger 170 pakker i sekundet.

• Det er ingen funksjonskode som blir sendt for «Write Single Register».

• Hver unike «Write» instruks overstiger ikke 25 pakker i sekundet.

Her kan vi lage noen alarmer for å få varsel hvis miljøet avviker denne tilstanden.

Enten hvis antall nettverkspakker overstiger 170 per sekund, eller hvis antall pakker med «Write Multiple …» overstiger 25 per sekund. Jeg har visualisert det i følgende bildet med to fargede streker.

Simulert angrep

Da er det på tide å simulere et angrep for å se om vi detekterer avvik.

I dette scenarioet har jeg lastet ned en FrostyGoop versjon. Denne skadevaren er blitt brukt til å slå av varmen til over 600 boliger i Ukraina. Utdypende rapport her: Dragos-FrostyGoop-ICS-Malware-Intel-Brief-0724_r2.pdf

Etter å ha lastet ned skadevaren så lager jeg den nødvendige konfigurasjonsfilen, «task_test.json», som inneholder IP adresse for PLC og Modbus funksjonen som skal kjøres. Til slutt så eksekverer jeg filen med konfigurasjonsfilen, rettet mot miljøet.

Bildet viser skadevaren som kjører i kommandovinduet, og til høyre kan vi se en enkel kontrollstasjon. Hvis det er synlig på bildet så viser displayet på kontrollstasjonen en verdi på "9999". Det er også synlig i terminalvinduet, der ser man hvilken Register adresse som blir justert med spesifisert verdi.

For å simulere skade med gjentagende funksjonskall brukte jeg også en modifisert FrostyGoop "malware" som jeg kodet i Golang.

Deteksjon

Først kan vi se på hvordan trafikken så ut under angrepet. Og her ser vi at det absolutt har skjedd noe unormalt.

For det første så blir det plutselig sendt «Write Single Register», noe som ikke oppstod i normaltilstanden. De grønne prikkene kom når jeg eksvekverte FrostyGoop malware som jeg lastet ned fra MalwareBazar.

De andre elementene er veldig synlig; Det er en spike i mengde pakker som blir sent, og det er en økning med funksjonen «Write Multiple Coils». De kom fra en justert og egen-kompilert versjon av FrostyGoop.

Det som også oppstod under angrepet, men som ikke er synlig i bildet, er at det oppstod noen «TCP Errors». Og dette er det verdt å detektere og varsle på, hvis det er uvanlig i miljøet.

Men vi kan ikke ha en person som ser på slike grafer hele tiden for å se om tilstanden fortsatt er normal. Det er behov for et system som kan se på trafikken over tid og ikke bare på enkelte nettverkspakker. Zeek er et gratis verktøy som har denne funksjonen.

Med en tilpasset Zeek konfigurasjon kan vi alarmere på slik aktivitet:

Bildet viser et eksempel der zeek analyser nettverkstrafikk med en egendefinert konfigurasjonsfil som er justert i forhold til miljøet. Og dette resulterer i aktuelle alarmer som er synlig på nedre del av bildet.

Oppsummering

Jeg har fokusert på et lite område innenfor sammensatt komplisert teknisk felt. Og her finnes det flere risikoer som må prioriteres.

Vi må være forberedt, personlig og organisert, at essensielle tjenester kan bli utsatt for angrep. Og da bør vi ha en plan for hvordan vi skal håndtere denne situasjonen der tjenester kan være ute av drift.

Jeg avslutter med å sitere noen nøkkelpunkter fra «Risiko 2025 - Nasjonal sikkerhetsmyndighet»:

Det er viktig å overvåke systemene til kritisk infrastruktur for å kunne avdekke uvanlig eller mistenkelig aktivitet.

• Sørg for overvåking av digitale systemer for kritisk infrastruktur og reduser digitale sårbarheter der dette er mulig.

• Gjennomgå beredskapsrutiner og øv på bortfall av kritiske innsatsfaktorer.

• Etabler varslingsrutiner med lav terskel for varsling av mistenkelige eller uønskede hendelser, både internt og til politiet og andre myndigheter.

I neste artikkel, "Når normalen brytes: Slik avsløres digitale trusler i OT-nettverk" får du vite de tekniske detaljene rundt hvordan angrepet ble utført og hvordan du kan lage din egen tilpasset varsling.