Når nettleseren endres: Har dere kontroll på tilgangen til eldre OT-systemer?

Har dere kontroll på tilgangen til eldre OT-systemer?
Har dere kontroll på tilgangen til eldre OT-systemer?
Artikkel Cybersikkerhet Nettverk
5 min lesning
Del til

Google planlegger å fjerne innebygd XSLT-støtte i Chrome. For virksomheter med eldre, nettleserbaserte grensesnitt er dette en anledning til å undersøke både kompatibilitet og sikker tilgang – før brukerne møter problemer.

Et administrasjonsgrensesnitt kan fungere i dag og få problemer etter en nettleseroppdatering. I et OT-miljø bør slike avhengigheter avklares før en tekniker trenger tilgang for å undersøke en feil eller gjennomføre vedlikehold.

Bakgrunnen er en varslet endring i hvordan nettlesere håndterer XSLT. Teknologien brukes til å omforme XML-data til blant annet lesbare nettsider. Når denne behandlingen skjer i nettleseren, kan grensesnittet være avhengig av funksjonalitet som nå fases ut. Behandling som allerede skjer på serveren, rammes ikke direkte av denne nettleserendringen.

Hva endres – og når?

Ifølge Googles publiserte plan skal innebygd XSLT-støtte deaktiveres som standard i Chrome 158, planlagt 17. november 2026. Google beskriver også tidsbegrensede overgangsordninger for enkelte virksomheter og nettsteder.

Firefox- og WebKit-prosjektene har også signalisert planer om utfasing. Tidsplanen er likevel ikke nødvendigvis den samme: Microsoft oppgir versjon 159 for endringen i stabil Edge. Virksomheter bør derfor undersøke nettleserne og versjonene de faktisk bruker.

Google begrunner utfasing med å redusere nettleserens angrepsflate og risiko knyttet til den underliggende implementasjonen. Dette betyr ikke at alle systemer som bruker XSLT, er kompromittert.

Hvorfor bør OT-ansvarlige undersøke dette?

Google trekker selv frem innebygde enheter som leverer XML-data med XSLT for visning i nettleseren, og påpeker at enkelte slike enheter kan være vanskelige å oppdatere. Dokumentasjonen gir imidlertid ikke grunnlag for å fastslå hvor utbredt dette er i OT.

Vår anbefaling er derfor å undersøke konkrete systemer fremfor å anta at alt eldre utstyr er berørt.

Start med grensesnitt som er viktige for drift, feilsøking og vedlikehold. Dersom et av dem er avhengig av nettleserens XSLT-støtte, bør dere avklare hvilke arbeidsoppgaver som påvirkes. En feil i administrasjonsgrensesnittet betyr ikke nødvendigvis at selve prosessen stopper, men konsekvensene for tilsyn og feilretting må vurderes.

Dette bør gjøres sammen med systemleverandøren og de som kjenner anleggets operative krav.

Begynn med kartlegging og en kontrollert test

Vi anbefaler fem steg:

  1. Finn de kritiske grensesnittene. Ta med både intern tilgang og tilgangen eksterne serviceleverandører bruker.
  2. Avklar avhengigheten. Be systemleverandøren bekrefte om løsningen bruker nettleserbasert XSLT, og hvilke oppdateringer eller alternativer som finnes.
  3. Test relevante arbeidsoppgaver. Kontroller pålogging, navigasjon, visning og nødvendige funksjoner i et egnet testmiljø.
  4. Velg tiltak ut fra konsekvensene. Prioriter systemene der bortfall av tilgang vil gjøre det vanskelig å opprettholde eller gjenopprette normal drift.
  5. Dokumenter overgangsløsningen. Gi eventuelle unntak en ansvarlig, en risikovurdering og en dato for ny vurdering.

Målet er å få en bekreftet oversikt over hva som faktisk trenger tiltak.

Kan problemet løses på serversiden?

En mulig tilnærming er å flytte omformingen av XML til serveren eller et egnet mellomledd, slik at nettleseren mottar ferdig HTML.

NGINX har eksempelvis en dokumentert XSLT-modul som kan omforme XML-responser. Modulen er ikke aktivert som standard og bruker bibliotekene libxml2 og libxslt. En slik løsning krever derfor både teknisk tilpasning, testing og vedlikehold.

En vanlig reverse proxy eller WAF løser ikke automatisk problemet. Løsningen må faktisk utføre den nødvendige omformingen og fungere med applikasjonens pålogging, sesjoner og øvrige funksjoner.

For OT anbefaler vi at denne typen endringer avklares med systemleverandøren før de innføres.

Hvor passer FortiPAM inn?

Når et eldre grensesnitt må beholdes, bør dere samtidig vurdere hvordan tilgangen til det styres.

FortiPAM er en løsning for administrasjon av privilegert tilgang. Fortinet dokumenterer blant annet rollebaserte rettigheter, beskyttelse av påloggingsinformasjon, godkjenningsflyter og overvåking og opptak av privilegerte økter. Fortinet beskriver også bruksområder innen OT og sikker fjerntilgang. Funksjonene avhenger av valgt oppsett og støttet tilgangsmetode.

Dette gjør FortiPAM relevant når dere vil få bedre kontroll på vedlikeholds- og leverandørtilgang: Hvem skal få tilgang? Til hvilke systemer? Hvem skal godkjenne den, og hvordan skal aktivitetene kunne følges opp?

XSLT-kompatibiliteten må likevel avklares separat. Tilgang gjennom FortiPAM er ikke i seg selv dokumentasjon på at et XSLT-avhengig grensesnitt vil fungere etter nettleserendringen. Hele tilgangskjeden må testes mot det aktuelle systemet.

Planlegg for både drift og sikkerhet

Vi anbefaler å prioritere en støttet løsning som fjerner avhengigheten av nettleserens innebygde XSLT-funksjon. Der det ikke er gjennomførbart på kort sikt, bør virksomheten velge en kontrollert overgang med tydelig ansvar og plan for videre tiltak.

Hos NetNordic forstår vi at eldre OT-systemer ikke kan endres på samme måte som en vanlig nettside. Driftshensyn, leverandørkrav og sikkerhet må vurderes samlet.

Vi kan sammen med dere kartlegge berørte grensesnitt, teste alternative tilgangsmåter og vurdere hvor FortiPAM eller andre tiltak kan gi bedre kontroll. Første steg er å finne ut hva som faktisk er berørt – og hva som skal til for å bevare trygg og fungerende tilgang.

Forfatter

Raymond Utsi

Raymond Utsi

Team Lead Protective Security

Ta kontakt

Fyll ut skjemaet så kommer vi tilbake til deg så snart som mulig! Takk!