Styring af browserudvidelser for NIS2, DORA og GDPR

Maria, CISO i en hurtigt voksende fintech-virksomhed, mente, at DORA-forhåndsvurderingen forløb godt. Hendes team havde forberedt IKT-tredjepartsregisteret, kritiske SaaS-kontrakter, dokumentation for leverandør-due diligence, beslutninger om risikoaccept og rapporteringspakken til ledelsesorganet.

Så stillede revisoren et spørgsmål, som ingen havde forberedt sig på.

“Kan I vise os jeres styringsproces for browserudvidelser?”

Spørgsmålet kom fra en gennemgang af endepunkter med en finansanalytiker. Under en skærmdeling bemærkede revisoren en tredjepartsudvidelse til produktivitet i analytikerens browser. Den så harmløs ud, men en hurtig søgning viste, at udvikleren havde været ramt af en kompromittering af forsyningskæden tre måneder tidligere. Den kompromitterede udvidelse var blevet brugt til at opsnappe sessionstokens til større SaaS-platforme.

Fintech-virksomheden havde stærke politikker mod uautoriseret software. Den havde EDR, MFA, CASB, SaaS-logfiler og et ISMS tilpasset ISO/IEC 27001. Men ingen havde behandlet browseren som en administreret softwareplatform. Ingen havde registreret udvidelser. Ingen havde godkendt deres tilladelser. Ingen havde kontrolleret, om udviklere af udvidelser var leverandører. Ingen havde kortlagt udvidelsesaktivitet til bevismateriale for DORA, NIS2 eller GDPR.

Én enkelt browserudvidelse havde forvandlet et tilsyneladende efterlevende endepunkt til en mulig bagdør til finansielle systemer, kundedata og regulerede arbejdsgange.

Det er styringsproblemet for browserudvidelser i 2026. Browseren er ikke længere blot et vindue til internettet. Det er her, medarbejdere autentificerer sig, godkender betalinger, tilgår CRM-registre, behandler personoplysninger, administrerer cloudinfrastruktur og interagerer med kritiske SaaS-platforme. Udvidelser er ikke længere kosmetiske tilføjelser. De er tredjepartskode, der kører i det mest følsomme lag af moderne arbejde.

For CISO’er, compliance-ansvarlige, databeskyttelsesrådgivere og IKT-risikoejere ligger uadministrerede udvidelser i krydsfeltet mellem endepunktssikkerhed, shadow IT, leverandørrisiko, ændringsstyring, sårbarhedsstyring og ansvarlighed for databeskyttelse. ISO/IEC 27001:2022 giver organisationer strukturen til at styre denne risiko. NIS2, DORA og GDPR skaber det regulatoriske pres for at dokumentere styringen.

Browserudvidelser er software, leverandører og databehandlere

De fleste organisationer har allerede lært at administrere laptops, mobile enheder, servere, SaaS-applikationer, cloudinfrastruktur og privilegerede konti. Browserudvidelser falder ofte mellem disse programmer.

Sikkerhedsteams ser dem som en browserindstilling. Indkøb ser dem ikke, fordi der ikke underskrives en kontrakt. Jura ser dem ikke, fordi der ikke oprettes en leverandøronboarding. Databeskyttelsesteams ser dem ikke, fordi udvidelsen installeres af en bruger og ikke udrulles som en officiel applikation. Alligevel kan udvidelsen anmode om tilladelse til at læse og ændre data på alle websites, tilgå udklipsholderens indhold, indsamle metadata fra sider, administrere downloads, injicere scripts eller kommunikere med en ekstern backend.

Det betyder, at en browserudvidelse kan være alt dette på én gang:

[ZB] Zenith Blueprint: En auditors 30-trins køreplan indfanger kerneproblemet i sin ISO/IEC 27002:2022-vejledning til kontrol 8.19. Den advarer om, at “selv velmenende medarbejdere kan installere værktøjer for at ‘få arbejdet gjort hurtigere’, en browserudvidelse, et kodebibliotek eller en filoverførselsapp, uden at være klar over, at de netop har introduceret en bagdør, en upatchet afhængighed eller en vektor for dataeksfiltrering.”

Den sætning bør behandles som en risikoudtalelse på bestyrelsesniveau. De medarbejdere, der installerer risikofyldte udvidelser, forsøger normalt ikke at omgå sikkerheden. De forsøger at øge brugervenlighed og effektivitet. Styringssvigtet opstår, når organisationen ikke stiller en sikker proces til anmodning, godkendelse, udrulning og overvågning til rådighed.

Hvorfor NIS2, DORA og GDPR gør blindvinklen presserende

Risikoen ved browserudvidelser har eksisteret i årevis, men den regulatoriske kontekst har ændret sig. I 2026 forventes organisationer ikke kun at dokumentere, at kontroller findes, men også at de er risikobaserede, integrerede, overvågede og understøttet af bevismateriale.

NIS2 hæver forventningerne til cyberhygiejne og sikkerhed i forsyningskæden. DORA kræver, at finansielle enheder styrer IKT-risiko på tværs af interne afhængigheder og tredjepartsafhængigheder. GDPR kræver, at dataansvarlige og databehandlere dokumenterer behandlingssikkerhed, ansvarlighed og databeskyttelse gennem design. Uadministrerede udvidelser kan undergrave alle tre.

Læringen er enkel. En browserudvidelse er ikke for lille til at være relevant. Hvis den kan berøre regulerede data, autentificerede sessioner, finansielle arbejdsgange eller kritiske SaaS-tjenester, skal den styres.

Brug ISO/IEC 27001:2022 som driftsmodel

ISO/IEC 27001:2022 er effektiv til styring af browserudvidelser, fordi den ikke kræver en særskilt compliance-silo. Den gør det muligt for organisationer at udvide eksisterende ISMS-processer til browserlaget.

Den praktiske kontrolmodel er bygget op omkring otte ISO/IEC 27001:2022 Annex A-kontroller:

[ZC] Zenith Controls: Vejledningen til tværgående efterlevelse er særligt nyttig, fordi den forklarer, hvordan ISO/IEC 27001-kontroller revideres, og hvordan de understøtter bevismateriale på tværs af rammeværker. For kontrol 8.19 forklarer Zenith Controls: Vejledningen til tværgående efterlevelse, at revisorer vil “følge arbejdsgangen: fra anmodning til test, godkendelse og implementering.” Det er præcis sådan, styring af udvidelser bør designes.

Hvis en revisor finder en udvidelse, der ikke står på den godkendte liste, ikke er dokumenteret i ændringsregistreringer og ikke er risikovurderet, er problemet ikke længere blot en browserindstilling. Det bliver bevismateriale for svag kontrol med softwareinstallation, svag styring af endepunkter og muligt svigt i leverandørrisikostyringen.

Trin 1: Kortlæg udvidelseslandskabet

Det første kontrolsvigt i Marias fintech-virksomhed var manglende synlighed. Hendes team vidste ikke, hvilke udvidelser der var installeret, hvem der havde installeret dem, hvilke tilladelser de anmodede om, eller om de oprettede forbindelse til eksterne tjenester.

Kortlægningen bør omfatte alle administrerede browsere, profiler, brugere, enheder og operativsystemer. Den bør identificere udvidelsens navn, unikke ID, version, udgiver, installationskilde, tilladelsessæt, installationsdato, opdateringsstatus, antal brugere, forretningsejer, og om udvidelsen er tvangsinstalleret, brugerinstalleret, sideloaded eller blokeret.

Kontrol 8.1, Brugeres endepunktsenheder, er ankeret. Vejledningen i Zenith Blueprint: En auditors 30-trins køreplan til kontrol 8.1 angiver, at brugeres endepunktsenheder “skal forstærkes, overvåges og kontrolleres.” Det krav omfatter naturligt browseren, fordi browseren nu er den primære brugergrænseflade på endepunkter til SaaS- og cloudarbejde.

Kontrol 5.23 gælder også, når udvidelser opretter forbindelse til cloudtjenester. Zenith Blueprint: En auditors 30-trins køreplan beskriver denne kontrol som en respons på shadow IT, hvor brugere tager ikke-godkendte tjenester i brug uden styring. En browserudvidelse, der sender indhold til en ukendt hosted backend, er ibrugtagning af en cloudtjeneste, selv om ingen i indkøb har godkendt den.

Et modent kortlægningsoutput bør klassificere hver udvidelse i én af fem tilstande:

Kortlægning må ikke være et engangsprojekt. Udvidelser opdateres ofte, udgivere skifter ejerskab, tilladelser udvides, og butikker fjerner ondsindede pakker, efter at brugere allerede har installeret dem. Fortegnelsen skal ajourføres løbende eller gentages ofte nok til at understøtte sårbarhedsstyring og revisionsbevis.

Trin 2: Gør acceptabel brug eksplicit

Når udvidelser er synlige, skal brugerforventninger være klare. Mange organisationer har allerede politikformuleringer, der kan understøtte styring af udvidelser, men de skal anvendes eksplicit på browseren.

[P-EPM] Politik for malwarebeskyttelse af endepunkter - SME angiver, at brugere “ikke må installere uautoriseret software eller plugins, der kan introducere risiko.” Den ene sætning giver sikkerhedsteams et stærkt politikgrundlag for at behandle browserudvidelser som kontrolleret software.

[P03-AUP] P03 Politik for acceptabel brug, som også omtales som virksomhedens Politik for acceptabel brug, forbyder “ikke-godkendte værktøjer: installation eller brug af uautoriseret software, hardware, cloudtjenester eller enheder”. Dette er det brugerrettede fundament. Det omsætter styring af browserudvidelser fra en teknisk præference til et håndhæveligt krav til adfærd og efterlevelse.

En stærk politik for browserudvidelser skal besvare seks praktiske spørgsmål:

Det handler ikke om at forbyde alle nyttige udvidelser. Det handler om at gå fra implicit tillid til eksplicit godkendelse. Nogle udvidelser kan være sikre, nødvendige og forbedre brugervenligheden. Andre kan være unødvendige, overprivilegerede, opgivne eller ondsindede. Styringsprogrammet skal kunne skelne mellem dem.

Trin 3: Håndhæv standard-deny med tilladelsesliste efter undtagelse

Kontrol 8.19, Installation af software på driftssystemer, er den kontrol, der omsætter politik til drift. Browserudvidelser skal ikke behandles anderledes end anden software, blot fordi brugere installerer dem gennem en browserbutik.

Zenith Blueprint: En auditors 30-trins køreplan er direkte på dette punkt: “ingen software installeres, medmindre den er begrundet, autoriseret og sikret.” For browserudvidelser betyder det brug af central browserstyring, endepunktsstyring eller værktøjer til enhedskonfiguration til at håndhæve installationsregler.

Den mest forsvarlige model er standard-deny med tilladelsesliste efter undtagelse:

1. Blokér som standard alle udvidelser for administrerede browsere.
2. Tvangsinstallér kun væsentlige, godkendte virksomhedsudvidelser.
3. Vedligehold en tilladelsesliste for godkendte udvidelser efter brugergruppe, afdeling eller rolle.
4. Blokér sideloadede udvidelser og ikke-betroede installationskilder.
5. Forhindr brugere i at omgå politikker ved at skifte profil eller bruge uadministrerede browsere.
6. Fjern allerede installerede udvidelser, der ikke er godkendt.
7. Gennemgå udvidelsestilladelser og udgiverrisiko før godkendelse.
8. Log tilladte, blokerede, fjernede og ændrede udvidelser.

Nogle organisationer starter med en blødere model på grund af driftsmæssig kompleksitet. De kan først registrere, blokere kendt skadelige udvidelser og derefter indfase tilladelseslister for højrisikogrupper såsom økonomi, engineering, privilegerede administratorer, jura, HR og kundesupport. Det er acceptabelt, hvis der findes en dokumenteret køreplan. Det, der ikke er forsvarligt, er permanent tolerance af ukendt risiko ved udvidelser.

Trin 4: Risikovurdér udvidelser som leverandører og software

En risikovurdering af browserudvidelser bør være enkel nok til at blive brugt i forretningen, men stærk nok til at kunne bestå en revision. Gennemgangen bør kombinere softwarerisiko, leverandørrisiko, cloudrisiko, databeskyttelse og sårbarhedsstyring.

[P-TP] Politik for tredjeparts- og leverandørsikkerhed kræver, at “alle nye leverandører skal gennemgå en dokumenteret sikkerhedsvurdering før kontraktindgåelse.” Ikke alle udviklere af udvidelser kræver fuld leverandøronboarding, men princippet om leverandørrisiko gælder stadig. Hvis en udvikler kan skubbe kodeopdateringer ind i medarbejderes browsere eller behandle organisationsdata gennem en backendtjeneste, har organisationen en tredjepartsafhængighed.

[P-ASR] Politik for krav til applikationssikkerhed - SME understøtter samme krav fra et softwareperspektiv: “Ethvert tredjepartsværktøj, plugin eller eksternt kodebibliotek, der anvendes i en applikation, skal registreres og gennemgås årligt for sikkerhedsmæssig påvirkning og patchstatus.”

Brug følgende risikomodel til at standardisere beslutninger:

En højrisikoudvidelse må ikke godkendes, medmindre der er et kritisk forretningsbehov, dokumenterede kompenserende kontroller og risikoaccept fra øverste ledelse. Eksempler på kompenserende kontroller omfatter begrænsning af brug til en hærdet browserprofil, begrænsning til bestemte URL’er, blokering af dataindtastning i følsomme applikationer, mens udvidelsen er aktiv, brug af DLP-overvågning eller krav om leverandørkontrakt og databehandleraftale.

Trin 5: Integrér databeskyttelses- og GDPR-gennemgang

Styring af browserudvidelser fejler ofte, fordi databeskyttelsesgennemgangen er adskilt fra endepunktsværktøjer. Mange udvidelser kan imidlertid se personoplysninger, der vises i SaaS-applikationer, HR-systemer, supportsager, CRM-registre, e-mail, analyseplatforme og samarbejdsværktøjer.

Efter GDPR Article 5(2) skal organisationen dokumentere ansvarlighed. Efter Article 25 skal den implementere databeskyttelse gennem design og standardindstillinger. Efter Article 32 skal den anvende passende tekniske og organisatoriske foranstaltninger for behandlingssikkerhed. Hvis en udvidelse eksfiltrerer personoplysninger, kan hændelsen blive et brud på persondatasikkerheden efter Article 4(12), hvilket udløser vurdering og muligvis anmeldelsesforpligtelser efter Article 33.

En databeskyttelsesbevidst gennemgang af udvidelser bør stille følgende spørgsmål:

Ikke alle udvidelser kræver en fuld DPIA. Udvidelser med bred sideadgang, AI-behandling, skærmoptagelse, e-mailadgang, CRM-adgang, adgang til HR-data, kundesupportdata eller regulerede finansielle data bør dog udløse en struktureret databeskyttelsesvurdering.

Trin 6: Log og overvåg til revision og hændelseshåndtering

Et styringsprogram for udvidelser uden logfiler kan ikke revideres effektivt. Det svækker også hændelseshåndtering, fordi organisationen ikke kan afgøre, hvornår en udvidelse blev installeret, hvem der brugte den, hvilken version der var til stede, hvornår tilladelser ændrede sig, eller om der forekom et blokeret installationsforsøg.

[P-LM] Lognings- og overvågningspolitik - SME identificerer logfiler for “softwareinstallationer” som et centralt styringskrav. Installation af browserudvidelser er en softwareinstallationshændelse og skal registreres tilsvarende.

Som minimum bør logfiler omfatte:

Disse logfiler bør indgå i overvågningsprocesser efter kontrollerne 8.15 og 8.16. Afhængigt af risiko kan de også sendes til en SIEM-platform, endpoint-platform eller et repository for revisionsbevis. Alarmer bør konfigureres for blokerede højrisikoudvidelser, pludselige stigninger i anmodninger om udvidelser, ændringer i tilladelser for godkendte udvidelser, forsøg på installation fra ikke-officielle kilder og installationsforsøg fra privilegerede brugere.

Overvågning er også en fordel i forhold til NIS2 og DORA. Hændelsesrapportering efter NIS2 Article 23 afhænger af tidlig detektion og konsekvensvurdering. DORA kræver robust håndtering af IKT-hændelser og bevismateriale for robusthed. GDPR-vurdering af brud afhænger af at vide, hvad der skete, hvornår det skete, og hvilke data der kan være berørt.

Hvad revisoren vil se

En revisor bliver sjældent tilfreds med en udtalelse som “vi blokerer risikofyldte udvidelser.” Revisoren vil se bevismateriale for styring. Bevismaterialet skal forbinde politik, risikovurdering, teknisk håndhævelse, overvågning og ledelsesansvar.

Det er her, Zenith Controls: Vejledningen til tværgående efterlevelse bliver værdifuld. Den hjælper organisationer med at vise, hvordan én kontrolaktivitet understøtter flere compliance-forventninger. Én enkelt godkendelsesarbejdsgang for browserudvidelser kan understøtte ISO/IEC 27001 kontrol 8.19, NIS2-cyberhygiejne, DORA IKT-risikostyring og GDPR-ansvarlighed, hvis bevismaterialet opbevares og kortlægges tydeligt.

Krydsreference: ISO/IEC 27001:2022 til NIS2, DORA og GDPR

En praktisk krydsreference hjælper CISO’er med at forklare, hvorfor styring af browserudvidelser ikke er en snæver teknisk kontrol. Det er en compliance-kontrol med bred regulatorisk værdi.

DORA-kortlægningen fortjener særlig opmærksomhed. Nogle revisorer og assessorer vil bruge COBIT-lignende terminologi ved gennemgang af IKT-ændringsstyring. COBIT BAI06 forstås almindeligvis som Managed IT Changes. Hvis browserudvidelser er software, og deres installation ændrer brugerens computermiljø, hører installation af udvidelser hjemme i den samme styrede ændringslogik. Zenith Controls: Vejledningen til tværgående efterlevelse understøtter dette revisionsperspektiv ved at vise, hvordan kontrolbevismateriale fra ISO/IEC 27001 kan genbruges på tværs af compliance-forventninger.

En 90-dages implementeringsplan for styring af browserudvidelser

Organisationer behøver ikke løse alt på én uge. Et praktisk program kan opbygges i faser, især hvis forretningsmæssige forstyrrelser skal håndteres omhyggeligt.

For højrisikoorganisationer, især finansielle enheder under DORA eller væsentlige og vigtige enheder under NIS2, bør den første håndhævelsesfase prioritere brugere med adgang til kritiske systemer, regulerede data, privilegerede administrative konsoller, finansplatforme, kundesupportværktøjer og udviklingsmiljøer.

Budskabet til bestyrelsen

Styring af browserudvidelser bør ikke præsenteres for ledelsen som et browserhærdningsprojekt. Det bør præsenteres som en kontrol over ikke-vurderet tredjepartskode i regulerede arbejdsgange.

Bestyrelsen og ledelsesorganet skal forstå fire punkter:

1. Browseren er nu en central forretningsplatform.
2. Udvidelser kan tilgå følsomme SaaS-data og autentificerede sessioner.
3. Uadministrerede udvidelser skaber leverandør-, privatlivs-, hændelses- og robusthedsrisiko.
4. ISO/IEC 27001:2022 giver en forsvarlig kontrolmodel, der understøtter bevismateriale for NIS2, DORA og GDPR.

Den rammesætning flytter diskussionen væk fra teknisk præference og hen mod operationel robusthed. Den understøtter også finansiering af enterprise browserstyring, endepunktsintegration, overvågning, databeskyttelsesgennemgang, leverandørtriage og automatisering af revisionsbevis.

Fra blindvinkel til strategisk kontrol

Marias revisionsproblem skyldtes ikke, at én analytiker installerede ét produktivitetsværktøj. Det skyldtes en uadministreret risikoklasse. Organisationen havde opbygget et stærkt compliance-program omkring synlige aktiver, synlige leverandører, synlige SaaS-platforme og synlige endepunkter, men laget med browserudvidelser forblev usynligt.

Det hul er nu for vigtigt til at ignorere.

Løsningen er ikke kompliceret, men den skal være bevidst. Behandl browseren som en del af endepunktet. Behandl udvidelser som software. Behandl udviklere af udvidelser og backends som leverandører, hvor det er relevant. Behandl tilladelser som dataadgang. Behandl installation som ændring. Behandl logfiler som revisionsbevis.

Et forsvarligt program starter med fire handlinger:

1. Kortlæg alle udvidelser på tværs af administrerede browsere og endepunkter.
2. Definér acceptabel brug og standard-deny-regler ved hjælp af Politik for malwarebeskyttelse af endepunkter - SME, P03 Politik for acceptabel brug og virksomhedens Politik for acceptabel brug.
3. Vurder anmodninger om udvidelser med leverandør-, cloud-, sårbarheds- og databeskyttelseskriterier fra Politik for tredjeparts- og leverandørsikkerhed og Politik for krav til applikationssikkerhed - SME.
4. Håndhæv og overvåg installationsaktivitet ved hjælp af browserstyring, logning og praksis for bevismateriale tilpasset Lognings- og overvågningspolitik - SME.

For CISO’er, der forbereder sig på NIS2-, DORA-, GDPR- eller ISO/IEC 27001:2022-revisioner, er styring af browserudvidelser en kontrolforbedring med høj værdi, fordi den lukker en reel angrebsvej og samtidig producerer genanvendeligt bevismateriale på tværs af rammeværker.

For at fremskynde arbejdet kan du downloade Zenith Blueprint: En auditors 30-trins køreplan og kortlægge dit bevismateriale med Zenith Controls: Vejledningen til tværgående efterlevelse. Hvis du vil omsætte kaos omkring browserudvidelser til et revisionsklart styringsprogram, kan du planlægge en Clarysec-vurdering eller demo og starte med en praktisk fortegnelse, et risikokort og en 90-dages kontrolplan.