ICT Security Policy
IKT-sikkerhetspolicy — Drop
Dokument-ID: IKT-SEC-DROP-001 Versjon: 1.0 Dato: 12. februar 2026 Eier: ALAI Holding AS, org.nr. 932 516 136 Klassifisering: Intern Gjelder for: Alle systemer, ansatte og leverandører tilknyttet Drop-tjenesten Regulatorisk grunnlag: DORA (EU) 2022/2554, IKT-forskriften, GDPR
1. Innledning
1.1 Formål
Denne policyen etablerer rammeverket for IKT-sikkerhet i Drop-tjenesten. Policyen sikrer at ALAI Holding AS oppfyller kravene i Digital Operational Resilience Act (DORA), forordning (EU) 2022/2554, samt Finanstilsynets IKT-forskrift og øvrig relevant regulering.
1.2 Virkeområde
Policyen gjelder for:
- Alle IKT-systemer som understøtter Drop-tjenesten
- Alle ansatte, konsulenter og tredjepartsleverandører med tilgang til Drop-systemer
- All behandling av data i Drop-tjenestens infrastruktur
- Open Banking-integrasjoner (PSD2 PISP/AISP)
- BankID-integrasjon
1.3 Regulatorisk bakgrunn
| Regulering | Relevante artikler | Beskrivelse |
|---|---|---|
| DORA (EU) 2022/2554 | Art. 5-16 | IKT-risikostyring |
| DORA (EU) 2022/2554 | Art. 17-23 | IKT-relaterte hendelser |
| DORA (EU) 2022/2554 | Art. 24-27 | Digital operasjonell resiliens-testing |
| DORA (EU) 2022/2554 | Art. 28-30 | IKT-tredjepartsrisiko |
| GDPR (EU) 2016/679 | Art. 32 | Sikkerhet ved behandling |
| IKT-forskriften | Hele | Finanstilsynets krav til IKT |
| PSD2 (EU) 2015/2366 | Art. 95-98 | Sikkerhet ved betalingstjenester |
2. IKT-styring og organisering — DORA art. 5
2.1 Ledelsesansvar
Selskapets ledelse har det overordnede ansvaret for IKT-risikostyring, jf. DORA artikkel 5(2). Dette innebærer:
- Godkjenning av IKT-sikkerhetspolicy og vesentlige endringer
- Allokering av tilstrekkelige ressurser til IKT-sikkerhet
- Regelmessig gjennomgang av IKT-risikostatus (minimum kvartalsvis)
- Gjennomføring av opplæring i IKT-sikkerhet (minimum årlig)
2.2 Organisering
| Rolle | Ansvar |
|---|---|
| Daglig leder | Overordnet ansvar for IKT-sikkerhet |
| IKT-sikkerhetsansvarlig (CISO) | Operativt ansvar for sikkerhetspolicy og -tiltak |
| Personvernombud (DPO) | Personvernrelatert IKT-sikkerhet |
| Driftsteam | Implementering og vedlikehold av sikkerhetstiltak |
| Utviklingsteam | Sikker utvikling (DevSecOps) |
2.3 Rapportering
- Kvartalsvis IKT-sikkerhetsrapport til styret
- Umiddelbar eskalering av alvorlige hendelser til daglig leder
- Årlig risikovurdering presentert for styret
3. IKT-risikostyringsrammeverk — DORA art. 6
3.1 Rammeverk
IKT-risikostyring følger et strukturert rammeverk basert på:
- Identifisere: Kartlegge IKT-eiendeler, trusler og sårbarheter
- Beskytte: Implementere tiltak for å redusere risiko
- Oppdage: Overvåke og detektere sikkerhetshendelser
- Reagere: Håndtere hendelser effektivt
- Gjenopprette: Gjenopprette normal drift etter hendelser
3.2 Risikovurdering
- Frekvens: Minimum årlig, samt ved vesentlige endringer
- Metodikk: Sannsynlighet × konsekvens (4×4-matrise)
- Omfang: Alle IKT-systemer, tredjepartsleverandører og prosesser
- Dokumentasjon: Risikoregister vedlikeholdes løpende
3.3 Risikoakseptkriterier
| Risikonivå | Handling |
|---|---|
| Lav (1-4) | Aksepteres, overvåkes |
| Middels (5-8) | Tiltak planlegges innen 90 dager |
| Høy (9-12) | Tiltak implementeres innen 30 dager |
| Kritisk (13-16) | Umiddelbar handling, eskalering til ledelse |
4. IKT-systemer og -eiendeler — DORA art. 7-8
4.1 Eiendelsregister
Vi vedlikeholder et komplett register over alle IKT-eiendeler, jf. DORA artikkel 8, inkludert:
- Programvare og versjoner
- Maskinvare og infrastruktur
- Nettverkskomponenter
- Datalagre og databaser
- Tredjepartssystemer og -integrasjoner
4.2 Klassifisering
Alle IKT-eiendeler klassifiseres etter kritikalitet:
| Klasse | Beskrivelse | Eksempler |
|---|---|---|
| Kritisk | Tjenesten fungerer ikke uten | Betalingsmotor, BankID-integrasjon, database |
| Viktig | Vesentlig funksjonalitet påvirkes | Kundeservicesystem, rapportering |
| Standard | Begrenset påvirkning ved utilgjengelighet | Intern kommunikasjon, utviklingsmiljø |
4.3 Konfigurasjons- og endringsstyring
- Alle endringer i produksjonsmiljøet gjennomgår formell endringsprosess
- Endringer risikovurderes og godkjennes før implementering
- Alle konfigurasjoner versjoneres og dokumenteres
- Rollback-plan kreves for alle endringer
5. Tilgangskontroll — DORA art. 9(4)
5.1 Tilgangsprinsipper
- Minste privilegium (Least Privilege): Brukere tildeles kun nødvendig tilgang
- Need-to-know: Tilgang til data begrenses basert på tjenstlig behov
- Rollebasert tilgangskontroll (RBAC): Tilgang styres gjennom definerte roller
- Segregering av oppgaver (SoD): Kritiske funksjoner fordeles på flere personer
5.2 Brukerkontoer
| Type | Krav |
|---|---|
| Standardbrukere | Unik bruker-ID, MFA påkrevd |
| Administratorer | Egen admin-konto, MFA påkrevd, tidsbegrenset tilgang |
| Systemkontoer | Ingen interaktiv pålogging, API-nøkler med rotasjon |
| Tredjeparter | Tidsbegrenset tilgang, MFA påkrevd, godkjenning fra CISO |
5.3 Multifaktorautentisering (MFA)
MFA er påkrevd for:
- Alle administrative tilganger
- Tilgang til produksjonsdata
- VPN-tilkobling
- Koderepository og CI/CD-pipeline
- Skyinfrastrukturens administrasjonsgrensesnitt
5.4 Tilgangsgjennomgang
- Kvartalsvise gjennomganger av alle tilganger
- Umiddelbar deaktivering ved endret roller eller avsluttet arbeidsforhold
- Årlig resertifisering av alle privilegerte tilganger
6. Kryptering — DORA art. 9(4)(d)
6.1 Data i transitt
| Protokoll | Minimumskrav | Bruksområde |
|---|---|---|
| TLS | Versjon 1.3 (TLS 1.2 kun for legacy-integrasjoner) | All ekstern kommunikasjon |
| mTLS | TLS 1.3 med gjensidig sertifikatautentisering | Interservice-kommunikasjon |
| HTTPS | TLS 1.3 | Web-API-er og brukergrensesnitt |
6.2 Data i hvile
| Datakategori | Krypteringsmetode | Nøkkelhåndtering |
|---|---|---|
| Personopplysninger | AES-256-GCM | HSM-beskyttede nøkler |
| Fødselsnummer | AES-256-GCM + applikasjonsnivå | Separat nøkkelpar, HSM |
| Transaksjonsdata | AES-256-GCM | HSM-beskyttede nøkler |
| Logger | AES-256-GCM | Rotasjon hver 90. dag |
| Sikkerhetskopier | AES-256-GCM | Offline nøkkelkopi i safe |
6.3 Nøkkelhåndtering
- Nøkler genereres i Hardware Security Module (HSM)
- Nøkkelrotasjon minimum hver 12. måned (90 dager for logger)
- Separasjon av nøkler per miljø (utvikling, test, produksjon)
- Nøkler for kryptering av fødselsnummer håndteres separat
- Nødprosedyre for nøkkelkompromittering dokumentert
7. Applikasjonssikkerhet — OWASP
7.1 Sikker utviklingslivssyklus (SSDLC)
Alle utviklingsaktiviteter følger en sikker utviklingslivssyklus:
- Kravfase: Sikkerhets- og personvernkrav defineres
- Design: Trusselmodellering (STRIDE) gjennomføres
- Implementering: Sikre kodestandarder, code review
- Testing: Sikkerhetstesting (SAST, DAST, avhengighetsskanning)
- Lansering: Penetrasjonstesting før produksjonssetting
- Drift: Løpende overvåking og sårbarhetshåndtering
7.2 OWASP Top 10 — tiltak
| OWASP-risiko | Tiltak |
|---|---|
| A01: Broken Access Control | RBAC, autorisasjonskontroll på API-nivå, funksjonsnivåtesting |
| A02: Cryptographic Failures | TLS 1.3, AES-256, HSM, ingen hardkodede hemmeligheter |
| A03: Injection | Parametriserte SQL-spørringer, input-validering, ORM |
| A04: Insecure Design | Trusselmodellering, sikre designmønstre, minste privilegium |
| A05: Security Misconfiguration | Automatisert konfigurasjonskontroll, hardening, ingen standardpassord |
| A06: Vulnerable Components | Avhengighetsskanning (SCA), automatiserte oppdateringer, SBOM |
| A07: Authentication Failures | BankID (brukere), MFA (ansatte), kontosperring ved mislykkede forsøk |
| A08: Software and Data Integrity | Signerte builds, CI/CD-integritetskontroll, code review |
| A09: Logging and Monitoring Failures | Sentralisert logging, SIEM, varsling, revisjonslogger |
| A10: Server-Side Request Forgery | Input-validering, nettverkssegmentering, egress-filtrering |
7.3 API-sikkerhet
Gitt at Drop er en API-drevet tjeneste med Open Banking-integrasjoner:
- OAuth 2.0 / OpenID Connect for autentisering og autorisasjon
- Rate limiting per bruker og per IP
- Input-validering og schema-verifisering på alle endepunkter
- API-versjonering med deprekeringspolicy
- API-gateway med WAF-funksjonalitet
8. Nettverkssikkerhet
8.1 Nettverksarkitektur
- Segmentering: Produksjon, test og utvikling er fullstendig isolert
- DMZ: Offentlig tilgjengelige tjenester plasseres i DMZ
- Mikrosegmentering: Tjenester kommuniserer kun med autoriserte tjenester
- Egress-filtrering: Utgående trafikk begrenses til godkjente destinasjoner
8.2 Brannmur og filtrering
- Web Application Firewall (WAF) foran alle offentlige endepunkter
- Nettverksbrannmur med default-deny-policy
- IDS/IPS for deteksjon og forebygging av inntrengning
- DDoS-beskyttelse på infrastrukturnivå
8.3 Overvåking
- Sentralisert logginnsamling fra alle nettverkskomponenter
- Netflow-analyse for anomalideteksjon
- DNS-overvåking for ondsinnet trafikk
9. Hendelsesdeteksjon og -overvåking — DORA art. 10
9.1 Overvåkingssystem
- SIEM (Security Information and Event Management): Sentralisert hendelseskorrelasjon
- Logginnsamling: All IKT-aktivitet logges sentralt
- Automatisert varsling: Definerte terskelverdier for automatisk varsling
- Anomalideteksjon: Maskinlæring for identifisering av uvanlig atferd
9.2 Loggkrav
| Loggkategori | Oppbevaringstid | Beskyttelse |
|---|---|---|
| Autentiseringslogger | 12 måneder | Kryptert, skrivebeskyttet |
| Transaksjonslogger | 5 år | Kryptert, skrivebeskyttet |
| Systemlogger | 6 måneder | Kryptert |
| Sikkerhetslogger | 24 måneder | Kryptert, skrivebeskyttet |
| Tilgangslogger | 12 måneder | Kryptert, skrivebeskyttet |
9.3 Hendelsesrespons
Se separat dokument: hendelseshaandtering.md for fullstendig hendelsesresponsplan.
10. Sårbarhetshåndtering — DORA art. 9(4)(e)
10.1 Sårbarhetsskanning
| Type | Frekvens | Omfang |
|---|---|---|
| Automatisert skanning | Daglig | Alle produksjonssystemer |
| Avhengighetsskanning (SCA) | Ved hver build | All kildekode |
| Statisk kodeanalyse (SAST) | Ved hver pull request | All ny kode |
| Dynamisk analyse (DAST) | Ukentlig | Alle offentlige endepunkter |
10.2 Sårbarhetshåndtering
| Alvorlighetsgrad (CVSS) | Frist for utbedring |
|---|---|
| Kritisk (9.0-10.0) | 24 timer |
| Høy (7.0-8.9) | 7 dager |
| Middels (4.0-6.9) | 30 dager |
| Lav (0.1-3.9) | 90 dager |
10.3 Patchhåndtering
- Sikkerhetsoppdateringer vurderes og implementeres innenfor angitte frister
- Nødpatcher kan deployeres utenfor normal endringsprosess med etterfølgende godkjenning
- All programvare holdes oppdatert med siste stabile versjon
- End-of-life-programvare erstattes innen 6 måneder etter annonsering
11. Penetrasjonstesting — DORA art. 24-27
11.1 Testprogram
| Testtype | Frekvens | Gjennomfører |
|---|---|---|
| Ekstern penetrasjonstest | Årlig | Uavhengig tredjepart |
| Intern penetrasjonstest | Årlig | Uavhengig tredjepart |
| Red team-øvelse | Hvert 3. år (TLPT) | Kvalifisert leverandør jf. DORA art. 26 |
| Applikasjonssikkerhetstest | Ved vesentlige endringer | Intern/ekstern |
| Social engineering-test | Årlig | Uavhengig tredjepart |
11.2 TLPT (Threat-Led Penetration Testing) — DORA art. 26
I henhold til DORA artikkel 26 kan Finanstilsynet kreve at vi gjennomfører TLPT. Vi er forberedt på:
- Engasjement av kvalifisert TLPT-leverandør
- Scenariobasert testing basert på reelle trusseletterretninger
- Involvering av kritiske IKT-tredjepartsleverandører
- Rapportering til Finanstilsynet
11.3 Oppfølging av funn
- Alle funn logges i sårbarhetsstyringssystemet
- Funn prioriteres etter alvorlighetsgrad
- Utbedringsplan utarbeides innen 5 virkedager
- Retest gjennomføres etter utbedring
- Ledelsen informeres om kritiske funn umiddelbart
12. Sikkerhetskopier og gjenoppretting — DORA art. 12
12.1 Sikkerhetskopieringsstrategi
| Dataklasse | Frekvens | Oppbevaring | Lokasjon |
|---|---|---|---|
| Database (produksjon) | Kontinuerlig (WAL) + daglig full | 30 dager | Geografisk adskilt, innenfor EØS |
| Konfigurasjon | Ved endring | 90 dager | Versjonskontroll + kryptert backup |
| Logger | Daglig | Iht. loggpolicy | Separat logginfrastruktur |
| Krypteringsnøkler | Ved endring | Permanent | Offline, i safe |
12.2 Gjenopprettingstesting
- Frekvens: Minimum halvårlig
- Omfang: Fullstendig gjenoppretting av kritiske systemer
- Dokumentasjon: Testresultater dokumenteres og gjennomgås
- Forbedring: Funn fra testing fører til oppdatert prosedyre
12.3 RTO og RPO
Se beredskapsplan.md for detaljerte RTO/RPO-krav per system.
13. Fysisk sikkerhet
13.1 Datasentre
- All infrastruktur er hostet i sertifiserte datasentre (minimum ISO 27001, SOC 2 Type II)
- Datasentre lokalisert innenfor EØS
- Redundant strømforsyning (UPS + dieselgenerator)
- Brannslukkingssystemer
- Adgangskontroll med biometri og logging
13.2 Utviklingsmiljø
- Produksjonsdata benyttes aldri i utviklings- eller testmiljøer
- Syntetiske testdata genereres for testing
- Utviklingsmaskiner har diskkryptering og MFA
14. Opplæring og bevissthet — DORA art. 13
14.1 Obligatorisk opplæring
| Målgruppe | Innhold | Frekvens |
|---|---|---|
| Alle ansatte | Generell IKT-sikkerhet, phishing, passord | Årlig |
| Utviklere | Sikker koding, OWASP, code review | Halvårlig |
| Drift | Hendelseshåndtering, herding, overvåking | Halvårlig |
| Ledelse | IKT-risikostyring, regulatoriske krav | Årlig |
14.2 Phishing-simulering
- Kvartalsvise phishing-simuleringer for alle ansatte
- Individuelle resultater brukes til målrettet opplæring
- Resultater rapporteres til ledelsen (aggregert)
15. IKT-tredjepartsrisiko — DORA art. 28-30
15.1 Leverandørstyring
Se separat dokument: utkontraktering-policy.md for detaljert leverandørstyringspolicy.
15.2 Kritiske IKT-leverandører
Kritiske IKT-tredjepartsleverandører identifiseres og underlegges forsterkede krav, jf. DORA artikkel 28:
- Årlig risikovurdering
- Rett til revisjon og inspeksjon
- Exit-strategi og overgangsplan
- Rapportering av vesentlige hendelser
- Overholdelse av DORA-krav
16. Kontinuitetsplanlegging — DORA art. 11
Se separat dokument: beredskapsplan.md for detaljert kontinuitetsplan.
Denne IKT-sikkerhetspolicyen understøtter kontinuitetsplanlegging ved å sikre:
- Høy tilgjengelighet gjennom redundans
- Rask gjenoppretting gjennom testede prosedyrer
- Begrenset konsekvens gjennom segmentering og isolasjon
17. Revisjon og oppdatering
17.1 Gjennomgang
- Årlig: Full gjennomgang av policyen
- Ved vesentlige endringer: Endringer i teknologi, tjenester eller regulering
- Etter hendelser: Relevant revisjon etter sikkerhetshendelser
- Etter penetrasjonstesting: Oppdatering basert på funn
17.2 Godkjenningsprosess
| Endring | Godkjenner |
|---|---|
| Redaksjonell | CISO |
| Vesentlig | Daglig leder |
| Prinsipiell | Styret |
17.3 Versjonshistorikk
| Versjon | Dato | Endring | Godkjent av |
|---|---|---|---|
| 1.0 | 12.02.2026 | Opprinnelig dokument | ____________ |
18. Referanser
- DORA — Forordning (EU) 2022/2554 om digital operasjonell motstandsdyktighet
- GDPR — Forordning (EU) 2016/679 om personvern
- PSD2 — Direktiv (EU) 2015/2366 om betalingstjenester
- ISO 27001:2022 — Informasjonssikkerhetsstyring
- NIST Cybersecurity Framework 2.0
- OWASP Top 10 (2021)
- Finanstilsynets IKT-forskrift
- Hvitvaskingsloven (LOV-2018-06-01-23)
Denne IKT-sikkerhetspolicyen er eid av CISO og godkjent av styret i ALAI Holding AS.