Bedre innsikt i industrielle miljø

I løpet av dette året har vi sett en økende etterspørsel rundt sikkerhet tilknyttet industrielle miljøer og infrastruktur. Vi ser flere produkter på markedet, og stadig flere aktører lanserer tjenester rundt sikkerhet i industriell infrastruktur. Som vi ofte ser innenfor sikkerhetsporteføljen i IT, består anbefalinger rundt sikkerhet i OT også av enkeltprodukter som skal løse mer eller mindre alle problemer. I realiteten er de tekniske sikkerhetsløsningene som settes i drift, kun en liten brikke i et stort puslespill, ofte uten at man vet hvordan puslespillet omsider kommer til å se ut.

Det er utfordrende å bygge sikkerhet rundt et miljø der målbilde for digital sikkerhet ofte er manglende, lite gjennomtenkt eller tiltenkt et helt annet miljø. For mange kan bruk av et godt etablert målbilde for IT-sikkerhet hjelpe deg i gang med arbeidet, men man ser fort at dette blir for tynt når man begynner å forstå konsekvenser og risiko, tekniske muligheter (eller en generell mangel på dette) og en generelt liten vilje til å endre på prosesser og godt innarbeidede rutiner for å kunne bedre sikkerheten i anlegget.

Dyktige sikkerhetsfolk, som har jobbet innenfor IT-sikkerhet i mange år, blir stadig utfordret når de må forstå forskjellen mellom IT og OT og hvilke mekanismer man kan bruke og, ikke minst, hvilke mekanismer som faktisk gir en bedre sikkerhet. Vi kommer ofte opp i diskusjoner der «agenter» blir tatt opp som en løsning for endepunktsikkerhet, men denne løsningen er kun så god som den tilgangen agenten har til systemet den kjører på. Et eksempel er leverandører av applikasjoner som kjører på «engineering stations». Disse har ofte krav til miljøet der denne applikasjonen skal kjøre, og setter i noen tilfeller begrensninger på hva andre applikasjoner på samme system har tilgang til. Disse begrensningene er ikke nødvendigvis teknisk begrunnet, men satt som et forbehold fra leverandør for at leverandører skal kunne garantere for forutsigbarhet og stabilitet

i den leverte løsningen. Dersom en kunde ikke forholder seg til disse begrensningene, kan leverandøren i verste fall velge å invalidere avtaler eller gå bort fra SLA betingelser på en leveranse.

For organisasjoner som leverer kritisk infrastruktur og andre som er helt og holdent avhengig av et stabilt produksjonsmiljø, er det ikke et alternativ å sitte igjen uten garantier for leverandørens leverte løsninger. Dersom dialog med leverandøren ikke fører frem, kan virksomheten derfor måtte velge å avstå fra å installere agenter som kan kompromittere en komponents funksjonalitet. Her har vi også antatt at utstyret kan kjøre agenter, en antagelse man absolutt ikke kan gjøre i et typisk industrielt miljø. Det er ikke ukjent at komponenter i industrielle miljøer kan være av en eldre generasjon (noe som er helt naturlig med tanke på levetiden på disse anleggene), eller har en kapasitet eller teknologisk beskaffenhet som hindrer kjøring av relevante agenter.

I IT utvikles applikasjoner og applikasjonenes krav til ressurser i rekordfart, mens i OT, der en komponents oppgave kan være å styre en enkelt I/O ser vi ikke samme krav til en økning i prosessorkraft. Utstyr som ble installert for 20 år siden er ofte like godt for å gjøre den samme oppgaven det opprinnelig var tiltenkt den dag i dag. Det skal ikke sies at industrielt utstyr ikke har blitt modernisert, lang derifra, men prosessene er ofte de samme, og spesielt når man kommer ned til kommunikasjonslaget (Purdue level 1 og 0). Moderne industrielle styringssystem (ICS/IACS) kan være like store og komplekse som de største systemene innenfor typisk IT, men da snakker vi også om systemer som kjører på moderne infrastruktur i kontrollerte omgivelser og med egne team for drift og vedlikehold.

I slike systemer ser vi at sikkerheten er mer gjennomtenkt og at tekniske kapabiliteter muliggjør sikkerhetsfunksjoner som endepunktsikring, antivirus, rollebaserte tilganger, lokale brannmurer og segmentering. Separasjon av komponenter og funksjonalitet (modulær design) basert på sikkerhet, tilgjengelighet, risiko og konsekvens. Dette er vel og bra, men en kjede er ikke sterkere enn det svakeste ledd.

Dersom vi skal sikre industrielle miljø og infrastruktur er det essensielt at vi har muligheten for å sikre alle ledd. For at dette skal være oppnåelig må vi først og fremst vite hva vi har. Når vi vet hva vi har, kan vi begynne å klassifisere utstyret basert på en operasjonell og funksjonell risiko- og sårbarhetsmatrise, samt se på de mulige konsekvensene av hendelser i forskjellige deler av infrastrukturen.

En enhetsdatabase (Asset Inventory) er et godt utgangspunkt for denne jobben, men her støter man ofte på utfordringer. En av utfordringene er knyttet til kjennskap til utstyrets funksjon i et større anlegg. Typisk er utstyret ofte knyttet til en leveranse og gjerne en serviceavtale med en leverandør. Leverandøren har ansvaret for utstyret så lenge dette er knyttet til serviceavtalen og gjør de endringene og oppdateringene som er nødvendig for utstyrets funksjon og tilordnet oppgave. Dokumentert informasjon samsvarer altså ikke alltid med utstyrets reelle funksjon, og i noen tilfeller har utstyret gjennom dets levetid fått endrede oppgaver som gjør at en tidligere risiko- og konsekvensvurdering ikke lenger er gyldig. Dette kan få alvorlige konsekvenser ved en hendelse, og da spesielt knyttet opp mot mitigerende tiltak skulle det komme til dette.

Dette bringer oss over på neste punkt; sikkerhetsmonitorering. Security Operations Centre (SOC) er ofte varmt omtalt så snart diskusjonen vris inn mot sikkerhet. Dette er vel og bra, og en SOC er et ekstremt viktig organ som en del av en helhetlig sikring av enhver infrastruktur. Hva godt gjør vel alle sikkerhets- og analyseprodukter dersom ingen er der for å følge med på å agere på alarmer og hendelser? En SOC sin hovedoppgave er å følge med på, analysere, og reagere på hendelser i infrastrukturen. Det er ikke alltid at en alarm er forårsaket av en sikkerhetshendelse eller resulterer i et brudd på sikkerheten, men dette vil ikke automatiserte systemer alltid kunne ta stilling til. Vi vil derfor i mange tilfeller fortsatt ha behov for et menneskes analytiske evner for å gjøre den endelige vurderingen.

Innen IT er vi gode på dette. Vi vet godt hva forskjellige typer system er og hvilke funksjoner og roller disse har. Ut fra dette kan vi gjøre en korrekt vurdering over hvordan vi skal agere på en hendelse for å redusere konsekvensene og oppnå minst mulig forstyrrelser for resten av infrastrukturen. Inne i denne vurderingen er det et svært viktig element; konfidensialitet. Innen IT er konfidensialitet rangert til aller viktigst, med integritet på en god andre plass og til slutt kommer tilgjengelighet (den kjente CIA-trekanten). Dersom det er fare for brudd på konfidensialitet, er sikkerhetsteamet gitt myndighet til å isolere og i verste fall skru av utstyr, ofte uten noen form for autorisasjonsprosess for å forhindre uønsket tilgang til data.

I OT betyr dette i beste fall at en produksjonslinje eller en prosess stopper opp og må startes på nytt, og i verste fall fare for fysisk skade på utstyr og miljø og i tillegg tap av menneskeliv. I OT er CIA-trekanten snudd på hodet. AIC (Availability, Integrity and Confidentiality) og noen ganger også fått et første tillegg «C (Control)» som det aller viktigste punktet. For en SOC-operatør er dette vital informasjon og det forandrer alt med tanke på aggregering på alarmer og mitigerende tiltak. Muligheten for å isolere eller skru av utstyr er nå svært avhengig av utstyrets funksjonalitet og operasjonelle virkemåte. Men hvordan skal en SOC-operatør kunne vite dette? Vi vet at i større og komplekse anlegg er det et stort behov for å ha spesialkompetanse innenfor et spesifikt domene. For personer med denne spesialkompetansen er det selvfølgelig helt innlysende hvilke konsekvenser man får ved bortfall av en komponent, og produksjonsledere må støtte seg på denne kompetansen for at anlegget skal kunne operere innenfor gitte rammer og så sikkert som mulig.

Dersom man er heldig, er denne spesialkompetansen fordelt og tilgjengelig hele døgnet 365 dager i året. Dersom noe skulle skje så er det alltid kompetent personell til stede for å mitigere, rette og gjenopprette produksjonen tilbake til en normal tilstand. Men er disse personene i stand til å vurdere sikkerhetshendelser opp mot operasjonelle konsekvenser? Er disse personene i stand til å gjøre vurderinger opp mot operasjonell sikker drift gitt en hendelse av en helt annen natur enn det de er trent til å agere på? Kan man garantere tilgjengeligheten av slikt nøkkelpersonell gjennom hele anleggets levetid? Og hvis alle svarene over er «ja», kan man også garantere for at kommunikasjon og forståelse av en hendelse mellom disse og en SOC-operatør kan foregå uten problemer?

Det er her viktigheten av kontekstuell visibilitet kommer inn i bildet. For enhver type kompetanseprofil eller rolle involvert i sikringen av industrielle miljø, er det et behov for å sette sammen informasjon på en slik måte at den er umiddelbart nyttig og forståelig for alle som bruker den. En industriell komponent, si et styringssystem er for en SOC-operatør ofte representert i form av en IP-adresse og en MAC-adresse. Gitt denne informasjonen er det mulig å forstå noe av denne komponentens operasjonelle rolle ved å slå opp i forskjellige informasjonskilder som IP Address Management, Asset Inventory, Wiki, anleggsdokumentasjon, etc. SOAR-verktøy kan effektivisere dette ellers tidkrevende arbeidet, men informasjonen kan fort feiltolkes uten riktig kompetanse, og kan gi et ufullstendig bilde av de fysiske prosesser og potensielle konsekvenser som knytter seg til komponenten. Korrekt og tilgjengelig informasjon om enheter og komponenter er svært viktig i forhold til vurdering av kritikaliteten til utstyret, konsekvensene av en sikkerhetshendelse, og konsekvensene ved mitigerende handlinger.

Kontekstuell visibilitet er et konsept der programvare setter sammen all tilgjengelig informasjon og, ved hjelp av algoritmer og domenekunnskap, setter denne informasjonen sammen på en slik måte at den kan utnyttes av operatører innenfor sikkerhet så vel som operasjonell drift av anlegget. En programvare med tilgang til historisk og oppdatert dokumentasjon, enlinjeskjema, feeds fra nettverks-

infrastruktur og operasjonelle kilder, sanntidsdata fra sensorikk og Enterprise Resource and Planning system har en stor fordel ovenfor frittstående tjenester. Ved hjelp av en slik programvare kan man legge på forskjellige brukerapplikasjoner basert på hvilken rolle man skal utføre; en SOC ønsker tilgang til informasjon som gjelder digital sikring av anlegget, ledelsen og operasjonelt personell ønsker tilgang til risikovurderinger gitt endring i driftssituasjonen, vedlikehold eller innfasing og utfasing av utstyr og funksjonalitet. HMS-ledelse ønsker tilgang til informasjon rundt «safety» i forbindelse med personell lokalisert i anlegget og, dersom uhellet skulle være ute, ønsker incident-response teams tilgang til rådata og logger for analyse av en hendelse og for å kunne fastslå angrepsvektor og sikker tilbakestilling av anlegget.