Intelligence sulle minacce ISO 27001 per NIS2 e DORA
Alle 07:42 di un martedì mattina, il CISO di una fintech europea riceve quattro messaggi prima del caffè.
Il primo è un’allerta di un CERT nazionale che segnala lo sfruttamento attivo di una vulnerabilità di accesso remoto. Il secondo è un bollettino di un fornitore che conferma che il componente interessato è utilizzato all’interno di un servizio gestito di trasferimento file. Il terzo è una notifica di un servizio di rilevamento e risposta gestiti che segnala traffico in uscita anomalo da una sottorete non di produzione. Il quarto arriva dal CFO: “Questo incide sul nostro pacchetto di preparazione DORA e dobbiamo notificare qualcuno ai sensi di NIS2?”
Questo è il problema dell’intelligence sulle minacce nel 2026. Non si tratta di raccogliere più feed. Si tratta di dimostrare che la cyber threat intelligence rilevante viene ricevuta, validata, instradata, gestita e convertita in evidenze di rischio, rilevamento, vulnerabilità, incidente, fornitore e consiglio di amministrazione.
Molte organizzazioni sono già abbonate ad avvisi dei fornitori, allerte CISA, aggiornamenti ENISA, comunicazioni dei CERT nazionali, bollettini ISAC, notifiche di sicurezza dei provider cloud, feed CVE, report MDR, database di sfruttabilità e monitoraggio del dark web. Eppure, quando arriva un avviso reale, i team continuano a muoversi in emergenza. Il SOC scrive una regola di rilevamento. L’infrastruttura cerca negli inventari degli asset, che potrebbero non essere aggiornati. La funzione compliance chiede se l’evento incida su NIS2 o DORA. La direzione vuole una risposta chiara prima ancora che l’organizzazione sappia se il componente vulnerabile sia in produzione.
Il problema non è la mancanza di dati. È la mancanza di un modello operativo verificabile in audit.
Un feed di minacce che nessuno usa non è un controllo. Un avviso di vulnerabilità che non modifica la priorità delle patch non è un’evidenza. Una comunicazione di un fornitore che non arriva mai al registro dei rischi non è sicurezza della catena di fornitura. Un’allerta CSIRT che non aggiorna il monitoraggio, il triage degli incidenti o la reportistica alla direzione è solo rumore nella casella di posta.
L’approccio di Clarysec è semplice: l’intelligence sulle minacce deve diventare un sistema operativo per le decisioni di rischio. Deve essere integrata nel campo di applicazione del SGSI, nella valutazione del rischio, nella dichiarazione di applicabilità, nei playbook sugli incidenti, nel triage delle vulnerabilità, nella registrazione e nel monitoraggio, nella governance dei fornitori, nella reportistica alla direzione e nel pacchetto di evidenze per l’audit.
Perché l’intelligence sulle minacce è ora un controllo a livello di consiglio di amministrazione
NIS2 ha cambiato il tono della governance della cibersicurezza. Porta nel perimetro molti fornitori SaaS, fornitori di servizi cloud, prestatori di servizi gestiti, fornitori di servizi di sicurezza gestiti, organizzazioni di infrastrutture digitali e fornitori di servizi digitali, come soggetti essenziali o importanti a seconda del settore, della dimensione e della designazione da parte dello Stato membro.
NIS2 Article 21 richiede misure tecniche, operative e organizzative appropriate e proporzionate per gestire i rischi. Queste includono analisi dei rischi, gestione degli incidenti, continuità operativa, sicurezza della catena di fornitura, sicurezza nell’acquisizione, nello sviluppo e nella manutenzione, compresi trattamento e divulgazione delle vulnerabilità, valutazione dell’efficacia, igiene informatica di base e formazione, crittografia, sicurezza delle risorse umane, controllo degli accessi, gestione degli asset e MFA o autenticazione continua ove appropriato.
NIS2 Article 20 richiede inoltre agli organi di gestione di approvare le misure di gestione dei rischi di cibersicurezza, vigilare sull’attuazione e ricevere formazione. Per i soggetti essenziali, la sanzione amministrativa massima può arrivare almeno a 10 milioni di euro o al 2% del fatturato annuo mondiale, se superiore. Per i soggetti importanti, può arrivare almeno a 7 milioni di euro o all’1,4%.
Per l’intelligence sulle minacce, la domanda a livello di consiglio diventa: come sappiamo che le minacce emergenti stanno modificando i nostri controlli prima che diventino incidenti?
DORA aggiunge un ulteriore livello per gli enti finanziari e per i pertinenti fornitori terzi di servizi ICT. Si applica dal 17 gennaio 2025 e richiede un quadro per la gestione del rischio ICT solido, completo e ben documentato, integrato nel sistema complessivo di gestione del rischio. Il quadro DORA si aspetta che le organizzazioni identifichino e classifichino funzioni aziendali e asset supportati dall’ICT, proteggano e prevengano, rilevino attività anomale, rispondano e ripristinino, gestiscano backup e ripristino, apprendano dagli incidenti ICT, comunichino durante le crisi e gestiscano il rischio ICT di terze parti.
DORA richiede inoltre la gestione, la classificazione e la segnalazione degli incidenti connessi all’ICT. Articles 17, 18 e 19 disciplinano i processi di gestione degli incidenti, la classificazione degli incidenti connessi all’ICT e delle minacce informatiche, e la segnalazione degli incidenti rilevanti connessi all’ICT. Article 10 si concentra sul rilevamento delle attività anomale. Articles 6 to 11 descrivono il quadro per la gestione del rischio ICT e le aspettative in materia di identificazione, protezione, prevenzione, rilevamento, risposta e ripristino.
In termini semplici, DORA richiede una resilienza consapevole delle minacce. Non una resilienza statica. Non una resilienza da politica annuale. Resilienza consapevole delle minacce.
ISO/IEC 27001:2022 fornisce il motore del sistema di gestione che collega queste aspettative. Le clausole 4.1 to 4.4 richiedono all’organizzazione di comprendere il proprio contesto interno ed esterno, le parti interessate, gli obblighi legali e normativi, il campo di applicazione del SGSI, le dipendenze e i processi interagenti. Le clausole 6.1.1 to 6.1.3 richiedono un processo ripetibile di valutazione del rischio e trattamento del rischio, selezione dei controlli, confronto con l’Allegato A, una dichiarazione di applicabilità, pianificazione del trattamento e approvazione del rischio residuo da parte del responsabile del rischio.
L’intelligence sulle minacce appartiene a questo contesto: non come dashboard laterale, ma come input per contesto, rischio, selezione dei controlli, trattamento, monitoraggio, riesame della direzione e miglioramento continuo.
La trappola della conformità: feed di minacce senza tracciabilità delle decisioni
Il modello di fallimento più comune è ingannevolmente semplice: l’organizzazione riceve intelligence sulle minacce ma non può dimostrare come questa modifichi le decisioni.
Una catena di evidenze debole di solito appare così:
| Segnale ricevuto | Risposta debole | Preoccupazione dell’auditor |
|---|---|---|
| Allerta CERT su sfruttamento attivo | Inoltrata alla casella IT | Nessuna evidenza di valutazione del rischio, responsabilità o azione |
| Bollettino del fornitore su patch critica | Aggiunto al backlog dei ticket | Nessuna prioritizzazione basata su criticità dell’asset o attività di exploit |
| Rilevamento MDR di riga di comando sospetta | Chiuso come falso positivo | Nessun criterio di triage documentato o ciclo di apprendimento |
| Comunicazione del fornitore su dipendenza compromessa | Archiviata nella cartella acquisti | Nessun aggiornamento del rischio dei fornitori o riesame dei controlli compensativi |
| Avviso ISAC su campagna di settore | Citato in una riunione SOC | Nessun aggiornamento del monitoraggio, della sensibilizzazione o dei playbook sugli incidenti |
È qui che il metodo di implementazione di Clarysec aiuta le organizzazioni a passare da “riceviamo informazioni” a “rendiamo operative le informazioni”.
In Zenith Blueprint: roadmap in 30 passi per auditor Zenith Blueprint, la fase Controls in Action trasforma esplicitamente l’intelligence sulle minacce in una pratica verificabile in audit. Lo Step 22, Controlli organizzativi, afferma:
Stabilire un elenco documentato delle fonti di intelligence sulle minacce (5.7), provenienti da fornitori, ISAC o fonti aperte, e determinare come l’intelligence sia validata e integrata nel processo decisionale. Definire chi riceve gli aggiornamenti sulle minacce e come vengono applicati, ad esempio per la prioritizzazione delle patch o per la formazione di sensibilizzazione. Creare un breve briefing sulle tendenze delle minacce da distribuire trimestralmente alle principali parti interessate.
Questa istruzione è il ponte tra i dati sulle minacce e le evidenze di conformità. Un registro dell’intelligence sulle minacce non è solo un elenco di fonti. Dimostra rilevanza, responsabilità, validazione, instradamento, integrazione e utilizzo aziendale.
Logica dei controlli ISO 27001: la catena dell’intelligence sulle minacce
Il controllo 5.7 di ISO/IEC 27002:2022, Threat intelligence, richiede alle organizzazioni di raccogliere e analizzare informazioni relative alle minacce alla sicurezza delle informazioni e di utilizzarle per produrre intelligence sulle minacce. In Zenith Controls: la guida cross-compliance Zenith Controls, il controllo 5.7 è classificato come preventivo, di rilevamento e correttivo. Supporta riservatezza, integrità e disponibilità, si allinea ai concetti di cibersicurezza Identify, Detect e Respond, e si colloca nella gestione di minacce e vulnerabilità come capacità operativa.
Questa classificazione è rilevante. L’intelligence sulle minacce previene orientando rafforzamento della configurazione, applicazione delle patch, formazione e controlli sui fornitori. Rileva modellando il monitoraggio, le regole SIEM e le attività di ricerca proattiva delle minacce. Corregge migliorando risposta agli incidenti, lezioni apprese e trattamento del rischio.
Zenith Controls mappa inoltre il controllo 5.7 di ISO/IEC 27002:2022 ai controlli di supporto:
| Relazione con il controllo ISO/IEC 27002:2022 | Perché è importante nella pratica |
|---|---|
| 5.6 Contatto con gruppi di interesse speciale | ISAC, CERT, forum professionali e comunità di settore sono fonti di intelligence, non semplici occasioni di networking |
| 8.7 Protezione dal malware | Indicatori di compromissione, URL malevoli, hash, infrastrutture command-and-control e pattern di attacco aggiornano le difese degli endpoint e della posta elettronica |
| 8.8 Gestione delle vulnerabilità tecniche | L’intelligence su exploit attivi nel mondo reale modifica la priorità delle vulnerabilità e l’urgenza delle patch |
| 8.15 Registrazione | I log forniscono la registrazione fattuale necessaria per cercare indicatori e ricostruire le attività |
| 8.16 Attività di monitoraggio | L’intelligence sulle minacce indica al SOC cosa monitorare, mentre il monitoraggio produce intelligence interna |
| 5.25 Valutazione e decisione sugli eventi di sicurezza delle informazioni | Il triage supportato da intelligence aiuta a decidere se un evento sia un incidente di sicurezza |
Il collegamento con le vulnerabilità è particolarmente importante. Zenith Controls considera il controllo 8.8, Gestione delle vulnerabilità tecniche, come preventivo e direttamente collegato al controllo 5.7 perché l’intelligence sulle minacce del mondo reale indica quali vulnerabilità sono attivamente sfruttate. Collega inoltre 8.8 a 8.16, Attività di monitoraggio, perché i tentativi di sfruttamento osservati devono aumentare l’urgenza delle patch.
Questo crea una catena pratica di intelligence sulle minacce:
- Arriva intelligence esterna o interna.
- La rilevanza viene validata rispetto ad asset, fornitori, area geografica, settore, servizi aziendali e dati.
- Il rischio viene aggiornato.
- Le priorità di patch e configurazione cambiano.
- La logica di rilevamento viene affinata.
- I playbook sugli incidenti e le soglie di classificazione vengono riesaminati.
- Le dipendenze da fornitori e cloud vengono verificate.
- La direzione riceve report sulle tendenze.
- Le evidenze vengono conservate per auditor, autorità di regolamentazione e clienti.
Politiche che trasformano l’intelligence in comportamenti responsabili
Le politiche sono il punto in cui la logica dei controlli diventa responsabilità basata sui ruoli. I set di politiche Clarysec per PMI e imprese includono riferimenti all’intelligence sulle minacce in gestione del rischio, protezione degli endpoint, gestione delle vulnerabilità, registrazione, monitoraggio ed evidenze di audit.
Per le PMI, la Protezione degli endpoint - Politica malware Protezione degli endpoint - Politica malware - PMI stabilisce un’aspettativa diretta nella clausola 5.4.1 dei Requisiti di governance:
Il fornitore del supporto IT deve monitorare fonti credibili di intelligence sulle minacce, ad esempio CISA, ENISA e i principali fornitori di antivirus, e garantire che le firme di rilevamento restino aggiornate
Il valore di questa clausola è l’assegnazione. L’intelligence sulle minacce non è “qualcuno in IT dovrebbe controllare le allerte”. È un obbligo esplicito del fornitore.
La Politica di gestione delle vulnerabilità e delle patch Politica di gestione delle vulnerabilità e delle patch - PMI rafforza lo stesso modello nella clausola 4.2.1 di Ruoli e responsabilità:
Monitora i sistemi per individuare vulnerabilità e patch disponibili utilizzando allerte dei fornitori, avvisi di intelligence sulle minacce e notifiche del sistema operativo
Identifica inoltre, nella clausola 6.2.1.3 dei Requisiti di applicazione della politica, il tipo di fonte che deve attivare un’azione:
Avvisi attendibili di intelligence sulle minacce, ad esempio CISA, ENISA e allerte dei CERT nazionali
Per le imprese, la Politica di gestione delle vulnerabilità e delle patch Politica di gestione delle vulnerabilità e delle patch afferma nella clausola 4.5.1 di Ruoli e responsabilità:
Monitorare gli avvisi sulle minacce, ad esempio CVE, CISA KEV e bollettini dei fornitori, ed effettuare l’escalation delle vulnerabilità critiche.
Il requisito di escalation è cruciale. Una vulnerabilità diventa urgente quando convergono sfruttabilità, esposizione, criticità aziendale, sensibilità dei dati e attività di minaccia.
La Politica di gestione del rischio Politica di gestione del rischio integra l’intelligence sulle minacce nell’analisi. La clausola 6.2.2 dei Requisiti di applicazione della politica afferma:
L’analisi deve considerare l’efficacia dei controlli esistenti, l’intelligence sulle minacce pertinente, la criticità degli asset e la gravità delle vulnerabilità.
Questa clausola è il cuore dell’intelligence sulle minacce pronta per l’audit. Dimostra che l’analisi del rischio non è teorica.
La Politica di registrazione e monitoraggio Politica di registrazione e monitoraggio trasforma l’intelligence in rilevamento. La clausola 1.2 sulla Finalità afferma:
La registrazione di audit, il monitoraggio e il rilevamento delle minacce sono essenziali per il rilevamento delle anomalie, la risposta alle minacce, il riesame forense, la capacità di dimostrare la conformità in sede di audit e la conformità legale. Questa politica garantisce che tutti gli eventi generati dai sistemi siano correttamente registrati, conservati e correlati con accuratezza sincronizzata temporalmente.
Infine, la Politica di audit e monitoraggio della conformità Politica di audit e monitoraggio della conformità spiega perché la disciplina delle evidenze è importante. La clausola 3.4 sugli Obiettivi richiede all’organizzazione di generare evidenze:
Generare evidenze sostenibili e una traccia di audit a supporto di richieste dell’autorità di regolamentazione, procedimenti legali o richieste di assurance dei clienti.
Quando NIS2, DORA, un cliente o un auditor ISO chiede cosa sapevate, quando lo sapevate, chi ha deciso e cosa è cambiato, questa traccia di evidenze distingue un’assurance matura da una rincorsa difensiva.
Costruire il registro dell’intelligence sulle minacce
Un registro maturo ha due livelli: governance delle fonti e tracciamento degli eventi. La governance delle fonti definisce ciò che l’organizzazione considera attendibile, chi ne è responsabile, come viene validato e quale azione può attivare.
| Nome della fonte | Tipo | Processo di validazione | Punto di integrazione | Responsabile |
|---|---|---|---|---|
| Catalogo CISA KEV | Operativo | Incrocio con inventario degli asset ed esposizione | Attivare la prioritizzazione delle patch di emergenza | Gestione delle vulnerabilità |
| Avvisi ENISA | Strategico | Riesame da parte del responsabile del rischio o del comitato rischi | Aggiornare scenari di rischio e briefing alla direzione | CISO |
| ISAC di settore | Tattico | Analizzare gli IOC per rilevanza rispetto allo stack tecnologico | Aggiornare SIEM, EDR e attività di ricerca proattiva delle minacce | Responsabile SOC |
| Bollettini dei provider cloud | Operativo | Verificare servizi e regioni interessati | Escalation al team di ingegneria cloud | Responsabile DevOps |
| Notifiche di patch dei fornitori | Operativo | Confermare prodotto, versione e ambito di deployment | Aggiungere al ciclo di patch o a una modifica di emergenza | Operations IT |
| Notifiche MDR | Tattico e operativo | Triage rispetto a log, asset e baseline note | Aprire un caso di rilevamento, indagine o incidente | Operazioni di sicurezza |
| Avvisi di sicurezza dei fornitori | Operativo | Mappare a servizi contrattualizzati e flussi di dati | Aggiornare rischio dei fornitori e controlli compensativi | Responsabile del fornitore |
Il tracciamento degli eventi cattura come uno specifico avviso sia diventato evidenza. Tornando allo scenario del martedì mattina sul trasferimento file, la voce del registro dovrebbe contenere informazioni sufficienti a supportare decisioni di rischio, risposta e conformità.
| Campo | Esempio di voce |
|---|---|
| Data e ora di ricezione | 2026-05-26 07:42 UTC |
| Fonte | Allerta CERT nazionale, bollettino del fornitore, notifica MDR |
| Tipo di fonte | Avviso governativo, avviso del fornitore, rilevamento interno |
| Tecnologia interessata | Servizio gestito di trasferimento file, intervallo di versioni, librerie dipendenti |
| Responsabile di business | Responsabile delle operazioni di piattaforma |
| Responsabile del rischio | CISO |
| Collegamento agli asset | Gateway esterno di trasferimento file, workflow di reportistica clienti |
| Gravità iniziale | Alta in attesa di validazione dell’esposizione |
| Azioni richieste | Verifica dell’esposizione, stato delle patch, riesame del rilevamento, conferma del fornitore |
| Rilevanza per la conformità | NIS2 Article 21, NIS2 Article 23 se sono soddisfatti i criteri di incidente significativo, ciclo di vita del rischio ICT e degli incidenti DORA se applicabile |
| Posizione delle evidenze | Ticket, aggiornamento del registro dei rischi, modifica SIEM, nota alla direzione |
Questa non è burocrazia. È la registrazione fattuale che dimostra che l’organizzazione dispone di un processo definito di acquisizione, validazione, triage, escalation ed evidenza.
Dall’avviso alle evidenze di audit: un flusso di lavoro pratico
Un flusso di lavoro di intelligence sulle minacce deve rispondere rapidamente a sei domande: siamo esposti, quanto è grave, cosa deve cambiare, chi ne è responsabile, dobbiamo segnalare e quali evidenze devono essere conservate?
1. Validare esposizione e impatto aziendale
Le clausole 4.1 to 4.4 di ISO/IEC 27001:2022 richiedono che il SGSI rifletta il contesto, gli obblighi e le dipendenze effettive dell’organizzazione. Il primo compito non è applicare patch alla cieca. È validare l’esposizione.
Chiedere:
- Eseguiamo la tecnologia interessata?
- È esposta a Internet?
- È utilizzata da un servizio aziendale critico?
- Tratta dati personali?
- È gestita da un fornitore o da un prestatore di servizi gestiti?
- È rilevante per una funzione critica o importante ai sensi di DORA?
- È rilevante per servizi nel campo di applicazione di NIS2?
- Esistono obblighi contrattuali di notifica verso i clienti?
- I log sono disponibili, completi e sincronizzati temporalmente?
Se possono essere interessati dati personali, anche la responsabilizzazione prevista dal GDPR entra nell’analisi. Il GDPR richiede un’adeguata sicurezza del trattamento e una responsabilizzazione dimostrabile, inclusa la capacità di valutare se si sia verificata una violazione dei dati personali e se sia richiesta una notifica.
2. Aggiornare il registro dei rischi
La Politica di gestione del rischio Politica di gestione del rischio - PMI fornisce una semplice regola temporale nella clausola 5.1.3 dei Requisiti di governance:
I rischi devono essere riesaminati trimestralmente e aggiornati quando si verificano eventi significativi.
Un avviso credibile di sfruttamento attivo è un evento significativo. L’aggiornamento non deve attendere il successivo riesame trimestrale.
| Elemento di rischio | Valutazione aggiornata |
|---|---|
| Minaccia | Sfruttamento attivo di una vulnerabilità del trasferimento file gestito |
| Vulnerabilità | Versione interessata, interfaccia esposta, configurazione debole, patch mancante |
| Asset | Piattaforma di scambio dati con i clienti |
| Conseguenza | Interruzione del servizio, accesso non autorizzato ai dati, segnalazione normativa, impatto sulla fiducia dei clienti |
| Probabilità | Aumentata a causa dello sfruttamento attivo nel mondo reale |
| Controlli esistenti | MFA, WAF, protezione degli endpoint, monitoraggio SIEM, backup, SLA del fornitore |
| Lacune nei controlli | Patch non confermata, rilevamento non affinato, evidenza del fornitore in sospeso |
| Trattamento | Patch di emergenza, restrizione temporanea di rete, ricerca IOC, attestazione del fornitore, valutazione dell’impatto sui clienti |
| Responsabile del rischio residuo | CISO e responsabile delle operazioni di piattaforma |
Questo si collega direttamente alle clausole 6.1.1-6.1.3 di ISO/IEC 27001:2022. L’organizzazione identifica il rischio, analizza probabilità e conseguenze, prioritizza il trattamento, seleziona i controlli, mantiene la dichiarazione di applicabilità, crea un piano di trattamento del rischio e ottiene l’approvazione del rischio residuo.
3. Prioritizzare il trattamento delle vulnerabilità usando l’intelligence sugli exploit
Lo Zenith Blueprint, fase Controls in Action, Step 19, Controlli tecnologici I, spiega perché la gestione delle vulnerabilità è igiene informatica essenziale:
Gestire le vulnerabilità è una delle aree più critiche della moderna igiene informatica. Sebbene firewall e strumenti antivirus forniscano protezione, possono essere vanificati se sistemi privi di patch o servizi configurati in modo errato restano esposti. Per soddisfare questo controllo, le organizzazioni dovrebbero attuare un processo strutturato e ripetibile per identificare, valutare e affrontare le vulnerabilità.
Il solo CVSS non basta. Una vulnerabilità con punteggio medio, ma sfruttata attivamente su un sistema esposto a Internet, può essere più urgente di una vulnerabilità con punteggio alto confinata in un laboratorio segmentato.
| Fattore | Domanda | Evidenza |
|---|---|---|
| Attività di exploit | Lo sfruttamento è osservato o segnalato da fonti attendibili? | Allerta CERT, riferimento CISA KEV, bollettino del fornitore, report MDR |
| Esposizione | L’asset è esposto a Internet o raggiungibile dai fornitori? | Inventario degli asset, livello di sicurezza cloud, scansione di rete |
| Criticità aziendale | Supporta servizi essenziali o funzioni critiche? | Business Impact Analysis, mappatura delle funzioni DORA |
| Sensibilità dei dati | Tratta dati personali, dati finanziari regolamentati o dati riservati dei clienti? | Inventario dei dati, DPIA, registrazioni dei trattamenti |
| Controlli compensativi | WAF, regole firewall, segmentazione, EDR o disabilitazione di funzionalità possono ridurre il rischio? | Richiesta di modifica, regola firewall, policy EDR |
| Rischio operativo | L’applicazione di patch di emergenza potrebbe interrompere l’erogazione di servizi critici? | Valutazione della modifica, piano di rollback, piano di continuità |
Questo produce una decisione sostenibile. Supporta inoltre NIS2 Article 21(2)(e) per il trattamento delle vulnerabilità, NIS2 Article 21(2)(g) per l’igiene informatica e le aspettative DORA in materia di gestione del rischio ICT.
4. Convertire l’intelligence in monitoraggio e rilevamento
L’intelligence sulle minacce deve arrivare alla registrazione e al monitoraggio. La Politica di registrazione e monitoraggio Politica di registrazione e monitoraggio - PMI afferma nella clausola 6.2.1 dei Requisiti di applicazione della politica:
Gli strumenti di sicurezza, ad esempio antivirus, firewall e VPN, devono essere configurati per generare allerte per scenari di minaccia definiti, tra cui:
L’estratto chiarisce l’intento del controllo: gli scenari di minaccia definiti devono guidare le allerte.
Lo Zenith Blueprint, fase Controls in Action, Step 19, descrive le attività di monitoraggio in questo modo:
Se la registrazione è l’atto di registrare ciò che accade nell’ambiente, il monitoraggio è l’atto di osservare, comprendere e rispondere a tali eventi. Questo controllo riguarda l’osservazione attiva di reti, sistemi e applicazioni per rilevare attività insolite, non solo a posteriori, ma in tempo reale o quasi reale, ove possibile.
Per lo scenario del trasferimento file, il SOC o il provider IT deve:
- Aggiungere o validare gli IOC provenienti dal CERT e dall’avviso del fornitore.
- Cercare nei log percorsi di exploit noti, caricamenti sospetti, indicatori di web shell, esecuzione insolita di processi e connessioni in uscita inattese.
- Confermare che log di autenticazione, attività amministrativa, accesso ai file, API e rete siano conservati.
- Affinare le allerte SIEM per il pattern di exploit.
- Creare una nota di caso che spieghi cosa è stato cercato, cosa è stato trovato e chi lo ha riesaminato.
- Effettuare l’escalation alla classificazione dell’incidente se gli indicatori mostrano compromissione, esposizione dei dati o impatto sul servizio.
È qui che la segnalazione degli incidenti diventa pratica. NIS2 Article 23 richiede una segnalazione graduale degli incidenti significativi, inclusa un’allerta precoce entro 24 ore, una notifica entro 72 ore, aggiornamenti intermedi su richiesta e un rapporto finale non oltre un mese dalla notifica. DORA richiede agli enti finanziari di rilevare, gestire, classificare e segnalare incidenti rilevanti connessi all’ICT attraverso il processo graduale definito dal regolamento e dai relativi standard tecnici.
L’intelligence sulle minacce aiuta a determinare se l’organizzazione si trova ancora nella risposta alla vulnerabilità, nella valutazione di un evento di sicurezza o nella segnalazione regolamentata di un incidente.
Un solo flusso di lavoro, più obblighi di conformità
L’intelligence sulle minacce è un flusso di lavoro ideale di conformità integrata perché le stesse evidenze supportano più regimi.
| Quadro di riferimento o normativa | Cosa richiede | Evidenze di intelligence sulle minacce |
|---|---|---|
| ISO/IEC 27001:2022 | SGSI consapevole del contesto, valutazione del rischio, selezione dei controlli, pianificazione del trattamento, miglioramento continuo | Campo di applicazione del SGSI, registro dei rischi, dichiarazione di applicabilità, piano di trattamento del rischio, input al riesame della direzione |
| ISO/IEC 27002:2022 | Intelligence sulle minacce, gestione delle vulnerabilità, registrazione, monitoraggio, valutazione degli incidenti, protezione antimalware | Registro dell’intelligence sulle minacce, aggiornamenti IOC, regole SIEM, ticket di patch, note di triage degli incidenti |
| NIS2 | Gestione del rischio, gestione degli incidenti, igiene informatica, trattamento delle vulnerabilità, sicurezza della catena di fornitura, supervisione della governance | Evidenze Article 20 e 21, briefing alla direzione, flusso di lavoro CSIRT, follow-up sugli avvisi dei fornitori |
| DORA | Quadro del rischio ICT, rilevamento, continuità, ciclo di vita degli incidenti, test di resilienza, rischio ICT di terze parti | Classificazione degli asset ICT, casi di rilevamento, registrazioni di classificazione degli incidenti, input ai test di resilienza, registrazioni dei fornitori ICT |
| GDPR | Sicurezza del trattamento, responsabilizzazione, supporto a rilevamento e notifica delle violazioni | Valutazione d’impatto sui dati, log degli accessi, evidenze di monitoraggio, registrazione della valutazione della violazione |
| NIST CSF 2.0 | Esiti Govern, Identify, Protect, Detect, Respond, Recover | Profilo attuale, profilo target, piano d’azione prioritizzato, comunicazioni sul rischio |
| Prospettiva di audit COBIT 2019 | Governance su rischio, controlli, prestazione, assurance e responsabilità | Titolarità del controllo, metriche di gestione, evidenze di assurance, tracciamento della correzione degli issue |
NIST CSF 2.0 è particolarmente utile per la comunicazione esecutiva. Le sue funzioni core, Govern, Identify, Protect, Detect, Respond e Recover, trasformano l’intelligence tecnica in una narrazione comprensibile dal consiglio di amministrazione:
- Govern: fonti, responsabili e linee di reporting dell’intelligence sulle minacce sono definiti.
- Identify: asset, fornitori, servizi aziendali e dati interessati sono mappati.
- Protect: patching, rafforzamento della configurazione, segmentazione e firme degli endpoint sono aggiornati.
- Detect: regole di monitoraggio, IOC e attività di ricerca proattiva delle minacce sono distribuiti.
- Respond: playbook sugli incidenti, regole di triage e soglie di notifica sono riesaminati.
- Recover: backup, priorità di ripristino e lezioni apprese sono validati.
Questo trasforma la cyber threat intelligence grezza in governance del rischio.
La prospettiva dell’auditor: cosa chiederà
Un processo solido di intelligence sulle minacce dovrebbe reggere a diversi stili di audit. Un auditor ISO, un revisore NIS2, un’autorità di controllo DORA, un valutatore NIST CSF, un auditor orientato a COBIT 2019, un professionista ISACA o un revisore privacy possono usare linguaggi diversi, ma convergono tutti sulle evidenze.
| Prospettiva dell’auditor | Probabile domanda di audit | Evidenza che risponde |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | In che modo il contesto esterno e interno influenza i rischi e i controlli del SGSI? | Registro dell’intelligence sulle minacce, metodologia del rischio, registro dei rischi aggiornato, razionale della dichiarazione di applicabilità |
| Revisore dei controlli ISO/IEC 27002:2022 | Come sono collegati i controlli 5.7, 8.8, 8.16, 8.15, 8.7 e 5.25? | Elenco delle fonti, triage delle vulnerabilità, tuning SIEM, aggiornamenti delle firme malware, registrazioni di valutazione degli eventi |
| Revisore NIS2 | Come soddisfate supervisione della direzione, igiene informatica, trattamento delle vulnerabilità, gestione degli incidenti e sicurezza della catena di fornitura? | Mappatura Article 20 e 21, briefing alla direzione, procedura di reporting CSIRT, flusso di lavoro sugli avvisi dei fornitori |
| Autorità di controllo DORA | In che modo l’intelligence sulle minacce aggiorna rischio ICT, rilevamento, test di resilienza e classificazione degli incidenti? | Quadro del rischio ICT, mappatura delle funzioni critiche, casi di rilevamento, registrazioni di classificazione degli incidenti, ambito dei test di resilienza |
| Valutatore NIST CSF | Quali sono il profilo attuale, il profilo target e il piano d’azione prioritizzato? | Profilo CSF, valutazione degli scostamenti, piano d’azione, log di aggiornamento continuo |
| Auditor COBIT 2019 o ISACA | Chi è responsabile del controllo, come viene misurata la prestazione e come sono corrette le eccezioni? | RACI, KPI, KRI, registro delle eccezioni, ticket di correzione, approvazione della direzione |
| Auditor GDPR o revisore privacy | In che modo monitoraggio e gestione delle vulnerabilità hanno protetto i dati personali e supportato la valutazione della violazione? | Mappa dei trattamenti, log, valutazione della violazione, evidenze delle misure tecniche e organizzative |
Zenith Controls fornisce l’interpretazione cross-compliance per queste discussioni. Per il controllo 8.16, Attività di monitoraggio, la guida collega il monitoraggio alla sicurezza GDPR e alla responsabilizzazione in caso di violazione, alla gestione degli incidenti e alla segnalazione NIS2, nonché alle aspettative DORA di rilevamento e risposta. Per il controllo 8.8, Gestione delle vulnerabilità tecniche, collega il trattamento delle vulnerabilità alla sicurezza del trattamento GDPR, a NIS2 Article 21(2)(e) e alla gestione proattiva del rischio ICT DORA.
Questa è la convergenza delle evidenze che gli auditor vogliono vedere.
Reportistica alla direzione: il briefing trimestrale sulle tendenze delle minacce
Il registro dell’intelligence sulle minacce non dovrebbe morire nel SOC. Lo Zenith Blueprint raccomanda un breve briefing trimestrale sulle tendenze delle minacce per le principali parti interessate. Clarysec raccomanda un report di una pagina alla direzione con cinque sezioni:
- Le tre principali tendenze di minaccia rilevanti per impatto aziendale.
- Le tecnologie o i fornitori più esposti.
- Vulnerabilità critiche corrette, mitigate o accettate.
- Miglioramenti apportati al rilevamento e alla risposta.
- Decisioni richieste alla direzione.
Un briefing efficace alla direzione non elenca 400 CVE. Spiega il movimento del rischio. Ad esempio:
- Il ransomware contro prestatori di servizi gestiti ha aumentato la priorità dei riesami dei fornitori.
- Lo sfruttamento di piattaforme di trasferimento file ha attivato patch di emergenza e una regola firewall compensativa.
- Gli attacchi alle identità cloud hanno causato il riesame delle eccezioni MFA e il rafforzamento dell’accesso condizionale.
- L’intelligence dell’ISAC di settore ha portato a nuove simulazioni di phishing per i team finanza e supporto.
- La mappatura delle funzioni critiche DORA ha rivelato una lacuna di monitoraggio in un flusso di lavoro di terze parti.
Questo briefing supporta la responsabilità della direzione NIS2, la governance del rischio ICT DORA, il riesame della direzione ISO/IEC 27001:2022 e l’assurance dei clienti.
Modelli di fallimento comuni
I programmi di intelligence sulle minacce spesso appaiono maturi nelle presentazioni, ma deboli in audit. I modelli di fallimento più comuni sono:
- Troppi feed e nessun criterio di validazione.
- Nessun collegamento tra intelligence e inventario degli asset.
- Nessun aggiornamento documentato del rischio dopo avvisi rilevanti.
- Priorità delle patch basata solo sulla gravità dello scanner.
- Avvisi dei fornitori gestiti al di fuori del SGSI.
- Regole SOC aggiornate senza registrazioni delle modifiche.
- Soglie di incidente non allineate ai flussi di reporting NIS2 o DORA.
- Reportistica al consiglio concentrata sul volume delle allerte invece che sul rischio aziendale.
- Nessuna evidenza che le lezioni apprese abbiano modificato i controlli.
- Nessun responsabile per il mantenimento del registro dell’intelligence sulle minacce.
La soluzione non è acquistare un altro feed. La soluzione è l’integrazione dei controlli.
Checklist di preparazione in 10 punti per il 2026
Utilizzare questa checklist come riesame interno pratico.
| Domanda di preparazione | Sì o no |
|---|---|
| Manteniamo un registro approvato dell’intelligence sulle minacce con responsabili delle fonti e regole di validazione? | |
| Gli avvisi CERT, CSIRT, ISAC, dei fornitori, cloud, MDR e dei fornitori terzi sono instradati a ruoli nominativi? | |
| Gli avvisi significativi attivano un riesame del registro dei rischi al di fuori del ciclo trimestrale? | |
| La prioritizzazione delle vulnerabilità include attività di exploit, criticità degli asset, sensibilità dei dati ed esposizione? | |
| Gli IOC e gli scenari di minaccia vengono convertiti in regole di monitoraggio o attività di ricerca proattiva delle minacce? | |
| Le firme degli endpoint, i rilevamenti cloud e i feed dinamici di intelligence sulle minacce sono verificati quanto ad aggiornamento? | |
| Le comunicazioni dei fornitori sono valutate rispetto al rischio della catena di fornitura e agli obblighi contrattuali? | |
| I criteri di classificazione degli incidenti sono allineati ai flussi di reporting NIS2 e DORA ove applicabile? | |
| La direzione riceve un briefing trimestrale sulle tendenze delle minacce? | |
| Possiamo produrre un pacchetto di evidenze per un auditor, un’autorità di regolamentazione o un cliente entro un giorno lavorativo? |
Se la risposta a una di queste domande è “no”, l’organizzazione non ha semplicemente un problema di intelligence sulle minacce. Ha un problema di integrazione del SGSI.
Come Clarysec aiuta a trasformare l’intelligence sulle minacce in evidenze
Il metodo Clarysec è progettato per organizzazioni che hanno bisogno allo stesso tempo di sicurezza pratica e conformità credibile.
Zenith Blueprint fornisce il percorso di implementazione in 30 passi, inclusi lo Step 22 per il registro dell’intelligence sulle minacce e lo Step 19 per gestione delle vulnerabilità e attività di monitoraggio. Le politiche Clarysec per imprese e PMI trasformano queste aspettative in procedure basate sui ruoli per gestione del rischio, trattamento delle vulnerabilità, protezione degli endpoint, registrazione, monitoraggio ed evidenze di audit. Zenith Controls fornisce quindi l’interpretazione cross-compliance, mostrando come i controlli ISO/IEC 27002:2022 si collegano a NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 ed evidenze di audit.
Per il CISO del martedì mattina, la risposta al CFO diventa chiara:
“Abbiamo ricevuto l’avviso, validato l’esposizione, aggiornato il registro dei rischi, prioritizzato le patch sulla base dello sfruttamento attivo, affinato il monitoraggio, verificato la dipendenza dal fornitore, valutato le soglie di segnalazione degli incidenti, informato la direzione e conservato le evidenze. Non stiamo tirando a indovinare. Stiamo seguendo il nostro SGSI.”
Questo è l’aspetto che dovrebbe avere nel 2026 l’intelligence sulle minacce ISO 27001 per l’igiene informatica NIS2 e le evidenze di rischio ICT DORA.
Prossimi passi
Se la vostra organizzazione riceve intelligence sulle minacce ma non può dimostrare come questa modifichi decisioni di rischio, controlli, rilevamento, risposta agli incidenti, gestione dei fornitori ed evidenze normative, iniziate questa settimana con tre azioni:
- Costruire o aggiornare il registro dell’intelligence sulle minacce usando Zenith Blueprint, fase Controls in Action, Step 22.
- Mappare il processo attuale rispetto ai controlli ISO/IEC 27002:2022 5.7, 8.8, 8.15, 8.16, 8.7 e 5.25 usando Zenith Controls.
- Allineare le politiche, in particolare Politica di gestione del rischio, Politica di gestione delle vulnerabilità e delle patch, Politica di registrazione e monitoraggio e Politica di audit e monitoraggio della conformità, affinché ogni avviso possa diventare evidenza sostenibile.
Clarysec può aiutarvi a trasformare feed di minacce, avvisi, comunicazioni dei fornitori, intelligence sulle vulnerabilità e segnali di rilevamento in un modello operativo allineato a ISO/IEC 27001:2022, pronto per NIS2 e consapevole di DORA.
Scaricate i toolkit Clarysec, richiedete una sessione guidata o prenotate una valutazione di preparazione per verificare come il vostro attuale processo di intelligence sulle minacce reggerebbe davanti a un auditor ISO, un revisore NIS2, un’autorità di controllo DORA o una richiesta di assurance da parte di un cliente.
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
