Ivanti Blog: Post di

Trusted Ownership: come Ivanti Application Control va oltre l'allowlisting

Wed, 25 Feb 2026 14:25:15 Z

Il controllo applicazioni è uno di quei temi di sicurezza su cui molte persone conservano vecchie convinzioni. L'allowlisting tradizionale sembra sicuro, ma diventa rapidamente un onere di manutenzione. Il blocklisting appare reattivo e incompleto. E se strumenti come Microsoft AppLocker hanno portato molti a credere che un allowlisting rigoroso sia lo standard di riferimento, gli attacchi moderni hanno dimostrato il contrario. Gli attaccanti si affidano sempre più a strumenti legittimi e firmati — utilizzati nel contesto sbagliato — per aggirare completamente i controlli basati su elenchi.

Quando quindi le organizzazioni valutano Ivanti Application Control o Ivanti Neurons for App Control e incontrano Trusted Ownership, inizialmente potrebbe sembrare simile al blocklisting, perché sono possibili blocchi espliciti. In realtà, Trusted Ownership è un modello di applicazione molto più ampio e molto più leggero dal punto di vista operativo, ispirato alla provenienza, che controlla l'esecuzione in base all'origine, non solo all'identità.

Invece di gestire elenchi in continua crescita, applica la sicurezza in base a chi ha inserito il software nel sistema, allineandosi in modo naturale alle moderne pratiche di distribuzione del software e ai principi zero trust. È più corretto considerarlo non come un ulteriore meccanismo basato su elenchi, ma come un modello di applicazione ispirato alla provenienza che controlla l'esecuzione in base all'origine, non solo all'identità.

Questo cambio di prospettiva porta a una domanda più efficace per il controllo applicazioni moderno: non solo che cosa sia un file, ma come sia arrivato lì.

Oltre gli elenchi: perché il controllo della provenienza oggi è importante

La domanda su come un file sia arrivato sul sistema è al centro del controllo della provenienza. Invece di considerare attendibili i file solo in base a editore, percorso o hash, il controllo della provenienza valuta l'origine e il processo che li hanno introdotti. Chi ha scritto il file su disco? Attraverso quale meccanismo? L'installazione ha seguito un workflow IT controllato? Questa valutazione sposta il controllo applicazioni dalla fiducia nell'oggetto alla fiducia nel processo, creando un perimetro di sicurezza molto più solido.

In Ivanti Application Control, il controllo della provenienza viene implementato come Trusted Ownership. Qualsiasi file inserito da un proprietario attendibile viene consentito; qualsiasi elemento introdotto da un utente viene negato per impostazione predefinita. Questo vale in modo coerente per eseguibili, DLL, programmi di installazione e script. Poiché identità come SYSTEM, TrustedInstaller e Administrators sono attendibili per impostazione predefinita, il software distribuito tramite canali di deployment standard come MS Intune, MECM, Ivanti Endpoint Manager (EPM) o altri strumenti enterprise viene eseguito immediatamente, senza manutenzione delle regole o eccezioni.

Questo rappresenta una rottura fondamentale rispetto all'allowlisting classico. Le regole di AppLocker dipendono da definizioni esatte di editore, percorso o hash. Non valuta l'origine dell'installazione e non considera automaticamente attendibili i meccanismi di deployment. Il software distribuito da Intune richiede comunque una regola di autorizzazione preesistente, spesso basata su impostazioni predefinite ampie che consentono le directory Program Files o Windows.

Questa distinzione è importante perché gli attacchi moderni trasformano sempre più spesso strumenti legittimi in armi, usandoli in contesti impropri. Il controllo della provenienza neutralizza gran parte di questo rischio applicando la fiducia a come arriva il software, non solo a che cosa sia. Si allinea ai principi zero trust, riduce l'esposizione della supply chain e restringe drasticamente, per impostazione predefinita, le opportunità di abuso Living off the Land (LotL).

Una volta compresa l'importanza dell'origine, la domanda successiva diventa: come applicarla su larga scala?

La risposta: applicare la provenienza in modo coerente a tutti i modi in cui il software viene eseguito e a tutti i modi in cui viene distribuito.

Oltre le blocklist: una copertura ampia progettata per il deployment software moderno

Il controllo della provenienza sposta la sicurezza applicativa dalla gestione di elenchi interminabili alla convalida del processo con cui il software arriva sul sistema. Una volta adottata questa prospettiva, diventa chiaro che Trusted Ownership non è un approccio basato su blocklist. È un perimetro di fiducia basato sull'origine, che si comporta in modo molto diverso dall'allowlisting tradizionale.

Un equivoco comune è che Trusted Ownership assomigli al blocklisting perché gli amministratori a volte aggiungono regole di negazione mirate per strumenti Windows noti. In pratica, queste regole di negazione sono misure di hardening difensivo contro le tecniche Living off the Land. Ogni metodo serio di controllo applicazioni utilizza restrizioni mirate di questo tipo. Il nucleo di Trusted Ownership è l'opposto del blocklisting. Il software distribuito tramite un processo controllato e attendibile è consentito per impostazione predefinita, mentre il contenuto introdotto dall'utente è negato per impostazione predefinita.

Un elemento di differenziazione più importante è la copertura. Molte organizzazioni che si affidano agli allowlist classici finiscono per concentrarsi quasi esclusivamente sui file eseguibili. Spesso evitano di applicare lo stesso controllo a DLL, script e pacchetti MSI perché questi tipi di file rendono la manutenzione delle regole molto più complessa. Questo crea lacune che gli attaccanti moderni sfruttano di frequente.

Trusted Ownership evita queste lacune applicando lo stesso controllo basato sull'origine all'intera catena di esecuzione. Eseguibili, DLL, script, programmi di installazione MSI e componenti correlati vengono valutati attraverso lo stesso modello di fiducia. Poiché la fiducia è determinata da chi ha introdotto il file, non servono criteri separati per ogni tipo di file. Uno script nella cartella Download, una DLL creata in una directory di build temporanea o un EXE eseguito da un profilo utente ricevono tutti lo stesso trattamento di negazione predefinita quando hanno origine al di fuori di un processo di installazione controllato.

Questo modello di fiducia si allinea inoltre in modo naturale al modo in cui le moderne piattaforme di gestione degli endpoint distribuiscono il software. Soluzioni come Intune, MECM, Ivanti Neurons for MDM, Ivanti Endpoint Manager e sistemi simili installano in genere le applicazioni utilizzando l'identità SYSTEM o un altro account di servizio attendibile.

Poiché queste identità sono già Trusted Owner, il software distribuito tramite questi canali viene eseguito immediatamente senza creare regole di autorizzazione, mantenere percorsi file o aggiornare criteri. Solo quando si utilizzano intenzionalmente account di installazione alternativi, come agenti DevOps personalizzati o installazioni tramite script nel contesto utente, è necessario identificare tale identità come Trusted Owner.

Il risultato è un modello con una copertura ampia e coerente su tutti i tipi di file rilevanti. Funziona senza interruzioni con le moderne distribuzioni software ed evita l'overhead operativo associato agli allowlist classici, che si concentrano principalmente sui file eseguibili.

Trusted Ownership colloca la fiducia non nei singoli oggetti, ma nei processi controllati attraverso cui il software viene distribuito, creando un approccio al controllo applicazioni più scalabile e più sicuro.

Il ruolo di WDAC (App Control for Business)

Microsoft mantiene due tecnologie di controllo applicazioni: AppLocker e App Control for Business (in precedenza WDAC). Sebbene entrambe esistano ancora, Microsoft è chiara sui rispettivi ruoli. AppLocker aiuta a impedire agli utenti di eseguire applicazioni non approvate, ma non soddisfa i criteri di manutenzione per le funzionalità di sicurezza moderne ed è quindi classificato come meccanismo di difesa in profondità piuttosto che come controllo di sicurezza strategico.

La direzione futura di Microsoft per il controllo applicazioni è App Control for Business e Microsoft afferma esplicitamente che AppLocker è feature-complete e non è più in sviluppo attivo, oltre agli aggiornamenti di sicurezza essenziali. Ciò significa che tutte le nuove funzionalità vengono fornite solo in WDAC e non in AppLocker.

App Control for Business introduce il concetto di Managed Installer. Questo consente a Windows di considerare automaticamente attendibili le applicazioni installate tramite piattaforme di deployment designate, come Intune o MECM. La fiducia deriva dal canale di distribuzione anziché dai singoli file, riducendo in modo significativo la manutenzione delle regole.

Questo si allinea strettamente al modello Trusted Ownership di Ivanti Application Control. Entrambi gli approcci considerano attendibile il software in base al processo controllato che lo ha installato, anziché in base ad attributi discreti dei file. Tuttavia, Trusted Ownership applica questo concetto in modo più semplice e più accessibile dal punto di vista operativo. Ivanti considera attendibili identità come SYSTEM e gli account di servizio designati, senza richiedere livelli di policy complessi, definizioni XML o competenze approfondite su WDAC.

Ivanti sente da molte organizzazioni che l'operatività di WDAC è complessa. I criteri WDAC richiedono una progettazione attenta, test prolungati in modalità audit, gestione delle eccezioni per driver e kernel e manutenzione continua di più set di criteri. Questo spesso porta le organizzazioni a combinare WDAC con AppLocker per coprire sia l'applicazione a basso livello sia il controllo quotidiano dello spazio utente, finendo per generare overhead amministrativo.

Ivanti Application Control offre un'alternativa unificata. Attraverso Trusted Ownership, Trusted Vendors e la convalida delle firme digitali, fornisce un modello di negazione predefinita basato sulla provenienza, con copertura coerente su eseguibili, DLL, script e pacchetti MSI.

Invece di mantenere due piani di controllo Microsoft con ambiti diversi, le organizzazioni gestiscono un unico criterio semplificato che applica la fiducia in base a come il software viene introdotto nel sistema. Questo consente di raggiungere molti degli obiettivi pratici che i clienti cercano di ottenere con un deployment combinato di WDAC e AppLocker, ma con minore complessità operativa e un modello di fiducia coerente.

LOLBins e controllo a livello di argomenti

Una volta stabilita una copertura ampia, il tema diventa come gestire gli strumenti legittimi già presenti su ogni macchina, che gli attaccanti amano sfruttare.

Gli attaccanti moderni spesso evitano di utilizzare malware tradizionale e si affidano invece agli strumenti già presenti su ogni dispositivo Windows. Questi strumenti Living off the Land (LOLBins) sono legittimi e necessari per le normali operazioni, il che li rende difficili da bloccare senza incidere sulla produttività. L'allowlisting tradizionale fatica in questo contesto, perché blocchi troppo ampi interrompono i workflow, mentre autorizzazioni troppo ampie lasciano pericolose lacune.

Un modello basato sulla provenienza come Trusted Ownership cambia questa dinamica. Anche se un attaccante tenta di utilizzare uno strumento integrato, il contenuto che prova a eseguire di solito non proviene da un processo di installazione attendibile. Poiché Ivanti valuta l'origine di quel contenuto, la maggior parte dei tentativi di uso improprio fallisce automaticamente. Lo strumento può essere legittimo, ma il contenuto che gli viene chiesto di eseguire non lo è, e Trusted Ownership lo blocca prima dell'esecuzione.

È importante capire non solo quali strumenti vengono eseguiti, ma anche che cosa viene chiesto loro di fare. Molti interpreti e runtime, come PowerShell, Python o Java, possono essere perfettamente sicuri in un contesto e rischiosi in un altro. Un'applicazione aziendale può basarsi su Java per avviare un processo specifico e approvato, mentre un file JAR scaricato da un utente rappresenta uno scenario completamente diverso.

Ivanti gestisce questo aspetto con un approccio a livelli. Un file JAR viene prima valutato tramite Trusted Ownership, che lo blocca immediatamente se è stato introdotto da un utente anziché tramite un processo di deployment controllato. Oltre a questo, gli amministratori possono creare semplici regole di autorizzazione che specificano esattamente quali comandi Java sono consentiti, garantendo che vengano eseguite solo applicazioni basate su Java legittime, mentre i tentativi di avviare file JAR non approvati vengono negati in modo silenzioso.

Lo stesso principio si applica anche ad altri strumenti. I criteri possono approvare il comportamento esatto di cui l'organizzazione ha bisogno, bloccando al contempo le attività che escono da quei limiti. Questo evita regole ampie e fragili e mantiene fluido il lavoro quotidiano.

Il risultato è un approccio equilibrato e moderno. Trusted Ownership blocca per impostazione predefinita i contenuti non attendibili. L'hardening mirato si allinea alle best practice governative e della community per ridurre gli abusi living off the land, mentre i controlli consapevoli dell'intento assicurano che i processi legittimi continuino a funzionare senza aprire porte agli attaccanti.

Questo approccio è strettamente allineato alle attuali linee guida della community e degli enti governativi sulla mitigazione delle tecniche living off the land. Agenzie come CISA, NSA, FBI e l'Australian Cyber Security Centre sottolineano l'importanza di ridurre le opportunità per gli attaccanti di usare strumenti integrati, controllando come vengono utilizzati e limitando i contenuti non attendibili su cui operano. Le loro linee guida congiunte evidenziano che gli attacchi LOTL dipendono dall'abuso di strumenti nativi e sottolineano la necessità di controlli che limitino questo uso improprio senza bloccare i processi di sistema legittimi.

Il modello di Ivanti riflette queste linee guida. Trusted Ownership blocca automaticamente i contenuti non attendibili su cui gli attaccanti fanno affidamento, mentre un numero limitato di restrizioni mirate interviene sul piccolo insieme di strumenti che richiede particolare attenzione.

Trusted Ownership in azione: scenari reali

Ecco alcuni esempi operativi di come Ivanti Application Control e Trusted Ownership funzionano nella pratica.

Un'applicazione portatile viene copiata nel profilo utente. Ivanti la blocca perché è di proprietà dell'utente. AppLocker la blocca solo se esistono regole corrispondenti. Senza le regole di percorso o editore corrette, il comportamento può variare.
Un allegato email avvia uno script PowerShell dalla cartella Download. Ivanti lo nega a causa della proprietà utente. AppLocker dipende dalle regole sugli script e, in caso di eventi di blocco, forza PowerShell in Constrained Language Mode, che eseguirà comunque lo script.
Abuso di strumenti del sistema operativo come rundll32 o mshta. Entrambi i modelli richiedono un hardening di negazione mirato. Ivanti lo combina con il controllo della provenienza, che in genere riduce il numero di eccezioni necessarie. AppLocker si basa su set di negazione curati e richiede una regolazione periodica.
Un aggiornamento di un fornitore distribuisce nuovi file firmati. Ivanti consente l'aggiornamento quando arriva tramite il canale di deployment attendibile grazie a Trusted Ownership. AppLocker può gestire questo caso con regole basate sull'editore, ma il riutilizzo della firma su più prodotti o percorsi di installazione insoliti spesso comporta manutenzione aggiuntiva e una fiducia più ampia del previsto.
Un utente scarica un file JAR e tenta di eseguirlo con Java. Ivanti blocca il tentativo perché il JAR è introdotto dall'utente e non supera Trusted Ownership. Se necessario, gli amministratori possono consentire solo l'invocazione approvata esatta confrontando l'intera riga di comando. AppLocker non può confrontare gli argomenti e si basa su regole di editore, percorso o hash.

Conclusione

Il controllo della provenienza sposta il controllo applicazioni da un problema di gestione a un modello di fiducia. Invece di considerare attendibili i singoli file, considera attendibile il processo con cui il software arriva su un sistema, rendendo la sicurezza sia scalabile sia praticabile.

Trusted Ownership si inserisce pienamente in questo approccio. Non è né una blocklist né un allowlist classico, ma un modello in cui il software che arriva tramite un processo IT controllato è consentito per impostazione predefinita, mentre tutto ciò che resta fuori da quel processo viene negato per impostazione predefinita. Applicando i controlli sull'origine e sulla proprietà anziché su file ad hoc, Ivanti Application Control e Ivanti Neurons for App Control si allineano molto meglio alle tecniche di attacco moderne e all'attuale distribuzione del software.

Se si continua a trattare il controllo applicazioni come un esercizio di gestione degli elenchi, l'onere amministrativo si farà sentire. Se lo si considera come un perimetro di fiducia, si ottengono scalabilità, sicurezza e praticabilità operativa.

5 motivi per cui la preparazione alla Direttiva NIS2 dovrebbe iniziare ora, parte due: l'implementazione richiede tempo

Mon, 28 Aug 2023 17:43:02 Z

In un precedente post del blog, ho analizzato le due principali aree da sottoporre ad audit prima che la Direttiva sulla sicurezza delle reti e dei sistemi informativi (NIS2) aggiornata dell'Unione europea venga recepita come legge nell'ottobre 2024. Nello specifico, questi audit servirebbero a:

Identificare fin da subito le lacune rispetto ai requisiti della Direttiva NIS2.

Analizzare le attuali criticità di sicurezza della supply chain.

Ora che abbiamo individuato queste criticità di sicurezza, dobbiamo risolverle prima che il tempo a disposizione scada nell'ottobre 2024.

In questo post, quindi, vedremo come affrontare i punti più deboli della vostra sicurezza prima della scadenza della Direttiva NIS2, intervenendo su tre aree chiave:

Informare il management sulle lacune di cybersecurity
Implementare correttamente nuove misure di sicurezza organizzative e tecniche
Trovare il tempo per formare tutti i dipendenti

1. Informare il management sulle lacune e ottenere il budget per colmarle

La Direttiva NIS2 impone obblighi significativi alle organizzazioni che rientrano nel suo ambito di applicazione, con possibili costi e risorse rilevanti. La Direttiva introduce inoltre multe e sanzioni pesanti in caso di non conformità, fino a un massimo di 10 milioni di euro o del 2% del fatturato annuo globale dell'organizzazione (Articolo 34).

Inoltre, in determinate situazioni la nuova Direttiva può estendere la responsabilità dagli enti ai loro rappresentanti individuali. Quando vengono soddisfatte determinate condizioni, le persone in posizioni dirigenziali potrebbero anche essere sospese temporaneamente (Articolo 32-5b).

Pertanto, rispettare la Direttiva NIS2 è una necessità legale e una priorità strategica.

Per essere conformi, è necessario:

Informare il management sulle implicazioni e sui vantaggi della Direttiva e convincerlo ad allocare budget e risorse sufficienti per implementare la conformità.
Presentare un business case chiaro che illustri i rischi della non conformità, le opportunità della conformità e il ritorno sull'investimento.
Dimostrare in che modo la conformità migliorerà reputazione, affidabilità, competitività e resilienza della vostra organizzazione.

Informare il management e ottenere un budget è un compito impegnativo, che richiede un'argomentazione persuasiva e basata su evidenze per dimostrare il valore della cybersecurity per la vostra organizzazione.

Prima avvierete questo processo, più tempo avrete per ottenere il consenso e il supporto del management.

Possibili vantaggi di business case per la conformità alla NIS2

Tra i possibili vantaggi da evidenziare nel business case rientrano:

Ridurre i costi operativi prevenendo o minimizzando le perdite dovute agli attacchi informatici, come downtime, violazioni dei dati, pagamenti di riscatti, cause legali e così via.
Aumentare i ricavi attirando o fidelizzando clienti che attribuiscono valore a sicurezza, privacy, qualità e altri aspetti.
Migliorare l'efficienza semplificando i processi, migliorando le prestazioni, riducendo gli errori e così via.
Innovare adottando nuove tecnologie, sviluppando nuovi prodotti o servizi, creando nuovi mercati e altro ancora.
Rispettare altre normative o standard di cybersecurity oltre alla NIS2 – come GDPR, ISO 27001, PCI DSS e altri – poiché i framework globali spesso presentano un'elevata sovrapposizione con i requisiti di conformità della NIS2.

Potenziali fonti di informazioni per giustificare il business case di conformità alla NIS2

Alcune fonti che potete utilizzare a supporto del business case sono:

Statistiche o dati di fatto che mostrino la diffusione, l'impatto o il costo degli attacchi informatici nel vostro settore o nella vostra area geografica.
Casi di studio o esempi che illustrino in che modo altre organizzazioni hanno tratto vantaggio dalla conformità alla Direttiva NIS2 o a normative simili. Ad esempio, il report Enisa NIS Investments 2022 mostra che, per il 62% delle organizzazioni che hanno implementato la precedente Direttiva NIS, tali implementazioni le hanno aiutate a rilevare gli incidenti di sicurezza; per il 21%, le implementazioni hanno supportato il ripristino a seguito di incidenti di sicurezza.
Testimonianze o feedback di clienti, partner, autorità di regolamentazione o esperti che sostengono o raccomandano la conformità alla Direttiva NIS2 o a normative simili.
Benchmark o indicatori che evidenzino le vostre prestazioni o i vostri progressi attuali o previsti in materia di cybersecurity rispetto alla Direttiva NIS2 o ai concorrenti.
Cyberstrategy Tool Kit 2023 di Ivanti per ottenere il consenso interno è anche un'ottima risorsa che spiega tempi di messa in funzione e costi, in che modo una soluzione aiuta a difendersi da determinati tipi di attacchi informatici e come reagire alle obiezioni più comuni e superarle.

Vantaggi aziendali generali della conformità alla Direttiva NIS2

Tra i vantaggi della conformità alla Direttiva NIS2 figurano:

Ridurre i costi operativi prevenendo o minimizzando le perdite dovute agli attacchi informatici, come downtime, violazioni dei dati, pagamenti di riscatti, cause legali e così via. Secondo un report di IBM, nel 2022 il costo medio di una violazione dei dati è stato di 4,82 milioni di dollari USA per le organizzazioni di infrastrutture critiche e il tempo medio per identificare e contenere una violazione è stato di 277 giorni. Se adottate misure per conformarvi alla Direttiva NIS2, il tempo medio necessario per identificare e contenere una violazione sarà molto più breve e i costi dell'attacco saranno inferiori.
Aumentare i ricavi attirando o fidelizzando clienti che attribuiscono valore a sicurezza, privacy, qualità e fattori simili. Secondo un sondaggio di PwC, l'87% dei consumatori afferma che si rivolgerebbe altrove se non si fidasse delle pratiche di gestione dei dati di un'azienda, e il 71% afferma che smetterebbe di utilizzare i prodotti o servizi di un'azienda se scoprisse che questa condivide i suoi dati senza autorizzazione, eventualità che potrebbe verificarsi in caso di fuga di dati.
Migliorare l'efficienza semplificando i processi, migliorando le prestazioni, riducendo gli errori e così via. Accenture ha rilevato che le aziende che adottano tecnologie di sicurezza avanzate possono ridurre il costo della criminalità informatica fino al 48%.
Rispettare altre normative o standard che richiedono misure di cybersecurity, come GDPR, ISO 27001, PCI DSS o altri. Cisco sottolinea che il 97% delle organizzazioni conformi al GDPR rileva benefici quali l'acquisizione di un vantaggio competitivo, il raggiungimento dell'efficienza operativa e la riduzione dei ritardi nelle vendite. Risultati simili sono probabilmente ottenibili rispettando la NIS2.

Per quanto riguarda il budget, la proposta di direttiva della Commissione europea (Allegato 7 - 1.4.3) indica che, per le aziende che rientrano nell'ambito del framework NIS2, si stima un incremento massimo del 22% della spesa attuale per la sicurezza ICT nei primi anni successivi all'introduzione del framework NIS2.

Tuttavia, la proposta afferma anche che questo aumento medio della spesa per la sicurezza ICT genererebbe un beneficio proporzionato da tali investimenti, soprattutto grazie a una notevole riduzione del costo degli incidenti di cybersecurity.

2. Implementare correttamente nuove misure di sicurezza organizzative e tecniche

Dopo aver analizzato le lacune e ottenuto un budget, è il momento di colmarle. La Direttiva NIS2 richiede alle aziende di implementare misure organizzative e tecniche adeguate per gestire i rischi di cybersecurity e garantire un elevato livello di sicurezza nelle reti e nei sistemi informativi.

Queste misure includono:

Adottare policy e procedure per la gestione del rischio, la risposta agli incidenti, la continuità operativa, la protezione dei dati e così via.
Definire ruoli e responsabilità per governance, supervisione, coordinamento e altre aree della cybersecurity.
Fornire programmi di formazione e sensibilizzazione per personale, management, clienti e così via.
Implementare l'igiene informatica di base come crittografia, autenticazione (MFA), firewall, software antivirus, patching, accesso zero trust e così via.
Eseguire test, monitoraggi, audit e altre misure con regolarità.

Implementare queste misure organizzative e tecniche non è un'attività una tantum né statica. Richiede l'istituzione di un processo continuo e dinamico capace di adattarsi all'evoluzione di minacce, tecnologie, normative ed esigenze aziendali.

Per questo processo vale quindi lo stesso consiglio già visto per gli altri punti: prima inizierete, più tempo avrete per implementare le misure necessarie e garantirne efficacia ed efficienza.

Il mio consiglio è iniziare l'implementazione almeno a gennaio 2024, così da essere pronti prima delle ferie estive.

Prossimi passi per le implementazioni della Direttiva NIS2

Alcuni possibili passaggi per implementare misure organizzative e tecniche sono:

Sviluppare e implementare un processo di gestione basato sul rischio che definisca obiettivi, ambito, ruoli, responsabilità, risorse, tempistiche e metriche per gestire i rischi di cybersecurity.
Implementare una policy di sicurezza che stabilisca principi, linee guida, standard e procedure per garantire la sicurezza delle reti e dei sistemi informativi.
Condurre valutazioni del rischio per identificare asset, minacce, vulnerabilità, impatti e probabilità di attacchi informatici; e prioritizzare le azioni in base alla propensione e alla tolleranza al rischio.
Implementare controlli di sicurezza che proteggano reti e sistemi informativi da accessi, utilizzi, divulgazioni, modifiche o distruzioni non autorizzati. Questi controlli possono essere classificati in tre categorie: preventivi (ad es. crittografia); investigativi (ad es. monitoraggio) e correttivi (ad es. backup).
Implementare un piano di risposta agli incidenti che definisca processi, ruoli, responsabilità, risorse, strumenti e canali di comunicazione per rispondere agli incidenti informatici in modo efficace ed efficiente.
Implementare un piano di continuità operativa che definisca processi, ruoli, responsabilità, risorse, strumenti e canali di comunicazione per mantenere o ripristinare i processi aziendali critici durante un'interruzione o un disastro legato alla cybersecurity.
Implementare un piano di revisione e miglioramento che definisca processi, ruoli, responsabilità, risorse, strumenti e canali di comunicazione per valutare, segnalare e migliorare regolarmente le misure di cybersecurity.
Implementare i controlli tecnici per la gestione degli asset e l'igiene informatica di base.

Il riferimento della Direttiva all'“igiene informatica di base” è piuttosto vago nell'Articolo 21, quindi approfondiremo l'argomento in un altro post del blog. Per ora, considerate misure di sicurezza di base come:

MFA.
Applicare patch al sistema operativo e alle applicazioni il più rapidamente possibile.
Proteggere le connessioni di rete sulle reti pubbliche.
Crittografare tutte le unità, in particolare quelle rimovibili.
Gestire i privilegi e formare tutti i dipendenti.
Iscriversi a canali che forniscono informazioni sulle patch più recenti e sulle priorità, come i webinar Patch Tuesday di Ivanti.

3. Risolvere il punto più debole: trovare il tempo per formare ogni dipendente

La Direttiva NIS2 riconosce che i fattori umani sono cruciali per la cybersecurity e che i dipendenti sono spesso l'anello più debole — oltre che la prima linea di difesa — nella prevenzione o nel rilevamento degli attacchi informatici.

La Direttiva richiede alle organizzazioni di fornire programmi adeguati di formazione e sensibilizzazione ai dipendenti, agli utenti dei servizi digitali e ad altri stakeholder sulle tematiche di cybersecurity.

Formare tutti i dipendenti non è un'attività sporadica né facoltativa. Richiede un programma regolare e completo che copra temi quali:

Concetti e terminologia di base della cybersecurity.
Minacce informatiche e vettori di attacco comuni.
Best practice e consigli per l'igiene informatica.
Policy e procedure di cybersecurity, rese pertinenti e semplificate per gli utenti finali.
Ruolo e responsabilità di ogni utente per la cybersecurity dell'organizzazione.
Come segnalare gli incidenti e rispondere.

È importante notare che questa formazione deve essere ricevuta da tutti all'interno dell'azienda, non solo dal personale IT. Anche il management dovrebbe seguire questa formazione.

Un sondaggio condotto per Ivanti mostra che molti dipendenti non sono nemmeno consapevoli della formazione obbligatoria sulla cybersecurity. Solo il 27% si sente “molto preparato” a riconoscere e segnalare minacce come malware e phishing sul lavoro. Il 6% si sente “molto preparato” a riconoscere e segnalare minacce come malware e phishing sul lavoro.

Nel report NIS Investments 2022 di Enisa, Enisa afferma che il 40% degli OES (Operatori di Servizi Essenziali) intervistati non dispone di un programma di sensibilizzazione alla sicurezza per il personale non IT.

È importante monitorare chi non è ancora stato formato e intervenire di conseguenza. Formare tutti i dipendenti non è utile solo ai fini della conformità, ma anche per produttività, qualità, innovazione e soddisfazione dei clienti.

Il miglior consiglio che possiamo dare sulla NIS2

La Direttiva NIS2 è una normativa di riferimento che mira a rafforzare la cybersecurity dei settori critici nell'UE. Impone obblighi significativi alle organizzazioni che rientrano nel suo ambito di applicazione, insieme a multe e sanzioni pesanti in caso di non conformità.

Rispettare la Direttiva NIS2 è un compito complesso. Richiede un approccio proattivo e completo che coinvolga molteplici fasi, stakeholder e risorse.

Prima inizierete a prepararvi, più sarete pronti quando entrerà in vigore nell'ottobre 2024.

Il miglior consiglio che possiamo offrire? Non aspettate fino ad allora: iniziate subito a prepararvi per la Direttiva NIS2!

5 motivi per cui la preparazione alla Direttiva NIS2 dovrebbe iniziare subito, parte 1: gli audit richiedono tempo

Mon, 28 Aug 2023 17:14:55 Z

Probabilmente hai già sentito parlare della Direttiva sulla sicurezza delle reti e dei sistemi informativi (NIS2) aggiornata dall'Unione europea. Questa direttiva sarà recepita nella legislazione nazionale entro ottobre 2024. È importante farsi trovare pronti, perché la mancata conformità può comportare sanzioni e ammende elevate.

Potresti però pensare che ottobre 2024 sia ancora lontano. Meglio non sottovalutare la scadenza.

Dopotutto, come puoi sapere se hai abbastanza tempo per prepararti se non sai quanto sei già conforme alle normative previste?

Per questo, da qui a ottobre 2024, devi sottoporre ad audit il tuo attuale stato di cybersicurezza. In particolare:

Individuare fin da subito le lacune rispetto ai requisiti della Direttiva NIS2
Esaminare le attuali carenze di sicurezza della catena di fornitura

Nella seconda parte di questa serie analizzerò le tre aree su cui intervenire per colmare le lacune emerse dagli audit — incluso come:

Informare il management sulle lacune di cybersicurezza.
Implementare correttamente nuove misure di sicurezza organizzative e tecniche.
Trovare il tempo per formare tutti i dipendenti.

1. Individuare fin da subito le lacune rispetto ai requisiti della Direttiva NIS2

La Direttiva NIS2 è la normativa dell'UE in materia di cybersicurezza che introduce misure giuridiche per innalzare il livello complessivo di cybersicurezza nell'Unione. Modernizza il quadro normativo esistente per adeguarlo all'aumento della digitalizzazione e a un panorama delle minacce informatiche in continua evoluzione.

La direttiva estende l'ambito di applicazione delle norme di cybersicurezza a nuovi settori e soggetti, migliorando la resilienza e le capacità di risposta agli incidenti di enti pubblici e privati, autorità competenti e dell'intera UE.

La Direttiva NIS2 definisce misure più incisive per rafforzare la resilienza contro gli attacchi informatici, ridurre al minimo le vulnerabilità e migliorare la difesa informatica.

Per conformarti alla Direttiva NIS2, devi:

Valutare la tua postura di cybersicurezza e individuare eventuali lacune o punti deboli che potrebbero esporti a rischi informatici.
Mappare le policy, le procedure e i controlli esistenti rispetto ai requisiti della direttiva e capire dove migliorarli o aggiornarli.
Valutare le capacità di risposta agli incidenti e i meccanismi di reporting, assicurandoti che siano allineati agli standard della direttiva.

Uno dei principali problemi della NIS2 è che indica cosa dovresti fare, ma non come farlo. Fortunatamente, diversi framework possono aiutarti a definire il come, tra cui:

In Belgio, il CCB ha creato un Cyberfundamentals Framework basato su più framework, con riferimenti a come le diverse parti dei framework si collegano al GDPR e alla NIS2.

Dopo aver selezionato il framework, devi individuare le lacune rispetto al framework scelto e ai requisiti della direttiva. L'individuazione delle lacune non è un'attività semplice né rapida: richiede un'analisi approfondita e sistematica della maturità e del livello di preparazione della cybersicurezza della tua organizzazione.

Non devi solo verificare la strategia e le policy di cybersicurezza, ma anche condurre un'analisi dei rischi per individuare gli asset più critici e i rischi informatici associati, quindi valutare controlli di sicurezza che riducano il punteggio di rischio di tali asset essenziali.

Prima inizi questo processo, più tempo avrai per ottenere il budget necessario a risolvere eventuali problemi e implementare le modifiche richieste.

Possibili lacune dell'ambiente NIS2

Tra le possibili lacune che potresti riscontrare nel tuo ambiente rientrano:

Assenza di una strategia o policy di cybersicurezza completa che copra tutti gli aspetti della gestione del rischio, della risposta agli incidenti, della continuità operativa, della protezione dei dati, ecc.
Assenza di un team o di una funzione dedicata alla cybersicurezza che supervisioni, coordini e monitori tutte le attività e iniziative di cybersicurezza nell'intera organizzazione.
Assenza di controlli o misure di sicurezza adeguati per proteggere le reti e i sistemi informativi da accessi, utilizzi, divulgazioni, modifiche o distruzioni non autorizzati.
Assenza di test o audit regolari dei controlli o delle misure di sicurezza, per garantirne l'efficacia e la conformità ai requisiti della direttiva.
Assenza di programmi adeguati di formazione o sensibilizzazione per il personale, il management, altri dipendenti o altri stakeholder in merito a temi e best practice di cybersicurezza.
Assenza di canali chiari di comunicazione o reporting per notificare alle autorità o alle parti pertinenti eventuali incidenti o violazioni che interessano i tuoi servizi.

Potenziali soluzioni di sicurezza per il tuo ambiente per conformarti alla NIS2

Per individuare e colmare queste lacune di sicurezza, puoi:

Eseguire framework o modelli di gap analysis che ti aiutino a confrontare lo stato attuale con quello desiderato e a individuare le aree di miglioramento.
Implementare modelli o standard di maturità della cybersicurezza che ti aiutino a misurare il livello di prestazioni e i progressi in ambito cybersicurezza.
Condurre una valutazione del rischio per identificare asset, minacce, vulnerabilità, impatti e probabilità di attacchi informatici.
Richiedere audit o valutazioni esterne che ti aiutino a convalidare il tuo stato di conformità e a individuare eventuali debolezze o carenze.

2. Esaminare le attuali carenze di sicurezza della catena di fornitura con tempo sufficiente per coordinare le azioni con i fornitori

La Direttiva NIS2 introduce inoltre nuove disposizioni sulla sicurezza della catena di fornitura (capitolo 0, punti 54 e 56), riconoscendo che le minacce informatiche possono provenire da fornitori terzi o subappaltatori.

La direttiva richiede alle organizzazioni di assicurarsi che i fornitori adottino standard e pratiche di sicurezza adeguati (articolo 21-2d) e di monitorarne regolarmente le prestazioni e la conformità (articolo 21–3).

E non senza motivo. Gli attacchi alla catena di fornitura sono in aumento:

In una ricerca BlackBerry condotta nel 2022 su oltre 1.500 decision maker IT, quattro intervistati su cinque hanno dichiarato di essere stati informati di un attacco o di una vulnerabilità nella propria catena di fornitura nel corso dell'anno. Il 77% ha affermato di aver scoperto partecipanti nascosti nella propria supply chain software di cui in precedenza non era a conoscenza.

Una ricerca Accenture rivela inoltre che il 40% delle violazioni della sicurezza è indiretto e avviene attraverso la catena di fornitura.

Pertanto, mettere in sicurezza la catena di fornitura è essenziale per garantire continuità operativa, resilienza, reputazione e fiducia.

Tuttavia, nel Press Reset: A 2023 Cybersecurity Status Report di Ivanti, abbiamo rilevato che solo il 42% degli oltre 1.300 leader executive e professionisti della sicurezza intervistati si dichiara pronto a proteggersi dalle minacce alla catena di fornitura, anche se il 46% le considera una minaccia di alto livello.

Le minacce alla catena di fornitura non arrivano solo tramite attacchi a fornitori di soluzioni come Okta, Kaseya o SolarWinds, ma anche tramite partner direttamente connessi alla tua infrastruttura IT o in grado di accedervi.

E non dimenticare gli attacchi ai tuoi fornitori di risorse, che potrebbero bloccarli al punto da impedire loro di consegnare determinate risorse necessarie per le tue attività. Devi essere preparato e disporre di fornitori di backup in grado di fornire quelle risorse se il fornitore principale è fuori servizio a causa di un attacco informatico o per altri motivi.

La sicurezza della catena di fornitura è un tema complesso e impegnativo, che coinvolge molteplici attori, dipendenze e interconnessioni, e non può essere realizzata dall'oggi al domani.

Devi:

Stabilire canali di comunicazione chiari e trasparenti con i fornitori e definire aspettative e obblighi in materia di cybersicurezza.
Condurre audit e valutazioni regolari delle pratiche di sicurezza dei fornitori e verificare che soddisfino i requisiti della direttiva.
Stabilire piani di emergenza e soluzioni di backup in caso di interruzione o compromissione della catena di fornitura.

Inoltre, devi iniziare a coinvolgere i fornitori il prima possibile e collaborare con loro per garantire che la catena di fornitura sia sicura e resiliente.

Sfide di sicurezza della catena di fornitura per la NIS2

Tra le possibili sfide che potresti affrontare nella messa in sicurezza della catena di fornitura rientrano:

Mancanza di visibilità o trasparenza sulle pratiche, le policy o gli incidenti di sicurezza dei fornitori.
Mancanza di fiducia o collaborazione tra i fornitori o tra te e i tuoi fornitori.
Mancanza di coerenza o allineamento negli standard, nei requisiti o nelle aspettative di sicurezza lungo tutta la catena di fornitura.
Mancanza di risorse o capacità per monitorare, sottoporre ad audit o verificare le prestazioni o la conformità di sicurezza dei fornitori.
Mancanza di piani di emergenza o soluzioni di backup per mitigare o superare eventuali interruzioni o compromissioni della catena di fornitura.
Mancanza di informazioni su ciò che ti aspetti dalle pratiche di sicurezza dei tuoi fornitori.

Soluzioni per la sicurezza della catena di fornitura per la NIS2

Per superare queste sfide di sicurezza della catena di fornitura, puoi:

Stabilire contratti o accordi chiari con i fornitori, specificando obblighi, responsabilità e responsabilità legali in materia di sicurezza.
Sviluppare criteri, linee guida o framework di sicurezza comuni applicabili a tutti i fornitori della catena di fornitura e allineati ai requisiti della direttiva.
Implementare controlli, misure o strumenti di sicurezza che consentano di tracciare, monitorare o verificare le attività di sicurezza, gli incidenti o lo stato di conformità dei fornitori.
Creare team, comitati o forum congiunti sulla sicurezza che facilitino la condivisione di informazioni, la collaborazione e il coordinamento tra i fornitori o tra te e i tuoi fornitori.
Costruire fiducia e comprensione reciproca con i fornitori attraverso comunicazioni regolari, feedback e riconoscimento.

Una volta completati gli audit per la Direttiva NIS2, qual è il passo successivo?

Ora che hai determinato la tua posizione attuale rispetto alla Direttiva NIS2, è il momento di implementare cambiamenti critici per garantire la conformità entro ottobre 2024. Sono certo che colmare le lacune individuate dagli audit richiederà tutto il tempo a disposizione, e probabilmente anche di più, prima che le normative vengano ufficialmente implementate nel tuo Paese.

Ma come affrontare queste lacune in modo sistematico e tempestivo? Nel prossimo post del blog parleremo delle tre aree di cambiamento in ambito sicurezza necessarie per la NIS2, esaminando come:

Informare il management sulle lacune di cybersicurezza.
Implementare correttamente nuove misure di sicurezza organizzative e tecniche.
Trovare il tempo per formare tutti i dipendenti.