Zero Trust Soldier

Fjernaksess er et hot tema innen kraftindustrien, men også for andre som drifter kritisk infrastruktur. Hvorfor?

Internett er fyfy fordi det utsetter kritiske systemer for økt risiko, og derfor har det historisk ofte ikke vært internett tilknyttet disse systemene. Men verden går videre og fremover, og systemene må snakke med andre systemer

IT og OT

Information Technology og Operational Technology.

OT systemer er typisk i produksjonsmiljøer. IT systemer er det vi i hverdagen omgir oss med, som er på kontoret, i skyen og på internett.

IT burde i hovedsak ikke snakke med OT, fordi det øker risiko, men blir stadig vanligere. OT trenger i dag ofte å snakke med IT for utveksling av data, statistikk og mer.

Fjernaksess for å spare tid og penger

OT miljøet inneholder mye spesialutstyr som krever spesiell kompetanse, gjerne fra eksterne. I tillegg kan lokasjoner være spredd geografisk, som f.eks på fjelltopper og øyer ute i havgapet.

Å etterleve den gamle holdningen om å kjøre alt dette uten internettilkobling vil bidra til tidkrevende prosesser ved endring, feilsøking og oppdatering. Tidkrevende betyr også kostbart, da både ansatte og eksterne må planlegge godt, og bruke mye tid på reise og selve jobben.

Dette danner grobunn for å se på tids og pengebesparende tiltak. Fjernaksess er et slik tiltak, men det må være sikkert.

Sikker fjernaksess, en nødvendighet, helst med FIDO2

Det er mange gode grunner for at fjernaksess klinger godt hos ledelsen. Men paranoide sikkerhetsmennesker liker typisk ikke løsningene. Da er det viktig å kompetanseheve seg. For verden har kommet veldig langt innen disse løsningene, nettopp fra et sikkerhets ståsted.

Zero Trust to the rescue

Fjernaksessen MÅ være mer sikker enn vanlig fjernaksess. Teknologien som benyttes kan være den samme som for vanlige IT miljøer, men designet må gjerne være en smule annerledes.

Operatører skal kunne nå løsningene fra internett, på en så sikker måte som mulig.

Uten internettaksess

Fjerning av internettaksess mens man er inne er et av de viktige tiltakene.

Dette er hvordan vi gjør det:

• Palo Alto Networks GlobalProtect er selve mekanismen for fjernaksess som er brukt (NVE var meget imponert over total-løsningen når de fikk denne presentert etter implementering)
• MFA er en naturlig komponent for disse miljøene, og det bør helst være FIDO2
  • FIDO2 benytter gjerne fysiske nøkler
• Eksterne må ringe til driftssentral for MFA detaljer dersom FIDO2 ikke er på plass.
• Når man har autentisert og kommet seg inn vil verifisering av tilstand på PC bidra til økt sikkerhet i forbindelse med videre tilgang. Mulighetene her er f.eks verifikasjon av at:
  • Brannmur er installert og aktiv
  • Endepunktsikkerhet er aktivt og oppdatert
  • Diskkryptering er aktivt
  • PC tilhører et spesifikt domene
  • Det ikke er utestående kritiske oppdateringer
  • Spesifikke registry settinger er på plass
• Når man har autentisert og kommet inn, vil regelsettet i brannmuren bare tillate én eneste tilgang, nemlig aksess til en jumpserver.
  • VPN forbindelsen er «full VPN», som betyr at all kommunikasjon fra PC’en går inn i VPN tunnelen
  • Aksess til internett er nå fjernet (VPN vil fortsatt fungere, som eneste forbindelse)
• Når man har logget på VPN vil man ha en bruker ID i brannmuren, som fungerer som ID i den eneste regelen som tillater trafikk mot jumpserver (RDP eller Apache Guacamole) der man igjen må logge på med MFA. #AssumeBreach
  • Det er meget viktig å alltid anta kompromittering og innføre tiltak deretter.
  • Full segmentering i tråd med Zero Trust og Purdue modellen er kritisk viktig.
  • MFA for alle pålogginger til alle systemer.
  • Internettaksess trengs ikke når man er inne i løsningen, derfor er det viktig med er regelsett som er bygget basert på #LeastPrivilege, og som bare tillater spesifikke behov, med en default deny regel i bunn. Dette forhindrer kommunikasjon med internett mens man er inne.

Neste steg er variabelt

Når man er inne på jumpserveren, uten internettaksess fra PC’en, ei heller for jumpserveren, er veien videre variabel fra kunde til kunde.

• Én anbefaling er å her skille tilganger, slik at videre tilgangskontroll skjer mot en ny brukerdatabase med andre brukernavn og passord.
• Alle tilganger videre inn i systemet MÅ ha MFA. Har man gamle systemer, eller systemer uten MFA støtte, vil segmentering i tråd med Purdue modellen bidra til mulighet for MFA i nettverket.

Andre anbefalinger

Denne artikkelen har til hensikt å belyse sikker fjernaksess. Dette er enkelt oppnåelig.

Andre anbefalinger man bør ta høyde for ved en slik løsning er god logging, helst med overvåking. En god endepunktsikkerhet på alle enheter i løsningen er også å anbefale, og jeg anbefaler å sjekke disse opp mot Mitre sitt framework.

Konklusjon

Fjernaksess er et sterkt behov, men det må være meget sikkert for kritiske OT miljøer.

Teknisk sett er dette lett tilgjengelig, og det er billig, så her er det bare å lese seg opp, eller spørre om hjelp.

VG testen vil stå til terningkast 6, da internett er der, men tilgangene er begrenset til behov. For internett har mange viktige egenskaper også for OT, inkludert software oppdateringer.