Governance delle estensioni del browser per NIS2, DORA e GDPR
Maria, Responsabile della sicurezza delle informazioni di una fintech in forte crescita, pensava che la valutazione preliminare DORA stesse procedendo bene. Il suo team aveva preparato il registro delle terze parti ICT, i contratti SaaS critici, le evidenze di due diligence sui fornitori, le decisioni di accettazione del rischio e il pacchetto di reporting per l’organo di gestione.
Poi l’auditor fece una domanda che nessuno aveva previsto.
“Potete mostrarci il vostro processo di governance per le estensioni del browser?”
La domanda nacque durante un riesame degli endpoint con un analista finanziario. Nel corso di una condivisione dello schermo, l’auditor notò un’estensione di produttività di terze parti nel browser dell’analista. Sembrava innocua, ma una rapida ricerca mostrò che lo sviluppatore aveva subito una compromissione della catena di fornitura tre mesi prima. L’estensione compromessa era stata utilizzata per sottrarre token di sessione da importanti piattaforme SaaS.
La fintech disponeva di politiche solide contro il software non autorizzato. Aveva EDR, MFA, CASB, log SaaS e un SGSI allineato a ISO/IEC 27001. Tuttavia, nessuno aveva trattato il browser come una piattaforma software gestita. Nessuno aveva inventariato le estensioni. Nessuno ne aveva approvato le autorizzazioni. Nessuno aveva verificato se gli sviluppatori delle estensioni dovessero essere qualificati come fornitori. Nessuno aveva mappato l’attività delle estensioni rispetto alle evidenze DORA, NIS2 o GDPR.
Un singolo componente aggiuntivo del browser aveva trasformato un endpoint apparentemente conforme in una possibile backdoor verso sistemi finanziari, dati dei clienti e flussi di lavoro regolamentati.
Questo è il problema della governance delle estensioni del browser nel 2026. Il browser non è più solo una finestra su Internet. È il punto in cui i dipendenti si autenticano, approvano pagamenti, accedono alle registrazioni CRM, trattano dati personali, gestiscono infrastruttura cloud e interagiscono con piattaforme SaaS critiche. Le estensioni non sono più componenti aggiuntivi cosmetici. Sono codice di terze parti eseguito nello strato più sensibile del lavoro moderno.
Per i Responsabili della sicurezza delle informazioni, i responsabili della conformità, i Responsabili della protezione dei dati (DPO) e i titolari del rischio ICT, le estensioni non gestite si collocano all’intersezione tra sicurezza degli endpoint, shadow IT, rischio dei fornitori, gestione delle modifiche, gestione delle vulnerabilità e accountability privacy. ISO/IEC 27001:2022 offre alle organizzazioni la struttura per governare questo rischio. NIS2, DORA e GDPR forniscono la pressione normativa per dimostrarlo.
Le estensioni del browser sono software, fornitori e potenziali responsabili del trattamento
La maggior parte delle organizzazioni ha già imparato a gestire laptop, dispositivi mobili, server, applicazioni SaaS, infrastruttura cloud e account privilegiati. Le estensioni del browser spesso restano fuori da questi programmi.
I team di sicurezza le considerano un’impostazione del browser. L’approvvigionamento non le vede perché non viene firmato alcun contratto. La funzione legale non le vede perché non viene aperta alcuna richiesta di onboarding del fornitore. I team privacy non le vedono perché l’estensione è installata da un utente, non distribuita come applicazione ufficiale. Eppure l’estensione può richiedere l’autorizzazione a leggere e modificare dati su tutti i siti web, accedere al contenuto degli appunti, acquisire metadati delle pagine, gestire download, iniettare script o comunicare con un backend esterno.
Ciò significa che un’estensione del browser può essere contemporaneamente tutte le seguenti cose:
| Prospettiva di governance | Perché è rilevante | Modalità tipica di fallimento |
|---|---|---|
| Software | Modifica il comportamento degli endpoint e può eseguire codice nelle sessioni utente | Gli utenti installano estensioni al di fuori dei flussi di approvazione del software |
| Fornitore | Lo sviluppatore controlla aggiornamenti, infrastruttura e supporto | Non viene svolta alcuna due diligence sui fornitori |
| Servizio cloud | Molte estensioni si connettono ad API ospitate o a piattaforme SaaS | I backend delle estensioni non sono riesaminati come servizi cloud |
| Rischio da responsabile del trattamento | Le estensioni possono vedere dati dei clienti, dei dipendenti o finanziari | I team privacy non valutano l’accesso ai dati o la base giuridica |
| Esposizione a vulnerabilità | Le estensioni possono essere compromesse, abbandonate o malevole | Non viene eseguito alcun riesame di patching, reputazione o compromissioni note |
| Fonte di incidente | L’attività dell’estensione può creare accesso non autorizzato o esfiltrazione | Mancano i log, rendendo più difficili indagine e notifica |
La [ZB] Zenith Blueprint: Roadmap in 30 passi per l’auditor coglie il punto centrale nella sua guida ISO/IEC 27002:2022 per il Controllo 8.19. Avverte che “anche personale animato da buone intenzioni potrebbe installare strumenti per ’lavorare più rapidamente’, un’estensione del browser, una libreria di codice, un’applicazione di trasferimento file, senza rendersi conto di aver appena introdotto una backdoor, una dipendenza non aggiornata o un vettore di esfiltrazione di dati”.
Questa frase deve essere trattata come una dichiarazione di rischio a livello di consiglio di amministrazione. I dipendenti che installano estensioni rischiose di solito non cercano di aggirare la sicurezza. Cercano di aumentare la produttività. Il fallimento della governance si verifica quando l’organizzazione non fornisce un processo sicuro di richiesta, approvazione, distribuzione e monitoraggio.
Perché NIS2, DORA e GDPR rendono urgente il punto cieco
Il rischio delle estensioni del browser esiste da anni, ma il contesto normativo è cambiato. Nel 2026, le organizzazioni devono dimostrare non solo che i controlli esistono, ma anche che sono basati sul rischio, integrati, monitorati e supportati da evidenze.
NIS2 alza le aspettative in materia di igiene informatica e sicurezza della catena di fornitura. DORA richiede alle entità finanziarie di gestire il rischio ICT lungo le dipendenze interne e di terze parti. GDPR richiede a titolari e responsabili del trattamento di dimostrare sicurezza del trattamento, accountability e protezione dei dati fin dalla progettazione. Le estensioni non gestite possono compromettere tutti e tre gli ambiti.
| Regolamento | Rilevanza delle estensioni del browser | Evidenze attese da autorità e auditor |
|---|---|---|
| NIS2 Article 21 | Le estensioni incidono su igiene informatica, trattamento delle vulnerabilità, controllo degli accessi, sicurezza del software e rischio della catena di fornitura | Inventario delle estensioni, elenco approvato, registrazioni della valutazione del rischio, log delle installazioni bloccate, evidenze di trattamento dell’incidente |
| NIS2 Article 23 | Un’estensione compromessa può generare un incidente significativo che richiede preallerta e notifica | Log di rilevazione, registrazioni di triage, valutazione dell’impatto, evidenze della decisione di notifica |
| DORA Article 5 | Gli organi di gestione restano responsabili della governance del rischio ICT | Politiche, decisioni sulla propensione al rischio, reporting, approvazioni delle eccezioni |
| DORA Article 6 | Le estensioni possono incidere sul quadro di riferimento per la gestione del rischio ICT | Identificazione degli asset, controlli di protezione, monitoraggio, test di resilienza, registrazioni di remediation |
| DORA Article 28 | Gli sviluppatori di estensioni e i servizi connessi possono costituire dipendenze ICT di terze parti | Due diligence, classificazione del rischio, voci di registro, valutazione contrattuale ove applicabile |
| GDPR Article 5(2) | Le organizzazioni devono dimostrare accountability per il trattamento dei dati personali | Valutazioni documentate, decisioni di approvazione, titolarità, cadenza dei riesami |
| GDPR Article 25 | La protezione dei dati fin dalla progettazione e per impostazione predefinita si applica alle scelte degli strumenti | Minimizzazione delle autorizzazioni, riesame privacy, configurazione con blocco predefinito |
| GDPR Article 32 | La sicurezza del trattamento richiede misure tecniche e organizzative adeguate | Controlli sugli endpoint, restrizioni di accesso, logging, monitoraggio, gestione delle vulnerabilità |
| GDPR Article 33 | La preparazione alla notifica delle violazioni dipende da rilevazione tempestiva ed evidenze | Log degli incidenti, analisi dell’impatto sui dati personali, evidenze della tempistica di notifica |
La lezione è semplice. Un’estensione del browser non è troppo piccola per essere rilevante. Se può entrare in contatto con dati regolamentati, sessioni autenticate, flussi di lavoro finanziari o servizi SaaS critici, deve essere governata.
Usare ISO/IEC 27001:2022 come modello operativo
ISO/IEC 27001:2022 è efficace per la governance delle estensioni del browser perché non richiede un silos separato di conformità. Consente alle organizzazioni di estendere i processi del SGSI esistenti allo strato del browser.
Il modello pratico di controllo si basa su otto controlli dell’Annex A di ISO/IEC 27001:2022:
| Controllo ISO/IEC 27001:2022 | Nome corretto del controllo | Applicazione alle estensioni del browser |
|---|---|---|
| 5.10 | Uso accettabile delle informazioni e degli altri asset associati | Definire cosa gli utenti possono installare, usare, richiedere e archiviare nei browser |
| 5.19 | Sicurezza delle informazioni nei rapporti con i fornitori | Trattare gli sviluppatori di estensioni e i servizi connessi come rischi dei fornitori quando pertinente |
| 5.23 | Sicurezza delle informazioni per l’uso dei servizi cloud | Riesaminare le estensioni che si connettono ad API SaaS esterne o a backend cloud |
| 8.1 | Dispositivi endpoint degli utenti | Gestire la configurazione del browser come parte della protezione degli endpoint |
| 8.8 | Gestione delle vulnerabilità tecniche | Tracciare estensioni vulnerabili, abbandonate, compromesse o ad alto rischio |
| 8.15 | Registrazione | Acquisire installazioni, rimozioni, tentativi bloccati, modifiche alle politiche e azioni amministrative |
| 8.16 | Attività di monitoraggio | Generare allerte su attività anomale delle estensioni e violazioni delle politiche |
| 8.19 | Installazione di software sui sistemi operativi | Richiedere approvazione prima che le estensioni siano installate sui sistemi di lavoro |
La [ZC] Zenith Controls: Guida alla conformità trasversale è particolarmente utile perché spiega come vengono auditati i controlli ISO/IEC 27001 e come supportano evidenze trasversali tra quadri di riferimento. Per il Controllo 8.19, Zenith Controls: Guida alla conformità trasversale spiega che gli auditor “seguiranno il flusso di lavoro: dalla richiesta al test, dall’approvazione all’attuazione”. È esattamente così che deve essere progettata la governance delle estensioni.
Se un auditor trova un’estensione che non è nell’elenco approvato, non è documentata nelle registrazioni delle modifiche e non è stata oggetto di valutazione del rischio, il problema non è più solo un’impostazione del browser. Diventa evidenza di un controllo debole sull’installazione del software, di una governance debole degli endpoint e di un possibile fallimento nella gestione del rischio dei fornitori.
Passo 1, rilevare il parco delle estensioni
Il primo fallimento di controllo nella fintech di Maria era la visibilità. Il suo team non sapeva quali estensioni fossero installate, chi le avesse installate, quali autorizzazioni richiedessero o se si connettessero a servizi esterni.
La discovery deve coprire tutti i browser gestiti, i profili, gli utenti, i dispositivi e i sistemi operativi. Deve identificare nome dell’estensione, ID univoco, versione, editore, fonte di installazione, insieme di autorizzazioni, data di installazione, stato di aggiornamento, numero di utenti, titolare dell’attività e se l’estensione è installata forzatamente, installata dall’utente, caricata tramite sideloading o bloccata.
Il Controllo 8.1, Dispositivi endpoint degli utenti, è il riferimento. La guida Zenith Blueprint: Roadmap in 30 passi per l’auditor per il Controllo 8.1 afferma che i dispositivi endpoint degli utenti “devono essere rafforzati, monitorati e controllati”. Questo requisito include naturalmente il browser, perché il browser è oggi l’interfaccia principale dell’endpoint utente per il lavoro SaaS e cloud.
Il Controllo 5.23 si applica anche quando le estensioni si connettono a servizi cloud. Zenith Blueprint: Roadmap in 30 passi per l’auditor inquadra questo controllo come risposta allo shadow IT, in cui gli utenti adottano servizi non autorizzati senza governance. Un’estensione del browser che invia contenuti a un backend ospitato sconosciuto rappresenta un evento di adozione di un servizio cloud, anche se nessuno nell’area approvvigionamento lo ha approvato.
Un output di discovery maturo dovrebbe classificare ogni estensione in uno dei cinque stati seguenti:
| Stato dell’estensione | Significato | Azione richiesta |
|---|---|---|
| Approvata | Riesaminata, giustificata e consentita per utenti definiti | Monitorare e riesaminare periodicamente |
| Condizionata | Consentita con restrizioni, ad esempio gruppi, siti o autorizzazioni specifici | Applicare le condizioni e riesaminare con maggiore frequenza |
| In attesa di riesame | Rilevata o richiesta ma non ancora valutata | Bloccare o mettere in quarantena fino all’approvazione |
| Bloccata | Nota come rischiosa, non necessaria, non conforme o vietata | Impedire l’installazione e rimuovere le istanze esistenti |
| Eccezione | Temporaneamente consentita per esigenza aziendale e rischio accettato | Registrare titolare, data di scadenza, controlli compensativi e approvatore |
La discovery non deve essere un progetto una tantum. Le estensioni si aggiornano frequentemente, gli editori cambiano proprietà, le autorizzazioni si ampliano e gli store rimuovono pacchetti malevoli dopo che gli utenti li hanno già installati. L’inventario deve diventare continuo o almeno ricorrente con frequenza sufficiente a supportare la gestione delle vulnerabilità e le evidenze di audit.
Passo 2, rendere esplicito l’uso accettabile
Quando le estensioni sono visibili, le aspettative verso gli utenti devono essere chiare. Molte organizzazioni hanno già testi di policy che possono supportare la governance delle estensioni, ma devono essere applicati esplicitamente al browser.
[P-EPM] Protezione degli endpoint - Politica malware - PMI stabilisce che gli utenti “non devono installare software o plugin non autorizzati che possano introdurre rischi”. Questa singola frase fornisce ai team di sicurezza una solida base di policy per trattare le estensioni del browser come software controllato.
[P03-AUP] P03 Politica di uso accettabile, richiamata anche come Politica di uso accettabile aziendale, vieta “Strumenti non approvati: installare o utilizzare software, hardware, servizi cloud o dispositivi non autorizzati”. Questa è la base rivolta agli utenti. Trasforma la governance delle estensioni del browser da preferenza tecnica a requisito comportamentale e di conformità applicabile.
Una politica solida sulle estensioni del browser deve rispondere a sei domande pratiche:
| Domanda di policy | Risposta di governance |
|---|---|
| Gli utenti possono installare liberamente estensioni? | No, le estensioni richiedono approvazione salvo pre-approvazione per ruolo o gruppo |
| Le estensioni del browser sono considerate software? | Sì, sono software installato sui sistemi operativi |
| I backend delle estensioni sono considerati servizi cloud? | Sì, quando trattano, trasmettono, archiviano o arricchiscono dati dell’organizzazione |
| Chi approva le estensioni? | Sicurezza, IT, privacy e titolari dell’attività approvano in base al rischio |
| Cosa accade alle estensioni non approvate? | Vengono bloccate, rimosse o messe in quarantena in attesa di riesame |
| Come sono gestite le eccezioni? | Le eccezioni richiedono accettazione del rischio documentata, scadenza e controlli compensativi |
Non si tratta di vietare ogni estensione utile. Si tratta di passare dalla fiducia implicita all’approvazione esplicita. Alcune estensioni possono essere sicure, necessarie e utili alla produttività. Altre possono essere non necessarie, eccessivamente privilegiate, abbandonate o ostili. Il programma di governance deve distinguerle.
Passo 3, applicare il blocco predefinito con lista di autorizzazione per eccezione
Il Controllo 8.19, Installazione di software sui sistemi operativi, è il controllo che trasforma la policy in operatività. Le estensioni del browser non devono essere trattate diversamente da altro software solo perché gli utenti le installano tramite uno store del browser.
Zenith Blueprint: Roadmap in 30 passi per l’auditor è diretto su questo punto: “nessun software viene installato se non è giustificato, autorizzato e sicuro”. Per le estensioni del browser, ciò significa utilizzare gestione del browser aziendale, gestione degli endpoint o strumenti di configurazione dei dispositivi per applicare le regole di installazione.
Il modello più difendibile è il blocco predefinito con lista di autorizzazione per eccezione:
- Bloccare per impostazione predefinita tutte le estensioni sui browser gestiti.
- Installare forzatamente solo le estensioni aziendali essenziali e approvate.
- Mantenere una lista di autorizzazione per le estensioni approvate per gruppo di utenti, dipartimento o ruolo.
- Bloccare le estensioni installate tramite sideloading e le fonti di installazione non attendibili.
- Impedire agli utenti di aggirare le politiche cambiando profilo o usando browser non gestiti.
- Rimuovere le estensioni già installate che non sono approvate.
- Riesaminare autorizzazioni dell’estensione e rischio dell’editore prima dell’approvazione.
- Registrare nei log le estensioni consentite, bloccate, rimosse e modificate.
Alcune organizzazioni iniziano con un modello più graduale a causa della complessità operativa. Possono prima inventariare, bloccare le estensioni note come malevole e poi introdurre progressivamente le liste di autorizzazione per gruppi ad alto rischio come finanza, engineering, amministratori privilegiati, legale, HR e assistenza clienti. È accettabile se esiste una tabella di marcia documentata. Ciò che non è difendibile è la tolleranza permanente del rischio ignoto delle estensioni.
Passo 4, valutare il rischio delle estensioni come fornitori e software
Il riesame del rischio di un’estensione del browser deve essere abbastanza leggero da favorire l’adozione da parte del business, ma abbastanza solido da reggere un audit. Il riesame deve combinare rischio software, rischio dei fornitori, rischio cloud, protezione dei dati e gestione delle vulnerabilità.
[P-TP] Politica di sicurezza delle terze parti e dei fornitori impone che “tutti i nuovi fornitori siano sottoposti a una valutazione di sicurezza documentata prima della formalizzazione del contratto”. Non tutti gli sviluppatori di estensioni richiederanno un processo completo di onboarding dei fornitori aziendali, ma il principio del rischio dei fornitori resta valido. Se uno sviluppatore può inviare aggiornamenti di codice nei browser dei dipendenti o trattare dati dell’organizzazione tramite un servizio backend, l’organizzazione ha una dipendenza da terze parti.
[P-ASR] Politica sui requisiti di sicurezza delle applicazioni - PMI rafforza lo stesso requisito da una prospettiva software: “qualsiasi strumento di terze parti, plugin o libreria di codice esterna utilizzata in un’applicazione deve essere registrata e riesaminata annualmente per l’impatto sulla sicurezza e lo stato delle patch”.
Utilizzare il seguente modello di rischio per standardizzare le decisioni:
| Fattore di rischio | Rischio basso | Rischio medio | Rischio alto |
|---|---|---|---|
| Autorizzazioni | Nessun accesso ai dati della pagina | Accesso alla scheda attiva o a siti limitati | Accesso in lettura e scrittura a tutti i siti |
| Editore | Editore verificato con storia solida | Azienda nota con informativa privacy | Soggetto sconosciuto, titolarità non chiara, nessuna informativa privacy |
| Accesso ai dati | Opera localmente senza dati sensibili | Vede dati aziendali limitati | Accede a dati personali, dati finanziari, segreti o contenuto di sessione |
| Connettività | Nessun backend esterno | Si connette a un servizio noto | Si connette a un backend sconosciuto o opaco di terze parti |
| Modello di aggiornamento | Store ufficiale, aggiornamenti regolari | Aggiornamenti poco frequenti, changelog limitato | Installata tramite sideloading, abbandonata o fonte di aggiornamento non chiara |
| Esigenza aziendale | Necessaria per un flusso di lavoro approvato | Utile ma sostituibile | Solo comodità con autorizzazioni elevate |
| Storico delle vulnerabilità | Nessuna risultanza negativa | Problemi passati risolti | Compromissione nota, comportamento malevolo o vulnerabilità irrisolta |
| Postura privacy | Informativa privacy chiara e raccolta limitata | Policy ampia ma controlli accettabili | Nessuna policy chiara o raccolta eccessiva |
Un’estensione ad alto rischio non deve essere approvata salvo esistenza di un’esigenza aziendale critica, controlli compensativi documentati e accettazione del rischio da parte dell’alta direzione. Esempi di controlli compensativi includono limitare l’uso a un profilo browser con configurazione sicura, restringere l’uso a URL specifici, bloccare l’immissione di dati in applicazioni sensibili mentre l’estensione è attiva, utilizzare monitoraggio DLP oppure richiedere un contratto con il fornitore e un addendum privacy.
Passo 5, integrare il riesame privacy e GDPR
La governance delle estensioni del browser spesso fallisce perché il riesame privacy è disconnesso dagli strumenti endpoint. Eppure molte estensioni possono vedere dati personali visualizzati in applicazioni SaaS, sistemi HR, ticket di supporto, registrazioni CRM, e-mail, piattaforme di analisi e strumenti di collaborazione.
Ai sensi del GDPR Article 5(2), l’organizzazione deve dimostrare accountability. Ai sensi dell’Article 25, deve applicare protezione dei dati fin dalla progettazione e per impostazione predefinita. Ai sensi dell’Article 32, deve applicare misure tecniche e organizzative adeguate per la sicurezza del trattamento. Se un’estensione esfiltra dati personali, l’evento può diventare una violazione dei dati personali ai sensi dell’Article 4(12), attivando una valutazione e, potenzialmente, gli obblighi di notifica previsti dall’Article 33.
Un riesame delle estensioni attento alla privacy deve porsi queste domande:
| Area di riesame GDPR | Domanda di riesame dell’estensione | Evidenza da conservare |
|---|---|---|
| Categorie di dati | L’estensione può accedere a dati personali, categorie particolari di dati o dati finanziari? | Valutazione dell’accesso ai dati |
| Limitazione della finalità | L’estensione è necessaria per una finalità aziendale definita? | Giustificazione aziendale |
| Minimizzazione dei dati | Le autorizzazioni richieste sono limitate al minimo necessario? | Riesame delle autorizzazioni |
| Rapporto con il responsabile del trattamento | Il fornitore dell’estensione tratta dati per conto dell’organizzazione? | Valutazione del fornitore e privacy |
| Trasferimenti internazionali | I dati lasciano la giurisdizione o la regione di hosting approvata? | Valutazione del trasferimento |
| Conservazione | Il fornitore archivia dati, log, prompt, screenshot o metadati? | Riesame dell’informativa privacy e della conservazione |
| Sicurezza | Cifratura, controlli di accesso e pratiche di gestione delle vulnerabilità sono adeguati? | Due diligence di sicurezza |
| Risposta alle violazioni | Il fornitore può notificare all’organizzazione gli incidenti? | Evidenza contrattuale o documentata della risposta |
Non tutte le estensioni richiedono una DPIA completa. Tuttavia, le estensioni con accesso ampio alle pagine, elaborazione AI, acquisizione dello schermo, accesso e-mail, accesso CRM, accesso a dati HR, dati dell’assistenza clienti o dati finanziari regolamentati devono attivare una valutazione privacy strutturata.
Passo 6, registrare nei log e monitorare per audit e risposta agli incidenti
Un programma di governance delle estensioni senza log non è auditabile. Indebolisce anche la risposta agli incidenti, perché l’organizzazione non può determinare quando un’estensione è stata installata, chi l’ha usata, quale versione fosse presente, quando siano cambiate le autorizzazioni o se si sia verificato un tentativo di installazione bloccato.
[P-LM] Politica di registrazione e monitoraggio - PMI identifica i log per le “installazioni software” come requisito chiave di governance. L’installazione di un’estensione del browser è un evento di installazione software e deve essere acquisita di conseguenza.
Come minimo, i log devono includere:
| Evento di log | Perché è rilevante |
|---|---|
| Estensione installata | Conferma la distribuzione e supporta le evidenze di modifica |
| Estensione bloccata | Dimostra il funzionamento del controllo preventivo |
| Estensione rimossa | Conferma la remediation |
| Estensione aggiornata | Supporta il riesame di vulnerabilità e modifiche |
| Autorizzazione modificata | Rileva un aumento del rischio dopo l’approvazione |
| Politica modificata | Dimostra controllo amministrativo e accountability |
| Tentativo di sideloading | Indica comportamento di aggiramento o rischio malware |
| Fonte dello store modificata | Rileva un percorso di installazione non attendibile |
| Estensione ad alto rischio rilevata | Attiva triage e rimozione |
| Eccezione utente concessa | Supporta le evidenze di accettazione del rischio |
Questi log devono alimentare i processi di monitoraggio previsti dai Controlli 8.15 e 8.16. In base al rischio, possono anche confluire in un SIEM, in una piattaforma endpoint o in un repository di evidenze di conformità. Le allerte devono essere configurate per estensioni ad alto rischio bloccate, picchi improvvisi nelle richieste di estensioni, modifiche alle autorizzazioni di estensioni approvate, tentativi di installazione da fonti non ufficiali e tentativi di installazione da parte di utenti privilegiati.
Il monitoraggio è anche un vantaggio per NIS2 e DORA. La segnalazione degli incidenti ai sensi di NIS2 Article 23 dipende dalla rilevazione precoce e dalla valutazione dell’impatto. DORA richiede un trattamento solido degli incidenti ICT ed evidenze di resilienza. La valutazione delle violazioni ai sensi del GDPR dipende dalla capacità di sapere cosa è accaduto, quando e quali dati possono essere stati interessati.
Cosa vuole vedere l’auditor
Un auditor raramente si accontenta di una dichiarazione come “blocchiamo le estensioni rischiose”. Vuole evidenze di governance. Le evidenze devono collegare policy, valutazione del rischio, applicazione tecnica, monitoraggio e responsabilità della direzione.
| Domanda di audit | Risposta solida | Artifact di evidenza |
|---|---|---|
| Le estensioni del browser rientrano nell’ambito di applicazione? | Sì, sono trattate come software sui dispositivi endpoint degli utenti | Ambito di applicazione del SGSI, registro degli asset, standard endpoint |
| Agli utenti è vietato installare estensioni non approvate? | Sì, le politiche di uso accettabile ed endpoint definiscono la regola | Protezione degli endpoint - Politica malware - PMI, P03 Politica di uso accettabile |
| Esiste un elenco di estensioni approvate? | Sì, le estensioni approvate sono documentate per titolare dell’attività e gruppo utente | Esportazione della lista di autorizzazione, registro delle approvazioni |
| Le nuove estensioni sono oggetto di valutazione del rischio? | Sì, le richieste attivano verifiche software, fornitori, vulnerabilità e privacy | Registrazione della valutazione del rischio |
| Gli sviluppatori di estensioni sono trattati come fornitori quando pertinente? | Sì, i provider ad alto rischio sono sottoposti a due diligence | Valutazione del fornitore |
| Le estensioni connesse al cloud sono riesaminate? | Sì, i backend esterni sono valutati nell’ambito della governance dei servizi cloud | Riesame del servizio cloud |
| Le installazioni sono applicate tecnicamente? | Sì, blocco predefinito e liste di autorizzazione per gruppi sono applicati nella gestione del browser | Esportazione della configurazione |
| Le modifiche sono registrate nei log? | Sì, installazioni, blocchi, rimozioni, aggiornamenti e modifiche amministrative sono registrati nei log | Log SIEM o console amministrativa |
| Le eccezioni sono controllate? | Sì, le eccezioni richiedono titolare, scadenza, approvatore e controlli compensativi | Registro delle eccezioni |
| I riesami sono ripetuti? | Sì, le estensioni sono riesaminate periodicamente e dopo modifiche rilevanti | Piano di riesame ed evidenze |
È qui che Zenith Controls: Guida alla conformità trasversale diventa preziosa. Aiuta le organizzazioni a mostrare come una singola attività di controllo supporti più aspettative di conformità. Un unico flusso di approvazione delle estensioni del browser può supportare il Controllo 8.19 ISO/IEC 27001, l’igiene informatica NIS2, la gestione del rischio ICT DORA e l’accountability GDPR se le evidenze sono conservate e mappate chiaramente.
Mappatura, da ISO/IEC 27001:2022 a NIS2, DORA e GDPR
Una mappatura pratica aiuta i CISO a spiegare perché la governance delle estensioni del browser non è un controllo tecnico di nicchia. È un controllo di conformità con ampio valore normativo.
| Controllo ISO/IEC 27001:2022 | Allineamento NIS2 | Allineamento DORA | Allineamento GDPR | Evidenza per le estensioni del browser |
|---|---|---|---|---|
| 5.10 Uso accettabile delle informazioni e degli altri asset associati | Article 21 igiene informatica e pratiche degli utenti | Article 5 aspettative di governance | Article 5(2) accountability | Regole di uso accettabile, sensibilizzazione degli utenti, attestazioni di presa d’atto delle politiche |
| 5.19 Sicurezza delle informazioni nei rapporti con i fornitori | Article 21 sicurezza della catena di fornitura | Article 28 gestione del rischio ICT di terze parti | Articles 28 and 32 quando si applica il trattamento | Riesame del fornitore, valutazione del provider, analisi contrattuale |
| 5.23 Sicurezza delle informazioni per l’uso dei servizi cloud | Article 21 sicurezza ICT e di rete | Articles 6 and 28 rischio ICT e dipendenze da terze parti | Articles 25 and 32 protezione dei dati fin dalla progettazione e sicurezza | Riesame del backend cloud, approvazione dell’integrazione SaaS |
| 8.1 Dispositivi endpoint degli utenti | Article 21 sicurezza degli endpoint e controllo degli accessi | Article 6 quadro di riferimento per la gestione del rischio ICT | Article 32 sicurezza del trattamento | Configurazione del browser, profili gestiti, inventario degli endpoint |
| 8.8 Gestione delle vulnerabilità tecniche | Article 21 trattamento delle vulnerabilità | Article 6 protezione e prevenzione | Article 32 misure tecniche | Tracciamento delle estensioni vulnerabili, registrazioni di remediation |
| 8.15 Registrazione | Article 23 evidenze sugli incidenti | Trattamento degli incidenti ICT ed evidenze di resilienza | Articles 5(2), 32, and 33 accountability ed evidenze sulle violazioni | Log di installazione, tentativi bloccati, modifiche alle politiche |
| 8.16 Attività di monitoraggio | Article 21 rilevazione e Article 23 segnalazione | Monitoraggio ICT e rilevazione degli incidenti | Articles 32 and 33 rilevazione delle violazioni | Allerte, eventi SIEM, report sulle anomalie |
| 8.19 Installazione di software sui sistemi operativi | Article 21 configurazione sicura e controllo del software | Aspettative di controllo delle modifiche ICT, incluso COBIT BAI06 Managed IT Changes come prospettiva di audit | Articles 25 and 32 ambiente di trattamento controllato | Richiesta, approvazione, test, distribuzione, evidenze della lista di autorizzazione |
La mappatura DORA merita particolare attenzione. Alcuni auditor e valutatori useranno linguaggio in stile COBIT durante il riesame della governance delle modifiche ICT. COBIT BAI06 è comunemente inteso come Managed IT Changes. Se le estensioni del browser sono software e la loro installazione modifica l’ambiente di elaborazione dell’utente, allora l’installazione delle estensioni rientra nella stessa logica governata delle modifiche. Zenith Controls: Guida alla conformità trasversale supporta questa prospettiva di audit mostrando come le evidenze dei controlli ISO/IEC 27001 possano essere riutilizzate tra diverse aspettative di conformità.
Un piano di attuazione di 90 giorni per la governance delle estensioni del browser
Le organizzazioni non devono risolvere tutto in una sola settimana. Un programma pratico può essere costruito per fasi, soprattutto se occorre gestire con attenzione l’impatto sull’operatività.
| Tempistica | Obiettivo | Azioni | Deliverable |
|---|---|---|---|
| Giorni 1-15 | Stabilire ambito e titolarità | Assegnare titolari IT, sicurezza, privacy, approvvigionamento e business; confermare browser gestiti e gruppi utente | Elenco dei responsabili della governance, ambito browser, dichiarazione iniziale di rischio |
| Giorni 16-30 | Rilevare lo stato attuale | Inventariare estensioni installate, autorizzazioni, editori, versioni, utenti e fonti di installazione | Inventario delle estensioni, risultanze ad alto rischio, sintesi esecutiva iniziale |
| Giorni 31-45 | Definire policy e regole decisionali | Aggiornare procedure di uso accettabile, endpoint, cloud e fornitori per includere le estensioni | Aggiornamenti delle politiche, criteri di approvazione, processo di eccezione |
| Giorni 46-60 | Costruire il flusso di valutazione del rischio | Creare modulo di richiesta, modello di punteggio, domande privacy, triage dei fornitori e registrazioni di approvazione | Flusso di richiesta delle estensioni, matrice del rischio, modelli di evidenza |
| Giorni 61-75 | Applicare i controlli tecnici | Configurare blocco predefinito o liste di autorizzazione progressive, bloccare il sideloading, rimuovere estensioni rischiose note | Configurazione di gestione del browser, lista di autorizzazione, lista di blocco |
| Giorni 76-90 | Monitorare e produrre evidenze | Inviare i log agli strumenti di monitoraggio, creare allerte, testare le evidenze di audit, riferire alla direzione | Dashboard di registrazione, regole di allerta, pacchetto di audit, report alla direzione |
Per le organizzazioni ad alto rischio, in particolare le entità finanziarie soggette a DORA o le entità essenziali e importanti soggette a NIS2, la prima fase di applicazione deve dare priorità agli utenti con accesso a sistemi critici, dati regolamentati, console amministrative privilegiate, piattaforme finanziarie, strumenti di assistenza clienti e ambienti di sviluppo.
Il messaggio per il consiglio di amministrazione
La governance delle estensioni del browser non deve essere presentata ai dirigenti come un progetto di rafforzamento della configurazione del browser. Deve essere presentata come un controllo sul codice di terze parti non valutato nei flussi di lavoro regolamentati.
Il consiglio di amministrazione e l’organo di gestione devono comprendere quattro punti:
- Il browser è ormai una piattaforma aziendale core.
- Le estensioni possono accedere a dati SaaS sensibili e sessioni autenticate.
- Le estensioni non gestite generano rischi per fornitori, privacy, incidenti e resilienza.
- ISO/IEC 27001:2022 fornisce un modello di controllo difendibile che supporta evidenze NIS2, DORA e GDPR.
Questo inquadramento sposta la discussione dalla preferenza tecnica alla resilienza operativa. Supporta inoltre il finanziamento di gestione del browser aziendale, integrazione endpoint, monitoraggio, riesame privacy, triage dei fornitori e automazione delle evidenze di audit.
Da punto cieco a controllo strategico
Il problema di audit di Maria non era stato causato da un analista che aveva installato uno strumento di produttività. Era stato causato da una classe di rischio non gestita. L’organizzazione aveva costruito un solido programma di conformità intorno ad asset visibili, fornitori visibili, piattaforme SaaS visibili ed endpoint visibili, ma lo strato delle estensioni del browser era rimasto invisibile.
Questa lacuna è ormai troppo importante per essere ignorata.
La soluzione non è complicata, ma deve essere deliberata. Trattare il browser come parte dell’endpoint. Trattare le estensioni come software. Trattare gli sviluppatori delle estensioni e i backend come fornitori quando pertinente. Trattare le autorizzazioni come accesso ai dati. Trattare l’installazione come modifica. Trattare i log come evidenze di conformità.
Un programma difendibile inizia con quattro azioni:
- Rilevare ogni estensione nei browser gestiti e negli endpoint.
- Definire regole di uso accettabile e blocco predefinito utilizzando Protezione degli endpoint - Politica malware - PMI, P03 Politica di uso accettabile e la Politica di uso accettabile aziendale.
- Valutare le richieste di estensioni usando criteri relativi a fornitori, cloud, vulnerabilità e privacy tratti dalla Politica di sicurezza delle terze parti e dei fornitori e dalla Politica sui requisiti di sicurezza delle applicazioni - PMI.
- Applicare e monitorare l’attività di installazione utilizzando gestione del browser, registrazione e pratiche di evidenza allineate alla Politica di registrazione e monitoraggio - PMI.
Per i CISO che si preparano ad audit NIS2, DORA, GDPR o ISO/IEC 27001:2022, la governance delle estensioni del browser è un miglioramento di controllo ad alto valore perché chiude un percorso di attacco reale e produce evidenze riutilizzabili tra quadri di riferimento.
Per accelerare il lavoro, scarica Zenith Blueprint: Roadmap in 30 passi per l’auditor e mappa le tue evidenze con Zenith Controls: Guida alla conformità trasversale. Se vuoi trasformare il caos delle estensioni del browser in un programma di governance pronto per l’audit, pianifica una valutazione o una demo Clarysec e inizia con un inventario pratico, una mappa dei rischi e un piano di controllo di 90 giorni.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
