Hva mer stopper? Forstå avhengigheter mellom IT-systemer og leverandører

De fleste virksomheter kan legge frem en liste over IT-systemene sine. Langt færre kan svare på et mer viktig spørsmål:

Hva mer stopper når ett av dem går ned?

Dette er i økende grad ikke bare et nyttig spørsmål for IT-driften. Å forstå avhengigheter har blitt en eksplisitt del av regelverk for cybersikkerhet og operasjonell robusthet.

I Norge krever digitalsikkerhetsforskriften at omfattede tilbydere av essensielle tjenester dokumenterer betydningen av nettverks- og informasjonssystemene sine for leveransen av tjenesten, samt i hvilken grad organisasjonen er avhengig av andre virksomheter for å fungere. Leverandører som kan påvirke sikkerheten i disse systemene, må også følges opp.

NIS2 tar samme retning på EU-nivå. Sikkerhet i leverandørkjeden er et av de pålagte risikostyringstiltakene innen cybersikkerhet, og direktivet adresserer spesifikt kritiske avhengigheter og potensielle enkeltpunkter for feil (single points of failure) i leverandørkjeder.

For finansielle virksomheter går DORA lenger. Det krever at virksomheter identifiserer IKT-støttede forretningsfunksjoner og de tilhørende ressursene, inkludert deres avhengigheter, og kartlegger koblinger og gjensidige avhengigheter mellom IKT-ressurser. Det krever også identifisering av prosesser som er avhengige av tredjepartsleverandører av IKT-tjenester.

Det er en god grunn til dette.

Et systemregister forteller dere at et system eksisterer. Det kan fortelle hvem som eier det, hvilken leverandør som leverer det, hvilken informasjon det behandler og hvor viktig noen mener det er.

Det forteller ikke nødvendigvis at syv andre systemer stopper i det øyeblikket dette systemet gjør det.

Og et leverandørregister forteller ikke nødvendigvis hvilken av de fem hundre leverandørene deres dere genuint ikke kan klare dere uten.

Den informasjonen eksisterer ofte et sted i virksomheten. Problemet er at den finnes i hodene på folk.

Dere oppdager det under en hendelse, en risikovurdering, en due diligence-prosess, eller når noen stiller et tilsynelatende enkelt spørsmål i et ledelsesmøte.

Vi bygde avhengighetsanalyse i Cyrigo for å gjøre disse avhengighetene synlige – og nyttige.

Fra et systemregister til et avhengighetskart

Systemer er avhengige av andre systemer. Et lønnssystem kan være avhengig av en identitetstilbyder for autentisering, mens et rapporteringssystem er avhengig av flere fagsystemer for data.

Det viktige spørsmålet er ikke bare om systemene er koblet sammen, men hva som skjer når en avhengighet faller bort. Noen avhengigheter er kritiske: systemet stopper uten dem. Andre tillater at det fortsetter med redusert funksjonalitet.

Å fange opp dette skillet gjør kartlegging av systemavhengigheter til noe nyttig for risikostyring, kontinuitetsplanlegging og operasjonell robusthet. Målet er ikke å lage et perfekt arkitekturdiagram. Det handler om å forstå hvordan feil forplanter seg gjennom virksomheten.

Finne skjulte kritiske systemer og sårbarheter (single points of failure)

De fleste virksomheter klassifiserer nok allerede viktigheten eller kritikaliteten til IT-systemene sine. Avhengighetsanalyse tilfører et annet perspektiv: hvor stor del av virksomheten er egentlig avhengig av dem?

De to samsvarer ikke alltid.

En tilsynelatende ordinær infrastrukturtjeneste kan støtte flere forretningskritiske systemer og prosesser uten selv å være klassifisert som kritisk. Flere viktige systemer kan også dele samme underliggende avhengighet, noe som skaper en sårbarhet (single point of failure) eller konsentrasjonsrisiko som er vanskelig å se fra et tradisjonelt IT-systemregister.

Dette gjør det mulig å identifisere hvor redundans, alternative ruter eller redusert driftsmodus kan forbedre robustheten vesentlig.

"Tilgjengelig" og "utilgjengelig" er sjelden de eneste alternativene. Et system kan fungere uten en integrasjon i flere timer, bruke en alternativ autentiseringsmetode eller midlertidig falle tilbake på en manuell prosess.

Det nyttige spørsmålet blir:

Hva kan vi endre slik at færre ting stopper neste gang?

Hvilke leverandører er faktisk kritiske?

Det samme prinsippet gjelder for risikostyring av leverandører.

Kontraktsverdi, datasensitivitet og manuelt tildelt leverandørkritikalitet er nyttige parametere, men de svarer ikke på:

Hva stopper faktisk hvis denne leverandøren forsvinner?

Å kombinere leverandørinformasjon med IT-systemavhengigheter gir et bilde av den operasjonelle leverandøravhengigheten. En relativt liten leverandør kan støtte systemer som store deler av virksomheten er avhengig av, mens en kommersielt viktig leverandør kan ha relativt liten operasjonell innvirkning.

Dette hjelper med å fokusere leverandøroppfølging, kontinuitetsplanlegging, exit-strategier og arbeidet med å redusere leverandørlåsing (vendor lock-in) der det betyr mest.

Og avhengighetskjeden stopper ikke nødvendigvis hos den direkte leverandøren deres. Skyleverandører, driftsselskaper, teleoperatører og andre underleverandører skaper tredjeparts- og fjerdepartssavhengigheter.

Det er en viktig forskjell på ingen avhengighet og ingen kjent avhengighet. Hvis en leverandør bruker underleverandører, men dere ikke vet hvem de er, er det et hull i risikobildet for leverandørkjeden, ikke et bevis på at avhengigheten ikke eksisterer.

Avhengigheter kan også avdekke flyt av personopplysninger

Systemavhengigheter kan gi nyttig kontekst for arbeid med personvern og GDPR.

En protokoll over behandlingsaktiviteter etter GDPR artikkel 30 beskriver behandlingen av personopplysninger, men data forblir sjelden i én applikasjon. De flytter seg mellom systemer, integrasjoner og leverandører.

Å sammenligne behandlingsaktiviteter med systemrelasjoner kan derfor bidra til å identifisere udokumenterte systemer, integrasjoner og dataflyt nedstrøms.

Dette erstatter ikke behandlingsprotokollen. Det bidrar til å teste om det dokumenterte bildet stemmer overens med systemene som faktisk er involvert i behandlingen av personopplysninger.

Avhengighetsanalyse er et annet perspektiv, ikke en ny risikoscore

Kritikalitet for virksomheten, cybersikkerhetsrisiko, datasensitivitet, økonomisk eksponering og operasjonell avhengighet er forskjellige ting. Avhengighetsanalyse bør ikke slå disse sammen til én enkelt score for "faktisk risiko".

Verdien ligger i å sammenligne dem.

Hvis et system er klassifisert som relativt uviktig, mens flere kritiske tjenester er avhengige av det, fortjener dette avviket oppmerksomhet. Det samme gjelder leverandører.

Det er også en åpenbar begrensning: dere kan ikke analysere avhengigheter dere ikke har kartlagt. Dekning og usikkerhet må derfor forbli synlig. En avhengighetsanalyse blir mer nyttig etter hvert som kunnskapen om IT-miljøet forbedres.

Fra inventar til operasjonell robusthet

System- og leverandørregistre svarer på et viktig spørsmål:

Hva har vi?

Avhengighetsanalyse tilfører spørsmålene som trengs for risikostyring og operasjonell robusthet:

Hva avhenger av hva? Hva skjer når noe svikter? Hvor er våre kritiske avhengigheter og sårbarheter (single points of failure)? Og hva kan vi endre slik at færre ting stopper?

Det er derfor vi har bygget avhengighetsanalyse inn i Cyrigo.

Formålet er ikke å lage enda et diagram. Det er å ta bedre beslutninger om IT-robusthet, kontinuitet i virksomheten, leverandørrisiko, risiko i leverandørkjeden og sikkerhetsinvesteringer.

For når et viktig system svikter, hjelper det lite å vite at det er viktig.

Å vite hva mer som stopper, gjør det.