Når angrepet kommer gjennom leverandøren din 

En leverandørkonto, en programvareoppdatering eller en integrasjon kan bli en vei inn til virksomhetens systemer og data. God leverandørsikkerhet handler derfor både om kravene dere stiller, tilgangen dere gir, og evnen til å oppdage og begrense misbruk. 

Skytjenester, programvare, IT-drift og fjernsupport er en del av den daglige driften i mange virksomheter. Leverandørene bidrar med kompetanse, kapasitet og tjenester som virksomheten trenger. 

Samtidig skaper samarbeidet avhengigheter. En driftspartner kan ha administrative rettigheter. En programvareleverandør distribuerer oppdateringer inn i miljøet. En skytjeneste behandler sensitive data, mens integrasjoner kobler sammen systemer på tvers av virksomheter. 

Angrepsflaten stopper ikke lenger ved virksomhetens perimeter. Tilganger, programvare og integrasjoner fra leverandører kan også bli veier inn til virksomhetens systemer og data. Derfor må sikkerhetsarbeidet omfatte forbindelsene virksomheten er avhengig av, også når deler av tjenesten leveres og kontrolleres av andre. 

For virksomheten kan konsekvensene være driftsstans, tap av informasjon eller usikkerhet om hvilke systemer og data som er berørt. Det avgjørende er derfor ikke bare hvor godt leverandøren beskytter seg, men hvordan dere sammen forebygger og håndterer en hendelse. 

Angriperen trenger ikke alltid angripe deg direkte 

Når en angriper misbruker en kanal virksomheten allerede stoler på, kan det være vanskeligere å skille angrepet fra normal aktivitet. 

Men angrep gjennom leverandørkjeden kan skje på ulike måter: 

• Kompromittert programvare: Skadelig kode følger med programvare eller oppdateringer kunden installerer. 

• Misbrukt leverandørtilgang: Angriperen bruker en leverandørs kontoer eller fjernaksess til å nå kundens systemer. 

• Angrep mot tjenester som behandler kundens data: Informasjon kan bli stjålet hos leverandøren, uten at angriperen får tilgang til kundens eget miljø. 

SolarWinds og 3CX illustrerer hvordan kompromittert programvare kan distribueres gjennom kanaler kundene stoler på. MOVEit-hendelsene illustrerer en annen risiko: At utnyttelse av en sårbarhet i en mye brukt filoverføringsløsning kunne ramme mange virksomheter og dataene de behandlet samtidig.  

For angriperen kan dette være svært attraktivt. I stedet for å angripe hundre virksomheter individuelt, kan det være mer effektivt å kompromittere én leverandør som allerede har en etablert tilganger til disse virksomhetene. 

Spørsmålet bør derfor være konkret: Hvordan kan en hendelse hos en leverandør påvirke vår drift, våre systemer eller våre data? 

Leverandørstyring alene er ikke nok 

God leverandørstyring er viktig. Krav til tilgangsstyring, sårbarhetshåndtering, hendelsesvarsling, underleverandører og beredskap gir et grunnlag for samarbeidet. 

En relevant ISO-sertifisering eller leverandørrevisjon kan gi nyttig dokumentasjon på sikkerhetsarbeidet. Men dokumentasjonen må vurderes opp mot tjenesten som leveres, hvilke systemer og data den omfatter, og hvilke avhengigheter den skaper. Ingen sertifisering eller sikkerhetsklausul gir garanti mot kompromittering. 

Derfor bør man ikke bare spørre: «Hvordan arbeider leverandøren med sikkerhet?» 

Man bør også spørre: «Hva kan bli berørt hos oss dersom leverandøren rammes, hvordan får vi vite det, og hva kan vi gjøre?» 

Svarene må omsettes til tilganger, logging, kontaktpunkter og beslutningsmyndighet som fungerer i praksis. 

Fem ting virksomheter bør gjøre 

1. Identifiser leverandørene som kan få størst konsekvenser for dere 

Ikke alle leverandører representerer samme risiko. Start med dem som har tilgang til kritiske systemer, sensitive data, administrative grensesnitt eller sentrale driftsprosesser. 

Vurder også leverandører dere er avhengige av for å opprettholde driften, selv om de ikke har tilgang til eget IT-miljø. 

For hver kritiske leverandør bør dere kunne svare på tre spørsmål: Hva kan bli berørt? Hvor lenge kan dere klare dere uten tjenesten? Hvem har ansvar for oppfølgingen internt? 

2. Kartlegg tilganger og avhengigheter 

Dokumenter hvilke kontoer, integrasjoner, AI-agenter, API-er og fjernaksessløsninger leverandørene bruker, og hvilke systemer de kan nå. 

Gi bare tilgangen oppdraget krever. Bruk navngitte kontoer og sterk autentisering der det er mulig, og vurder tidsbegrenset administratortilgang. Begrens hvilke deler av miljøet leverandørtilgangen kan brukes mot. 

Leverandørtilganger bør også være en del av virksomhetens sikkerhetsarkitektur, ikke et unntak fra den. Tilgang bør så langt som mulig gis just-in-time, med minst mulige privilegier og kun til de applikasjonene og systemene leverandøren faktisk trenger. Leverandøridentiteter bør kunne verifiseres uavhengig av leverandørens eget miljø, og tilgangen bør isoleres og segmenteres fra øvrige deler av virksomhetens miljø. Målet er å begrense konsekvensene dersom en leverandørkonto kompromitteres. En legitim tilgang skal ikke automatisk gi en angriper mulighet til å bevege seg videre i miljøet. 

Følg også opp tilganger når oppdrag endres eller avsluttes. En tilgang som var nødvendig under en implementering, trenger ikke være nødvendig i den løpende driften. 

3. Sørg for at relevant aktivitet er synlig 

Avklar hvilke logger dere trenger for å undersøke hvordan leverandørtilgangen brukes. Det kan være innlogginger, administrative endringer, fjernaksess og aktivitet i kritiske applikasjoner. 

Kontroller at loggene faktisk samles inn, er tilgjengelige for dem som skal undersøke hendelser, og oppbevares lenge nok til å støtte undersøkelsene. 

For tjenester der dere har begrenset innsyn, må dere avklare hva leverandøren kan dokumentere og dele ved en hendelse. Egne logger viser ikke nødvendigvis hva som har skjedd inne i leverandørens miljø. 

4. Varsling, ansvar og tiltak 

Definer hvem som skal varsles ved mistanke om misbruk, hvem som undersøker hendelsen, og hvem som kan begrense eller stenge en tilgang. 

Avklar også hva leverandøren skal varsle dere om, gjennom hvilken kanal og hvor raskt. Kontaktinformasjonen bør være tilgjengelig også dersom vanlige kommunikasjonskanaler er berørt. 

For kritiske tjenester må dere forstå konsekvensene av å stenge tilgangen. Det kan være nødvendig å begrense enkelte rettigheter eller forbindelser samtidig som nødvendig drift opprettholdes. 

5. Test scenarioet før det skjer 

• Gjennomfør en øvelse der en kritisk leverandør varsler om kompromitterte kontoer eller mulig datatyveri. 
• Kan dere raskt finne leverandørens tilganger? Vet dere hvilke data som kan være berørt? Hvem beslutter tiltak, og hvordan opprettholder dere driften? 
• En enkel gjennomgang med virksomheten, driftspartneren og sikkerhetsfunksjonen kan avdekke uklare ansvarsforhold og manglende informasjon før dere står i en reell hendelse. 

Fra «hvem har tilgang?» til «hvordan brukes tilgangen?» 

Tilgangskontroll reduserer risikoen, men også en legitim konto kan misbrukes. 

En innlogging fra en leverandørkonto er ikke nødvendigvis mistenkelig. En administrativ endring trenger heller ikke være det. Men flere handlinger sett i sammenheng kan gi grunn til å undersøke nærmere. 

Tenk deg at en leverandørkonto logger inn utenfor avtalt vedlikeholdsvindu, fra en kilde som ikke er forventet. Kontoen får deretter utvidede rettigheter og brukes mot systemer leverandøren normalt ikke arbeider med. 

Dette er ikke i seg selv bevis på et angrep. Det kan finnes en legitim forklaring. Men aktiviteten bør kunne undersøkes og avklares med leverandøren. 

Da trenger dere både logger og kunnskap om hva leverandøren faktisk skal gjøre. Avtalte arbeidsoppgaver, vedlikeholdsvinduer og forventede tilgangsmønstre gir viktig kontekst til sikkerhetsanalysen. 

Hva kan en SOC bidra med? 

Et Security Operations Center, SOC, kan bidra til å oppdage og undersøke mistenkelig aktivitet ved å sammenstille informasjon fra identiteter, endepunkter, nettverk, skytjenester og applikasjoner. 

Verdien ligger blant annet i å se sammenhenger som kan være vanskelige å oppdage når hvert system vurderes isolert. SOC-en kan også støtte virksomheten med å vurdere omfang, prioritere tiltak og følge opp hendelsen med relevante leverandører. 

Hva SOC-en kan oppdage og bidra med, avhenger av hvilke systemer og logger som er koblet til, hvilke deteksjoner som er etablert, og hvilket ansvar og hvilke fullmakter som er avtalt. 

En SOC har ikke automatisk innsyn i leverandørens interne miljø. Dersom kundedata blir stjålet fra en tjeneste hos leverandøren, kan leverandørens varsling og undersøkelser være avgjørende for å forstå hva som har skjedd. 

Overvåking må derfor inngå i et større sikkerhetsarbeid som også omfatter forebyggende tiltak, leverandøroppfølging og beredskap. 

Når noe skjer, må grensene mellom leverandørene forsvinne 

En sikkerhetshendelse kan berøre flere leverandører samtidig. Én drifter nettverket, en annen håndterer Microsoft 365, og en tredje har ansvar for en kritisk applikasjon. 

Når noe skjer, må grensene mellom leverandørene forsvinne som hindringer for samarbeid. Informasjon må kunne deles, observasjoner må sees i sammenheng, og tiltak må koordineres. Samtidig må ansvarsfordelingen være tydelig: Hvem leder hendelsen, hvem beslutter tiltak, og hvem gjennomfører dem? 

Et angrep kan starte med en identitet og berøre både klienter, skytjenester og forretningskritiske systemer. Dersom hver leverandør bare undersøker sin egen del, kan det ta lengre tid å forstå omfanget. 

En SOC kan bidra med å etablere et samlet situasjonsbilde og koordinere sikkerhetsfaglig oppfølging dersom dette inngår i oppdraget. Ledelsen av hendelsen og myndigheten til å gjennomføre tiltak må være avklart på forhånd. 

Det bør også finnes en alternativ kontaktvei dersom dere mistenker at leverandørens vanlige kontoer eller e-post er kompromittert. 

Regelverket understreker betydningen av leverandørsikkerhet 

NIS2 stiller krav til håndtering av leverandørkjederisiko for virksomheter som omfattes av regelverket. 

For norske virksomheter er det viktig å skille mellom NIS2 og kravene som følger av norsk regelverk. Digitalsikkerhetsloven trådte i kraft 1. oktober 2025 og gjennomfører NIS1. Hvilke plikter virksomheten har, må vurderes ut fra regelverket den faktisk omfattes av.  

Uavhengig av lovkrav er den praktiske oppgaven den samme: Forstå avhengighetene, redusere unødvendig tilgang og være forberedt på å håndtere konsekvensene av en hendelse. 

Begynn med én kritisk leverandør 

Ingen virksomhet kan kontrollere sikkerheten hos alle leverandører fullt ut. Men dere kan redusere eksponeringen og forbedre evnen til å handle dersom noe skjer, om angrepet kommer gjennom leverandøren din.

Velg én kritisk leverandør. Finn ut hvilke tilganger og data leverandøren har, hva dere kan se i egne logger, og hvem som kan begrense tilgangen ved mistanke om misbruk. 

Test deretter kontakt- og beslutningsveien sammen med leverandøren. Kan dere få tak i riktig person, avklare hva som er berørt og beslutte tiltak raskt nok? 

Det gir et konkret utgangspunkt for å gjøre leverandørsikkerhet til en del av den daglige driften, og for å beskytte både samarbeidet og verdiene det er satt til å ivareta. 

Forfatter