Fra beslutning til utført endring: sporbarhetskravet i petroleumsregelverket, anvendt på identitetsplattformen

Et vanlig spørsmål fra IT-ledere i petroleumsvirksomhet: hvilken paragraf i Havtils regelverk regulerer IKT-sikkerhet?

Svaret er at det ikke finnes én. HMS-regelverket for petroleumsvirksomheten — rammeforskriften, styringsforskriften, aktivitetsforskriften og innretningsforskriften — har ikke en egen digital sikkerhets-forskrift tilsvarende digitalsikkerhetsloven. IKT-sikkerhet håndteres gjennom de generelle styringskravene, supplert av bransjestandarden Offshore Norge 104 som innretningsforskriften § 34a viser til i veiledningen.

Dette oppleves som en lettelse. Det er det motsatte. En eksplisitt paragraf ville gitt en avgrenset liste å krysse av. De generelle styringskravene gir i stedet en forventning om at IKT-sikkerhet håndteres med samme systematikk som alt annet sikkerhetskritisk — barrierer som er identifisert og har kjent ytelse, avvik som registreres og årsaksanalyseres, data som samles inn og brukes.

Det er en høyere standard, ikke en lavere.

Til orientering: tilsynet skiftet navn fra Petroleumstilsynet til Havindustritilsynet (Havtil) med virkning fra 1. januar 2024, engelsk navn Norwegian Ocean Industry Authority, underlagt Energidepartementet.

De fire bestemmelsene som faktisk treffer

Styringsforskriften § 5, Barrierer. Krever at det etableres barrierer som identifiserer og forhindrer tilstander som kan føre til feil-, fare- og ulykkessituasjoner. Barrierer skal være kjent — hvilken funksjon de har, hvilken ytelse de skal ha, og hvem som har ansvaret.

Anvendt på identitet: hvis tilgangskontroll mot en systemsti som fører inn mot sikkerhetskritiske systemer er en barriere, må den behandles som en barriere. Den må ha en definert ytelse. Svikt i den må registreres som barrieresvikt. I de fleste virksomheter er tilgangskontroll i Entra ID ikke inkludert i barrierestyringen i det hele tatt, fordi den forvaltes som en administrativ IT-tjeneste.

Styringsforskriften § 6, Styring av helse, miljø og sikkerhet. Krever at styringen dekker nødvendige aktiviteter, ressurser og prosesser. Prosessene skal være beskrevet, og de beskrevne prosessene skal være de som faktisk følges. Avstanden mellom beskrevet og faktisk praksis i tilgangsstyring er ofte betydelig — fordi den beskrevne prosessen er den formelle bestillingsflyten, mens den faktiske er en melding på Teams til en kollega med rettigheter.

Styringsforskriften § 19, Innsamling, bearbeiding og bruk av data, og § 20, Registrering, undersøkelse og gransking av fare- og ulykkessituasjoner. Data skal samles inn, bearbeides og brukes — ikke bare finnes. En revisjonslogg som teknisk sett inneholder alt, men som ingen kan hente noe meningsfullt ut av innen rimelig tid, oppfyller ikke intensjonen.

Styringsforskriften § 22, Avviksbehandling. Krever registrering, oppfølging, årsaksanalyse og korrigerende eller kompenserende tiltak. Dette er den mest praktisk krevende: årsaksanalyse forutsetter at man vet hva som faktisk skjedde, i hvilken rekkefølge, og på hvilken beslutning.

Tre spor som må settes sammen manuelt

Se på hva et konkret avvik krever av dokumentasjon i en tradisjonell oppsett. En intern revisjon avdekker at en person hadde tilgang til et system vedkommende ikke skulle hatt, i fire måneder.

For å behandle dette som avvik etter § 22 må man fastslå:

1. Når ble tilgangen gitt? Kilde: Entra-revisjonsloggen. Utfordring: standard oppbevaringstid i Entra er 30 dager med P1 eller P2, og hvis hendelsen er eldre enn det og ikke eksportert til et eksternt lager, finnes ikke svaret.

2. Hvem ga den? Samme kilde. Gir en kontoidentifikator, ikke en beslutning.

3. På hvilket grunnlag? Kilde: saksbehandlingssystemet, hvis det ble opprettet en sak. Ellers e-post. Ellers ingenting.

4. Hvem godkjente? Kilde: e-post, eller et felt i saksbehandlingssystemet, hvis godkjenningen ble registrert der og ikke gitt muntlig i et møte.

5. Ble det som ble godkjent, det som ble utført? Dette er spørsmålet ingen kan svare presist på, fordi det krever at man sammenholder en fritekstbeskrivelse i en sak med et sett tekniske hendelser i en logg, og vurderer om de tilsvarer hverandre.

Punkt fem er kjernen. I en modell der et menneske med administratorrettigheter utfører en godkjent endring manuelt, finnes det alltid et gap mellom beslutning og handling. Gapet er som regel tomt — teknikeren gjorde det som var avtalt. Men det kan ikke bevises uten manuell korrelasjon, og under en gransking er «vi antar at det stemmer» ikke et svar.

Hva en sammenhengende ordre gjør med dette

Entra Logics modell er å gjøre beslutning og utførelse til samme objekt. En endring i Entra ID oppstår som en forespørsel med forretningsbegrunnelse, får en godkjenningsbeslutning med navn og tidspunkt, og utføres deretter maskinelt av en sentral motor som kjører PowerShell mot Microsoft Graph. Resultatet av utførelsen — inkludert feil — skrives tilbake til samme post.

Konsekvensen for de fem spørsmålene over: alle fem besvares fra én kilde, og spørsmål fem besvares strukturelt i stedet for ved vurdering. Det som ble godkjent, er det som ble utført, fordi det ikke finnes et manuelt mellomsteg der noe annet kunne skjedd.

Dette er en dokumentasjonsegenskap, ikke bare en sikkerhetsegenskap. For § 22-behandling betyr det at årsaksanalysen kan begynne med fakta i stedet for med rekonstruksjon. For § 19 betyr det at data faktisk er i en form som lar seg bearbeide og bruke. For § 5 betyr det at barrieren har en målbar ytelse — antall endringer, antall avviste forespørsler, antall utførelsesfeil — som kan rapporteres.

Et poeng verdt å understreke for dem som har jobbet med granskninger: automatisert utførelse fjerner også hele kategorien avvik som skyldes at en tekniker under tidspress gjorde noe litt annet enn det som ble avtalt. Masseoperasjoner ved omorganisering er det klassiske eksempelet — et frihåndsskript som treffer feil gruppe. Strukturerte bulkforespørsler der hver enkelt endring fortsatt får sin egen tilregnelige ordre, fjerner den feilmodusen uten å fjerne effektiviteten.

Et forhold som ødelegger flere granskninger enn folk tror: oppbevaringstid

Standard oppbevaringstid for revisjons- og påloggingsdata i Entra ID er 30 dager for tenanter med Entra ID P1 eller P2, og 7 dager for Entra ID Free. Virksomheter som ikke aktivt eksporterer disse dataene til et lengre lager — en logganalyseplattform, et SIEM eller tilsvarende — har altså et vindu bakover på én måned.

Regnestykket er ubehagelig konkret. Et uberettiget tilgangsforhold oppdages sjelden innen 30 dager. Når oppdagelsen skjer gjennom en intern revisjon, en tilfeldighet eller en tilsynsforberedelse, er det typisk gått måneder. Da er svaret på «når og av hvem ble denne tilgangen gitt» ikke bare vanskelig å finne — det finnes ikke lenger.

Konsekvensen for § 22-behandling er at årsaksanalysen må baseres på antakelser. Det er ikke et akseptabelt utgangspunkt i et regelverk som bygger på at årsaker skal forstås for at korrigerende tiltak skal treffe.

En kontinuerlig synkronisert kopi av katalogtilstanden, med tilhørende endringshistorikk knyttet til ordrer, adresserer dette annerledes enn logglagring: i stedet for å lagre hendelser fra plattformen, holdes selve tilstanden og beslutningene som endret den. For dokumentasjonsformål er det ofte det som faktisk trengs — ikke hvert eneste tekniske kall, men hvem som besluttet hva, når, og hva som ble resultatet.

Hvor grensene går

Tre presiseringer, fordi overselging i denne bransjen straffer seg raskt.

Entra Logic dekker Microsoft-boet. Endringer i systemer utenfor Entra ID og de tilknyttede Microsoft-tjenestene får ikke dette revisjonssporet. For en operatør med et titalls fagsystemer er identitetsplattformen én av mange kilder.

Produktet er ikke et attesterings- eller sertifiseringsverktøy. Det kjører ikke periodiske kampanjer der ledere må bekrefte at underordnedes tilganger fortsatt er riktige, og det gjør ikke arbeidsdelingsanalyse. Krever virksomhetens styringssystem dette, må det dekkes annensteds.

Barrierestyring er en organisatorisk øvelse. Ingen leverandør kan definere hvilke av dine tekniske kontroller som er barrierer med hvilken ytelse. Det arbeidet må gjøres internt. Det programvaren kan gjøre, er å levere målbare tall om barrieren når den først er definert.

Tre spørsmål å stille i neste styringssystemgjennomgang

1. Er tilgangskontroll i identitetsplattformen inkludert i barrierebeskrivelsen, med definert ytelse og ansvarlig, eller behandles den som en administrativ IT-tjeneste?

2. Kan vi, for en tilfeldig valgt tilgangsendring fra forrige kvartal, dokumentere begrunnelse, godkjenner og faktisk utførelse — fra én kilde, på under ti minutter?

3. Hvor lenge lagres revisjonsdata om identitetsendringer faktisk, og er lagringstiden avstemt mot hvor lenge et avvik typisk går uoppdaget?

Spørsmål tre avdekker som regel et gap på flere måneder.

Kilder

• Microsoft, Microsoft Entra data retention (30 dager for P1/P2, 7 dager for Free) — https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-reports-data-retention
• Havtil, styringsforskriften (§§ 5, 6, 19, 20, 22) — https://www.havtil.no/globalassets/regelverk/gjeldende-regelverk-2022/styringsforskriften_n.pdf
• Havtil, rammeforskriften § 11 — https://www.havtil.no/en/regulations/all-acts/the-framework-regulations3/II/11/
• Havtil, innretningsforskriften § 34a (viser til ON 104 i veiledningen) — https://www.havtil.no/en/regulations/all-acts/the-facilities-regulations3/V/34a/
• Havtil om navneendringen fra Petroleumstilsynet, gjeldende fra 01.01.2024 — https://www.havtil.no/en/about-us/role-and-area-of-responsibility/our-history/
• Offshore Norge, retningslinjeoversikt (ON 104) — https://www.offshorenorge.no/en/faginnhold/guidelines/guidelines/
• DNV GL for Ptil/Havtil, Regelverk og tilsynsmetodikk — IKT-sikkerhet — https://www.havtil.no/globalassets/fagstoff/prosjektrapporter/ikt-sikkerhet/dnv-gl---regelverk-og-tilsynsmetodikk.pdf