Slik kan virksomheter håndtere KI-risiko

1. Fremskynde patch- og oppdateringssykluser

Tiden mellom tilgjengelig sikkerhetsoppdatering og potensiell utnyttelse forventes å bli kortere. Rask testing og utrulling blir derfor enda viktigere. 

Virksomhetene bør særlig: 

• redusere etterslep på kjente sårbarheter 
• etablere egne prosedyrer for hasteoppdateringer 
• teste nødprosedyrer for rask endring i produksjonsmiljøer 
• vurdere midlertidige kompenserende tiltak når patching ikke kan gjennomføres raskt 
• fjerne eller isolere systemer som ikke lenger støttes av leverandør 

Patching alene er ikke nok. Virksomhetene bør også vurdere herding, nettverkssegmentering, bedre endepunktbeskyttelse, bot-beskyttelse, WAF-regler, virtual patching og strengere eksponeringskontroll.

2. Gjennomgå prosesser for sårbarhetshåndtering 

Tradisjonell prioritering basert på CVSS-score alene er ikke tilstrekkelig i et mer automatisert trusselbilde. Lavere graderte sårbarheter kan bli alvorlige dersom de er eksponert mot internett, enkle å utnytte eller gir tilgang til kritiske systemer. 

Virksomhetene bør derfor prioritere sårbarheter ut fra: 

• faktisk utnyttbarhet 
• eksponering mot internett
• tilgang til kritiske tjenester
• forretningsmessig konsekvens
• mulighet for kjeding med andre svakheter
• om sårbarheten gjelder identitet, privilegier eller fjernkjøring av kode 

Det bør også etableres prosesser for løpende reprioritering. Når trusselbildet endrer seg raskt, må også prioriteringene kunne endres raskt.

3. Styrke dialogen med kritiske tredjepartsleverandører 

Finansnæringen er avhengig av leverandører av skytjenester, kjerneinfrastruktur, sikkerhetsverktøy, programvare, driftsmiljøer og databehandling. Angrep kan bevege seg på tvers av plattformer, testmiljøer, åpne tjenester og leverandørkjeder. 

Virksomhetene bør sikre at kritiske leverandører kan svare på: 

• hvilke patchefrister som gjelder for kritiske sårbarheter 
• hvordan leverandøren håndterer KI-relaterte trusler 
• om leverandøren bruker KI i leveransen av tjenesten 
• hvilke avhengigheter leverandøren har til underleverandører 
• hvordan hendelser varsles 
• hvordan roller og ansvar er definert ved alvorlige sårbarheter eller innbrudd 
• hvilke beredskapsplaner som gjelder dersom leverandørens KI-systemer, utviklingsmiljøer eller produksjonsmiljøer rammes 

Dette er også i tråd med anbefalingene om å styrke leverandøroppfølging, tydeliggjøre roller og ansvar, og inkludere relevante krav i kontrakter og tjenestenivåavtaler. 

4. Teste og oppdatere beredskaps- og kontinuitetsplaner 

Kortere varslingstid og raskere eskalering stiller økte krav til samspill mellom IKT-drift, sikkerhet, kommunikasjon, juridisk, forretning og ledelse. Beredskapsplaner bør testes mot scenarioer der en autonom aktør beveger seg raskt gjennom flere systemer, utnytter legitime tilganger og skaper usikkerhet om omfang og konsekvens. 

Virksomhetene bør blant annet teste: 

• rask rotasjon av nøkler, token og hemmeligheter 
• isolering av kompromitterte miljøer 
• beslutninger om stans av tjenester 
• håndtering av hendelser hos leverandører 
• hendelser der KI-agenter eller automatiserte systemer er involvert 
• kommunikasjon med kunder, myndigheter og samarbeidspartnere 
• evnen til å analysere store mengder logger raskt 

Flere av de internasjonale rådene peker på behovet for å inkludere komplekse driftsavbrudd, leverandørsvikt og KI-spesifikke hendelser i beredskaps- og kontinuitetsarbeidet. 

5. Følge utviklingen på tvers av sektorer og myndigheter 

KI-risiko er tverrsektoriell. Finansnæringen er avhengig av kraft, telekom, sky, digitale identiteter, betalingsinfrastruktur og offentlige tjenester. Derfor må utviklingen følges nasjonalt og internasjonalt. 

Finans Norge vil fortsette å følge utviklingen gjennom nasjonale og internasjonale fora, og bidra til informasjonsdeling mellom finansnæringen, myndigheter og andre samfunnskritiske sektorer. Økt deling av erfaringer, indikatorer, sårbarheter, læringspunkter og tiltak blir viktig når trusselbildet endrer seg raskt. 

Dette gjelder også innad i virksomhetene. KI-risiko må ikke behandles som et isolert IT-spørsmål. Ledelse, risiko, compliance, juridisk, sikkerhet, utviklingsmiljøer og forretningsområder må ha en felles forståelse av hvordan KI påvirker virksomhetens risiko. 

6. Sikre KI-agenter, automatisering og ikke-menneskelige identiteter 

KI-agenter bør behandles som privilegerte aktører. Når en agent får tilgang til verktøy, data, kode, systemer eller internett, må virksomheten vite hva agenten kan gjøre, hvilke tilganger den har, og hvordan handlingene kan stoppes. Sikkerhetsgrenser, sandkasser og testmiljøer må være robuste også når systemet aktivt forsøker å løse en oppgave på uforutsette måter. 

Virksomhetene bør: 

• bruke minste privilegium for KI-agenter og automatiserte arbeidsflyter 
• begrense hvilke verktøy og data en agent kan bruke 
• skille tydelig mellom testmiljøer og produksjonsmiljøer 
• logge alle handlinger som utføres av agenter 
• etablere godkjenningstrinn for handlinger med høy risiko 
• bruke tidsbegrensede tilganger og just in time-prinsipper 
• ha mulighet til å stanse eller rulle tilbake agenthandlinger 
• teste for prompt injection, datalekkasje, verktøymisbruk og uønsket autonomi 
• stille krav til leverandører om hvordan de sikrer egne KI-agenter 

Dette bygger også på anbefalingene om kontroll av KI-agenters autonomi og tilgang, herunder IAM, PAM, minste privilegium, avgrensede tillatelser og hendelsesspesifikke responstiltak.

7. Få bedre kontroll på programvare, åpen kildekode og utviklingsmiljøer 

Moderne finansielle tjenester bygger på store mengder kode, biblioteker, pakker, containere, API-er og utviklerverktøy. Den utbredte bruken av åpen kildekode gir stor verdi, men skaper også sårbarheter dersom virksomheten ikke har oversikt over avhengigheter og indirekte avhengigheter. 

Virksomhetene bør: 

• ha oppdaterte oversikter over programvarekomponenter 
• bruke software composition analysis i utvikling og testing 
• vurdere kontrollert forsinkelse før nye åpne komponenter tas i bruk 
• overvåke kjente sårbarheter i direkte og indirekte avhengigheter 
• sikre utviklingsplattformer, kodebaser, byggemiljøer og artefaktregistre
• redusere bruk av langlivede hemmeligheter i utviklingsmiljøer
• styrke DevSecOps og sikkerhet i hele utviklingsløpet
• teste hvordan en angriper kan bevege seg fra utviklingsmiljø til produksjon 

8. Ledelsen må ta eierskap

KI-relaterte cybertrusler må håndteres som en virksomhetsrisiko. Det innebærer at styre og ledelse må forstå hvordan økt automatisering, raskere sårbarhetsutnyttelse, KI-agenter og leverandøravhengigheter påvirker virksomhetens risikobilde.

Finans Norge mener ledelsen bør sikre: 

• tydelig eierskap til KI-relatert cyberrisiko 
• at scenarioer inngår i virksomhetens risikotoleranse og risikovurderinger 
• at sikkerhetsmål og måleparametere inngår i styringen 
• at nødvendige ressurser er tilgjengelige for sårbarhetshåndtering og beredskap 
• at sikkerhet, utvikling, drift og forretning jobber mot felles prioriteringer