Ivanti Blog: Sicurezza

ITAM incontra il CAASM: perché l'IT Asset Management è un prerequisito per la tua strategia CAASM

Wed, 01 Jul 2026 15:00:42 Z

La gestione della superficie di attacco degli asset cyber (cyber asset attack surface management, CAASM) è un approccio emergente a un elemento fondamentale della strategia di cybersecurity: avere una visione completa dei propri asset cyber per poter identificare le vulnerabilità che gli attori malevoli potrebbero sfruttare.

Per il personale delle operations IT, il CAASM probabilmente ricorderà molto da vicino l'IT Asset Management (ITAM). Questo perché le due discipline sono strettamente correlate, evidenziando con chiarezza come sicurezza e IT ops possano e debbano fare leva su strumenti e processi condivisi.

ITAM vs. CAASM: qual è la differenza?

L'ITAM è un insieme di processi e strumenti per gestire tutti gli asset IT, inclusi hardware e software, lungo tutto il loro ciclo di vita. Normalmente comprende un'ampia gamma di workflow, tra cui discovery degli asset, gestione dell'inventario, mappatura dei servizi, tracciamento e monitoraggio degli asset e gestione del ciclo di vita degli asset.

Il CAASM amplia l'ITAM identificando e mitigando potenziali vulnerabilità e minacce ai sistemi, alle reti e alle applicazioni della tua organizzazione. Il processo prevede in genere l'identificazione di tutti gli asset all'interno dell'ambiente IT, la mappatura delle interdipendenze tra questi asset e la valutazione del potenziale impatto di una violazione.

L'obiettivo è offrire alla tua organizzazione una comprensione chiara della potenziale superficie di attacco e dare priorità agli interventi di remediation in base ai rischi più significativi. Ed è proprio ciò che i team desiderano: il 44% dei team di cybersecurity considera le informazioni sugli asset fondamentali per identificare e proteggere le superfici di attacco.

I vantaggi dell'ITAM per la sicurezza

L'importanza dell'ITAM per la sicurezza non è una novità per i leader IT. Un sondaggio del 2022 condotto da EMA tra i leader IT ha rilevato che quasi la metà misura il successo del proprio programma ITAM in base alla riduzione dei rischi di sicurezza. Analizzare l'ITAM attraverso la lente della sicurezza evidenzia diversi vantaggi direttamente collegati al CAASM:

Identificazione degli asset

Una soluzione ITAM pienamente implementata consente alla tua organizzazione di identificare e tracciare tutti gli asset IT. Sapere quali asset sono presenti nell'ambiente è il primo passo per identificare potenziali vulnerabilità e minacce.

Gestione delle vulnerabilità

Senza un inventario completo degli asset IT, la tua organizzazione si troverà di fronte a lacune quando tenterà di condurre valutazioni periodiche delle vulnerabilità, identificare potenziali vulnerabilità e affrontarle in modo proattivo.

Assegnazione delle priorità alle misure di sicurezza

Sapere quali sono tutti gli elementi e dove si trovano è un ottimo punto di partenza, ma allocare efficacemente le risorse a supporto della gestione del rischio significa sapere quali asset sono più critici. Un insieme ben definito di processi ITAM e sistemi ITAM efficaci fornisce alla tua organizzazione le informazioni necessarie per dare priorità alle misure di sicurezza.

Classificando gli asset per tipologia, i team di cybersecurity possono concentrarsi maggiormente sugli asset a rischio più elevato, come cloud e SaaS, mantenendo al contempo un controllo appropriato sugli asset a rischio relativamente più basso, come i dispositivi edge.

E sebbene siano meno direttamente collegati al CAASM, l'ITAM contribuisce anche a rafforzare la sicurezza in altre aree:

Conformità

Esiste un ampio corpus di normative – CCPA, GDPR, POPI, Castle e altre – che richiedono alle aziende di mantenere un inventario accurato dei propri asset IT e dimostrare la conformità a vari standard di sicurezza.

Risparmio sui costi

Per quanto riguarda gli asset IT, la gestione dei costi è strettamente correlata alla gestione dell'utilizzo. Ad esempio, quasi un terzo dei leader IT intervistati ritiene di sprecare budget in risorse cloud inutilizzate o sottoutilizzate. Una spesa gestita in modo inadeguato rappresenta di per sé un rischio per le organizzazioni IT e aggrava i problemi di cybersecurity limitando le risorse disponibili per affrontare le criticità di sicurezza.

Creare una soluzione CAASM che garantisca la sicurezza degli asset

Combinando l'ITAM con la gestione del rischio degli asset cyber, una soluzione CAASM può proteggere i singoli asset, così come l'intera superficie degli asset cyber, da un'ampia gamma di minacce e vulnerabilità. Esaminiamo più da vicino i componenti che costituiscono uno stack di soluzioni CAASM efficace:

Discovery e gestione degli asset

Abbiamo già visto che l'ITAM è un componente critico della soluzione CAASM. Per implementare con successo l'ITAM sono necessari strumenti di discovery in grado di analizzare la rete per identificare tutti i dispositivi connessi, inclusi quelli che potrebbero essere nascosti o sconosciuti.

Il database degli asset della soluzione ITAM, spesso associato alla CMDB (vedi sotto), può quindi fornire un repository centrale per gestire tutte le informazioni sugli asset, inclusi attributi degli asset, configurazioni e mappatura di relazioni e dipendenze.

Gestione delle vulnerabilità

La gestione delle vulnerabilità include strumenti e tecnologie che consentono alla tua organizzazione di identificare e assegnare priorità alle vulnerabilità all'interno degli asset IT. Gli strumenti di scansione delle vulnerabilità eseguono scansioni periodiche dell'ambiente per identificare potenziali vulnerabilità in hardware, software e configurazioni. Questi strumenti assegnano quindi le priorità alle vulnerabilità in base alla gravità e forniscono raccomandazioni di remediation per affrontarle in modo proattivo.

Threat intelligence

La threat intelligence include strumenti e tecnologie che forniscono informazioni in tempo reale su minacce e tendenze emergenti. Questi strumenti monitorano un'ampia gamma di fonti, tra cui feed pubblici e privati, social media e forum del dark web, per identificare potenziali minacce e vettori di attacco. Puoi utilizzare queste informazioni per dare priorità alle misure di sicurezza e affrontare in modo proattivo le potenziali minacce.

Configuration Management Database (CMDB)

La CMDB è un repository centrale di tutti i servizi, gli asset e gli altri elementi di configurazione presenti nell'ambiente IT. Include sia un inventario di questi elementi sia le relative relazioni e dipendenze. La CMDB consente alla tua azienda di monitorare e gestire tutte le modifiche agli asset, assicurando che vengano apportate in modo controllato e documentato.

Integrando la CMDB con strumenti di gestione delle vulnerabilità e threat intelligence, le aziende possono dare priorità alle misure di sicurezza in base alla criticità degli asset e alle loro relazioni.

Lo stack di soluzioni CAASM è un insieme completo di strumenti e tecnologie che consente alle aziende di identificare e mitigare in modo proattivo potenziali vulnerabilità nei propri asset IT. Combinando discovery degli asset e gestione dell'inventario, gestione delle vulnerabilità, threat intelligence e CMDB, la tua azienda può anticipare le potenziali minacce informatiche e mantenere al sicuro gli asset IT critici.

In che modo l'AI agentica abilita la risposta autonoma alle minacce alla velocità delle macchine

Mon, 29 Jun 2026 14:00:03 Z

Perché oggi il 40% degli avvisi ricevuti dai team di sicurezza resta completamente non investigato? Non è per mancanza di attenzione, ma a causa di finestre di attacco sempre più brevi e di una proliferazione tecnologica ingestibile.

I team di sicurezza odierni operano in uno scenario di minacce caratterizzato da attacchi in aumento, budget più ristretti e una crescente alert fatigue. Le organizzazioni elaborano in media 960 avvisi di sicurezza al giorno, mentre le grandi aziende gestiscono oltre 3.000 avvisi quotidiani su circa 30 strumenti. Il risultato è un totale di 36.000 potenziali minacce al mese che potrebbero passare inosservate. L'asimmetria è schiacciante: agli attaccanti basta una sola violazione riuscita, mentre i difensori devono avere sempre ragione.

Questo divario critico per le organizzazioni è un problema di architettura. La sfida più grande nella risposta alle minacce non è ciò che viene rilevato, ma ciò che accade dopo che l'avviso viene generato.

La buona notizia? L'AI agentica cambia questa architettura. Non sostituendo gli strumenti esistenti, ma colmando il divario operativo tra rilevamento e azione.

Il problema della velocità nella sicurezza

Gli strumenti implementati (SIEM, EDR, scanner di vulnerabilità, piattaforme SOAR) sono eccellenti nel rilevamento. Portano alla luce le minacce, catalogano i rischi e inviano gli avvisi. Ma il rilevamento senza una risposta efficace è solo documentazione costosa. Il vero collo di bottiglia diventa risolvere i problemi abbastanza rapidamente da fare la differenza, non semplicemente sapere che cosa non va.

Scopri di più:Perché la gestione tradizionale delle vulnerabilità sta cedendo sotto la pressione del rilevamento guidato dall'AI

Le operazioni di sicurezza tradizionali seguono una sequenza nota: viene generato un avviso, un analista indaga, viene presa una decisione, viene pianificata la remediation, viene approvata la modifica … e solo allora si interviene. Ogni fase ha senso se considerata singolarmente, ma nel complesso vincola i team alla velocità umana mentre le minacce si muovono autonomamente. Quando l'indagine è completa, l'avversario si è già spostato lateralmente. E quando viene distribuita una patch, sono già state divulgate altre tre CVE critiche.

Il divario temporale è evidente. Secondo il Verizon Data Breach Investigations Report 2025, le organizzazioni impiegano in media 32 giorni per correggere le vulnerabilità dei dispositivi perimetrali, mentre gli attori delle minacce sfruttano quelle stesse vulnerabilità al momento della divulgazione pubblica o persino prima, operando di fatto secondo tempistiche da zero-day. Questo divario sta accelerando: il M-Trends Report 2026 di Mandiant rivela che il tempo tra l'accesso iniziale e il passaggio a un gruppo di minaccia secondario è crollato da oltre otto ore nel 2022 ad appena 22 secondi nel 2025.

Un modello di sicurezza efficace richiede che il rilevamento attivi un'azione immediata e intelligente. Le funzionalità esistenti, come valutazione delle vulnerabilità , gestione degli endpoint , distribuzione delle patch e controlli di accesso, restano in essere, ma operano più rapidamente e con maggiore autonomia. Il risultato sono operazioni di sicurezza che funzionano alla velocità delle macchine anziché alla velocità umana.

Che aspetto ha davvero la sicurezza agentica

Nell'ambito della sicurezza, l'AI agentica indica sistemi autonomi che eseguono workflow di sicurezza end-to-end. Passano dal rilevamento alla decisione e all'azione senza interrompersi per richiedere un'approvazione manuale a ogni passaggio.

L'AI agentica dovrebbe operare sull'intera superficie di attacco, coordinando rilevamento, decisione e risposta come un unico sistema.

Remediation autonoma delle vulnerabilità

Quando viene divulgata una CVE critica, gli agenti valutano immediatamente l'esposizione in tutto l'ambiente. Assegnano la priorità al rischio in base alla sfruttabilità e al contesto aziendale, distribuiscono patch agli endpoint interessati e verificano la remediation. Tutto questo avviene prima che un analista apra un ticket. La supervisione umana resta in essere, ma viene eliminato il ritardo creato dai passaggi di consegne manuali.

Scopri di più:Report sulla prioritizzazione delle patch basata sul rischio

Risposta intelligente alle minacce

Quando un endpoint mostra un comportamento sospetto, gli agenti correlano i segnali tra EDR, telemetria di rete e inventario degli asset. I dispositivi interessati vengono isolati; le sessioni attive vengono revocate; le prove forensi vengono acquisite e il SOC viene avvisato con il contesto completo. La minaccia viene contenuta prima che si diffonda, consentendo agli analisti di indagare su un incidente neutralizzato anziché su una violazione attiva.

Postura di conformità continua

Gli agenti monitorano continuamente endpoint e server alla ricerca di deviazioni di configurazione. Quando un dispositivo non è più conforme, ad esempio perché un firewall è disabilitato, la crittografia è disattivata o è installato software non autorizzato, la remediation avviene automaticamente. La configurazione viene corretta, l'evento viene registrato e la conformità viene verificata. La conformità diventa uno stato continuo, non un'attività trimestrale.

Mitigazione del rischio di accesso

Gli agenti rilevano modelli di accesso anomali, incluse geolocalizzazioni inattese, tentativi di escalation dei privilegi e accessi ai dati insoliti. Le sessioni sospette vengono terminate; viene applicata l'autenticazione a più fattori e l'accesso viene ridotto fino al completamento della verifica. Gli utenti legittimi continuano a lavorare mentre il movimento laterale viene bloccato in tempo reale.

Questi agenti operano nell'intero stack di sicurezza esistente, inclusi SIEM, EDR, gestione delle vulnerabilità , sistemi di identità e gestione delle patch. Ogni strumento diventa più rapido ed efficace come parte di un sistema coordinato. L'obiettivo non è sostituire le operazioni di sicurezza, ma consentire loro di operare alla velocità con cui gli avversari agiscono già.

Scopri di più:In che modo l'AI agentica sta trasformando infrastruttura e operations

Dal rilevamento all'azione: l'architettura della velocità

Il cambiamento fondamentale reso possibile dall'AI agentica è il processo decisionale nel punto di rilevamento. Invece di separare il rilevamento dall'azione, i workflow di sicurezza sono progettati per valutare il rischio e rispondere immediatamente all'emergere delle minacce.

Quando viene identificata una vulnerabilità critica, l'agente non si limita a creare un ticket da esaminare in seguito. Valuta gli stessi fattori che prenderebbe in considerazione un architetto della sicurezza:

Il sistema è esposto a Internet?
A quali dati accede?
Esiste un exploit noto già attivo?
Qual è l'impatto sul business dell'applicare la patch rispetto al rimandare?

Quella decisione viene presa in millisecondi anziché in giorni. E per ottenere questo risultato non bastano script di automazione: servono sistemi in grado di ragionare su contesto e conseguenze.

Punteggio del rischio sensibile al contesto aziendale

Non tutte le vulnerabilità critiche hanno la stessa urgenza. Gli agenti valutano insieme sfruttabilità, esposizione e impatto sul business. Una vulnerabilità su un server di test interno viene gestita in modo diverso rispetto allo stesso problema su un sistema di produzione rivolto ai clienti. La prioritizzazione avviene automaticamente e la motivazione è chiara e difendibile.

Soglie di risposta adattive

Gli agenti apprendono dai risultati nel tempo. Quando determinate azioni producono costantemente falsi positivi, le soglie si adattano. Quando emergono nuovi schemi di attacco, la sensibilità aumenta. Il sistema migliora con l'uso, invece di diventare più fragile al cambiare delle condizioni.

Escalation con conservazione del contesto

Quando un agente raggiunge il limite della propria autonomia, l'escalation include il ragionamento, non solo un avviso. Che cosa è stato rilevato, quali segnali sono stati valutati, perché la decisione non ha potuto essere completata autonomamente e quale azione è stata raccomandata: tutto viene trasmesso all'analista. L'intervento umano si concentra sulle decisioni che contano, non sul triage.

Auditabilità integrata

Ogni azione viene registrata con il contesto completo, inclusi l'elemento scatenante, i dati valutati, la decisione presa e il risultato. La conformità è integrata direttamente nel workflow, anziché essere ricostruita a posteriori.

L'impatto sui team di sicurezza è misurabile. Il SANS Detection & Response Survey 2025 ha rivelato che il 73% delle organizzazioni indica i falsi positivi come la principale sfida di rilevamento, mentre il 76% segnala l'alert fatigue come una delle principali preoccupazioni del SOC. Non si tratta solo di un problema di efficienza. Quando gli analisti trascorrono la maggior parte del tempo a distinguere il rumore dai segnali rilevanti, i programmi di sicurezza restano reattivi per impostazione.

Il risultato è una realtà operativa diversa. Il rilevamento porta alla risoluzione. Gli avvisi vengono affrontati man mano che compaiono, invece di accumularsi nelle code. I team di sicurezza dedicano meno tempo a rispondere agli incidenti di ieri e più tempo a prevenire quello successivo.

Che cosa cambia nella pratica

Quando l'AI agentica viene implementata in ambienti di sicurezza di produzione, l'impatto si manifesta meno come una serie di successi isolati e più come un cambiamento strutturale. I team osservano cambiamenti costanti nel modo in cui i workflow sono strutturati, nella rapidità con cui il rischio viene ridotto e nell'area in cui viene applicato l'impegno umano.

1. Il tempo all'azione si riduce drasticamente

Rilevamento e risposta confluiscono in un unico movimento. Le vulnerabilità che un tempo aspettavano giorni per triage e pianificazione vengono valutate, priorizzate e corrette automaticamente quando le soglie di rischio sono soddisfatte. Le minacce che in precedenza si muovevano lateralmente durante l'indagine vengono contenute nel punto di rilevamento. Il risultato misurabile è un tempo di permanenza più breve e una riduzione del rischio più rapida, non solo avvisi più veloci.

2. Il carico operativo diminuisce

Le attività di sicurezza di routine che in precedenza assorbivano il tempo degli analisti, come la remediation delle deviazioni di conformità, il coordinamento delle patch e le correzioni degli accessi, passano a un'esecuzione continua in background. La reportistica diventa un sottoprodotto delle normali operazioni, anziché una corsa periodica. I team di sicurezza dedicano meno tempo alla gestione dei processi e più tempo all'applicazione del giudizio.

3. La qualità della risposta diventa più uniforme

Quando le decisioni vengono prese utilizzando ogni volta gli stessi input contestuali, il comportamento di risposta si stabilizza. Rischi simili vengono gestiti in modi simili, indipendentemente da quando si verificano o da chi è reperibile. Questa coerenza riduce la variabilità, limita l'errore umano e rende i risultati più facili da spiegare ad auditor, dirigenti e autorità di regolamentazione.

4. L'attenzione umana si sposta su attività di maggior valore

Gli analisti non vengono più coinvolti in ogni avviso o problema minore di configurazione. Intervengono quando l'escalation è giustificata e quando le decisioni incidono concretamente sul rischio aziendale. Il risultato è meno alert fatigue, meno falsi positivi e più tempo dedicato a threat hunting, analisi degli incidenti e miglioramento strategico.

L'impatto aziendale di questo cambiamento trova riscontro nei dati di settore. Secondo il Cost of a Data Breach Report 2025 di IBM, le organizzazioni che fanno ampio uso di AI e automazione hanno risparmiato in media 1,9 milioni di dollari per violazione e ridotto il ciclo di vita della violazione di ottanta giorni. Con un ciclo di vita medio globale delle violazioni pari a 241 giorni nel 2025, il livello più basso degli ultimi nove anni, anche miglioramenti incrementali della velocità si traducono in una riduzione significativa del rischio e dei costi.

Lo schema è costante. I team di sicurezza smettono di reagire agli arretrati e iniziano a operare al ritmo della minaccia stessa.

Perché procedere lentamente è il rischio maggiore

La cautela nei confronti dell'AI nella sicurezza è comprensibile. I sistemi di sicurezza incidono su infrastrutture critiche. Gli errori sono molto visibili e le conseguenze di un fallimento sono reali. Attendere casi d'uso più chiari, una governance più solida e controlli comprovati può sembrare la scelta responsabile.

La sfida è che l'ambiente di rischio sottostante è cambiato. Gli attaccanti operano già alla velocità delle macchine, mentre la maggior parte dei programmi di sicurezza risponde ancora alla velocità umana. Ogni settimana trascorsa a rimandare un'autonomia significativa amplia questo divario. L'esposizione si accumula silenziosamente, non perché il rilevamento fallisca, ma perché l'azione non riesce a tenere il passo.

La maggior parte delle organizzazioni dispone già dei segnali necessari. SIEM, EDR, gestione delle vulnerabilità e sistemi di patching generano rilevamento e contesto di alta qualità. Il vincolo è l'esecuzione. Gli avvisi si accumulano. I ticket restano in attesa. Le decisioni si bloccano. L'AI agentica affronta questo vincolo riducendo la distanza tra rilevamento e risposta. Più a lungo questa distanza permane, più la postura di sicurezza si allontana dalla realtà delle minacce moderne.

Nella pratica, la resistenza alla sicurezza agentica è più spesso organizzativa che tecnica. La responsabilità dei risultati guidati dall'AI può non essere chiara. Gli incentivi possono premiare l'aderenza ai processi più della riduzione del rischio. I team possono vedere l'automazione come una minaccia alla propria rilevanza anziché come un'estensione delle proprie capacità.

Sul piano operativo, tende a essere vero il contrario. Con l'aumento dell'autonomia, il lavoro degli analisti diventa più focalizzato e più prezioso. Si ampliano le attività di threat hunting, analisi degli incidenti, ricerca sugli avversari e miglioramento dell'architettura. Triage manuale, coordinamento delle patch e indagini ripetitive diminuiscono. La competenza umana viene applicata dove il giudizio conta di più.

Le organizzazioni che ritardano l'adozione della sicurezza agentica non restano ferme. Scelgono di operare con un modello di risposta che non riesce a eguagliare il ritmo degli attacchi moderni. Nel tempo, questo disallineamento diventa la principale fonte di rischio.

Il cambiamento è già in corso

Le operazioni di sicurezza si stanno allontanando dai modelli reattivi in cui il rilevamento crea arretrati, gli avvisi generano lavoro e le tempistiche di risposta si estendono per giorni. I programmi più avanzati si stanno riorganizzando attorno all'esecuzione proattiva, in cui i sistemi percepiscono le condizioni, valutano il rischio e agiscono in modo continuo. Gli agenti autonomi assorbono volume e variabilità. I team umani si concentrano su strategia, indagine e miglioramento.

Questo cambiamento riflette un'evoluzione nel modo in cui la sicurezza moderna deve operare. Gli avversari automatizzano già ricognizione, sviluppo di exploit e movimento laterale. Gli attacchi avanzano senza attendere che i ticket vengano sottoposti a triage o che le approvazioni siano pianificate. I programmi di sicurezza che restano vincolati a workflow alla velocità umana faticano a colmare questo divario.

Ciò che distingue le organizzazioni più efficaci è la disponibilità a operare in modo diverso. Progettano per l'esecuzione oltre che per il rilevamento. Governano l'autonomia in modo deliberato. Misurano i risultati anziché le attività. Nel tempo, questo modello operativo consolida il proprio vantaggio perché la risposta migliora man mano che i sistemi apprendono e i team si rifocalizzano.

La domanda che i leader della sicurezza devono affrontare non è più se l'autonomia abbia un ruolo nelle operazioni di sicurezza. È se la loro organizzazione sia pronta a gestire la sicurezza al ritmo che l'ambiente oggi richiede.

Pronti a colmare il divario di velocità nella sicurezza?

Scopri come Ivanti Neurons for ITSM abilita workflow di sicurezza autonomi che passano dal rilevamento alla risoluzione con rapidità e controllo.

Siamo nell’apocalisse delle patch. Ecco perché queste tre scuse IT non funzioneranno più.

Wed, 29 Apr 2026 14:00:07 Z

Il 7 aprile, Anthropic ha annunciato che il suo modello Claude Mythos Preview aveva identificato autonomamente migliaia di vulnerabilità zero-day ad alta gravità e critiche in tutti i principali sistemi operativi e browser web. Oltre il 99% non era stato corretto con patch il giorno della divulgazione.

Due settimane dopo, il 21 aprile, Mozilla ha dichiarato di aver utilizzato lo stesso modello per individuare e correggere con patch 271 vulnerabilità nell’ultima release di Firefox. La valutazione di Mozilla: “Finora non abbiamo trovato alcuna categoria o complessità di vulnerabilità che gli esseri umani possano individuare e che questo modello non sia in grado di trovare”.

271 è solo la prima ondata. Chrome, Edge, Windows, macOS, Linux, FreeBSD: la falla di esecuzione di codice da remoto vecchia di 17 anni in FreeBSD divulgata dal red team di Anthropic (CVE-2026-4747) è un primo esempio di ciò che sta arrivando. Ogni vendor nell’ambito del Project Glasswing di Anthropic è nella posizione di rilasciare correzioni a un ritmo mai visto prima nel settore. Tutte queste correzioni diventano CVE pubbliche con patch disponibili, e finiscono tutte nello stesso posto: il tuo ambiente.

Anche la storia del contenimento presenta una crepa. Il 21 aprile, Bloomberg ha riferito che un gruppo collegato a Discord ha ottenuto accesso non autorizzato a Mythos tramite l’ambiente di un vendor di terze parti. Anthropic afferma che l’attività non si è estesa oltre quel vendor. Indipendentemente dal fatto che capacità simili siano già o meno nelle mani degli attaccanti, il margine di manovra difensivo è più breve di quanto lasciasse intendere l’annuncio del 7 aprile.

Mythos è arrivato in un mondo che stava già andando in questa direzione. Il Global Threat Report 2026 di CrowdStrike ha documentato nel 2025 un aumento dell’89% su base annua degli attacchi abilitati dall’AI. Questa tendenza era precedente a Mythos.

Chiamiamola apocalisse delle patch. Quella operativa, concreta: il volume e la cadenza delle CVE pubbliche con patch disponibili stanno per superare il modo in cui oggi lavora la maggior parte dei team IT e di sicurezza.

Il NIST sta già subendo gli effetti dell’apocalisse delle patch. Ad aprile, l’agenzia ha annunciato un importante cambiamento nelle operazioni del National Vulnerability Database (NVD) in risposta a un aumento del 263% delle segnalazioni. Il NIST non fornirà più un arricchimento dettagliato per tutte le vulnerabilità inviate e lo farà invece solo per quelle che soddisfano criteri di rischio elevato, come le vulnerabilità presenti nel catalogo CISA Known Exploited Vulnerabilities o quelle che interessano software governativo critico. Il NIST farà affidamento sulle CVE Numbering Authorities (CNA), come Ivanti, anziché condurre una propria valutazione indipendente.

Dall’annuncio, ho sentito tre versioni della stessa risposta da clienti e colleghi. Tutte e tre sono varianti di un programma pensato per un mondo più lento.

“Abbiamo uno scanner di vulnerabilità”

Qualys, Rapid7 e Tenable svolgono bene l’attività di discovery delle vulnerabilità. Gli scanner individuano, segnalano, assegnano punteggi ed elencano. Distribuzione, verifica, gestione dei riavvii e rollback sono fuori dal loro ambito. Quel lavoro deve comunque essere svolto da qualche parte. Nella maggior parte dei programmi avviene in uno strumento separato, con un team separato, seguendo una cadenza separata.

Con la finestra di exploit ormai misurata in ore e la coda di Glasswing destinata quasi a raddoppiare il backlog, uno scanner che produce 587 vulnerabilità critiche e passa l’elenco a un team umano diventa una responsabilità. La scelta pratica è collegare lo scanner che già possiedi a un motore di remediation in grado di agire automaticamente sui risultati. Una piattaforma di gestione autonoma degli endpoint (AEM), con distribuzione ad anelli e rollback, e intelligence sulle vulnerabilità per fornire un contesto basato sul rischio a supporto di decisioni di remediation efficienti, così l’elenco si riduce senza che siano gli esseri umani a prendere ogni decisione.

“Gestiamo le approvazioni tramite il nostro sistema di ticketing”

A proposito di esseri umani che devono prendere decisioni… I lunghi processi di approvazione lineari rallenteranno in modo significativo la remediation. Quand’è stata l’ultima volta che hai dovuto decidere se distribuire l’ultimo aggiornamento del sistema operativo o del browser?

Le organizzazioni sanno già che distribuiranno questi aggiornamenti. Spesso il processo di approvazione è dovuto a complesse dinamiche interne e a un disallineamento sugli obiettivi di sicurezza. Il risultato? Un processo molto lineare che richiede lo scanner di vulnerabilità citato in precedenza, un analista che approvi ciò che sai già debba essere fatto, ticket inviati ai responsabili di business per l’approvazione e lasciati nelle caselle di posta in attesa, e in definitiva tempo prezioso sprecato per una decisione che era sostanzialmente già chiara e non doveva essere presa.

Il passaggio del mercato all’Exposure Management affronta questo processo in modo molto diverso, concentrandosi sulla definizione della propensione al rischio di un’organizzazione e sul monitoraggio della postura di rischio. La prossima volta che verrà rilasciato un aggiornamento del sistema operativo Windows, saprai già che lo distribuirai, con quale pianificazione lo farai e con quali SLA e metriche di conformità misurerai il successo. Quello che vuoi davvero sapere è:

1. Devo muovermi più rapidamente perché l’aggiornamento include vulnerabilità note sfruttate attivamente?

Oppure

2. L’aggiornamento sta impattando le operazioni e dobbiamo rallentare (per fortuna la piattaforma di Autonomous Endpoint Management include la distribuzione ad anelli con rollback)?

“Abbiamo Intune”

Microsoft Intune presenta due limiti di ambito che qui contano.

In primo luogo, gestisce solo i dispositivi registrati. Gli endpoint non registrati e non gestiti — server, laptop di collaboratori esterni, shadow IT, dispositivi edge trascurati — restano completamente fuori dalla sua visibilità. Nei periodi di aumento del volume di vulnerabilità, questi punti ciechi si moltiplicano più rapidamente di quanto i team possano gestire manualmente.

In secondo luogo, sebbene Intune semplifichi la distribuzione e gli aggiornamenti delle applicazioni, la copertura delle applicazioni di terze parti e la profondità della prioritizzazione sono più limitate di quanto la maggior parte degli amministratori immagini. Intune può dirti cosa non è aggiornato, ma non cosa aumenta davvero la tua esposizione––costringendo i team ad applicare patch a tutto in modo reattivo, oppure basandosi su ipotesi quando il tempo è poco.

La maggior parte degli ambienti enterprise non è esclusivamente Windows, completamente registrata o basata su uno stack applicativo ridotto e omogeneo. Quando le divulgazioni di vulnerabilità aumentano improvvisamente, instradare il patching lascia lacune e si trasforma in un rischio sistemico.

Mantieni Intune. Affiancalo a un livello di discovery e remediation che trovi gli asset che Intune non riesce a vedere, dia priorità alle vulnerabilità più importanti e applichi le patch con fiducia nelle applicazioni che Intune non copre.

Cosa fare

L’automazione è il modello operativo. Deve essere integrata nel workflow.

I professionisti conoscono questo principio da tempo. Si manifesta in tre aree:

Triage continuo. Le vulnerabilità note sfruttate attivamente possono seguire un percorso di risposta zero-day, soprattutto nelle aree meno sicure dell’organizzazione, come i sistemi degli utenti finali. Inoltre, definisci applicazioni specifiche, come browser e app di telecomunicazione, da aggiornare su un percorso prioritario controllato settimanalmente o anche quotidianamente. Tutto il resto può attendere la finestra di manutenzione ordinaria.
Distribuzione ad anelli con rollback automatizzato. Anello di test, anello early adopter, produzione estesa, sistemi mission-critical. La sequenza è poco entusiasmante, ma funziona per la maggior parte delle attività di manutenzione. Ciò che è cambiato è che alcuni aggiornamenti dovranno essere compressi per rientrare nella finestra di exploit, anziché attendere la manutenzione mensile. L’anello di test deve essere automatizzato e strumentato: una checklist umana non può muoversi a quella velocità.
Verifica a ciclo chiuso. La patch non è distribuita finché non viene verificata l’installazione sull’endpoint, e la CVE non viene chiusa finché una nuova scansione non lo conferma. La maggior parte dei team salta questo passaggio, ed è per questo che la prova di conformità diventa un’emergenza la settimana prima dell’audit. È per questo che questa settimana abbiamo rilasciato la conformità continua nella nostra piattaforma: così le evidenze di conformità vengono prodotte in modo continuo e automatico man mano che le patch vengono distribuite, mentre l’automazione gestisce le decisioni di prioritizzazione per cui la maggior parte dei team non ha capacità disponibile.

Le 271 vulnerabilità di Firefox individuate da Mozilla sono un’anticipazione. Ogni principale vendor software sotto Glasswing sta per iniziare a correggere più vulnerabilità e a un ritmo accelerato, e gli attaccanti con la stessa classe di capacità cercheranno esattamente quelle aperture ogni volta che avranno accesso a un modello simile. La conseguente corsa agli armamenti basata sull’AI avrà un effetto diretto sul numero e sulla frequenza degli aggiornamenti che le organizzazioni dovranno gestire con attività di remediation, e a un ritmo accelerato. L’automazione è ciò che consente a un programma di reggere. I team che ancora applicano patch solo su base mensile si troveranno ad affrontare un periodo difficile.

Se gestisci un programma IT o di sicurezza, vale la pena fare ora un’autovalutazione. Prendi l’ultima patch critica che hai distribuito. Ancora meglio: se uno zero-day uscisse di venerdì, riusciresti a risolverlo entro lunedì? Misura il tempo dalla pubblicazione della CVE all’installazione verificata sull’ultimo endpoint. Se quel numero si misura in settimane, l’apocalisse delle patch ti raggiungerà.

Sovranità digitale e cloud sovrano: proteggere i dati cloud dell’UE per la resilienza operativa

Fri, 17 Apr 2026 12:30:01 Z

La protezione tradizionale dei dati seguiva un principio semplice: i dati archiviati nel Paese A sono protetti dalle leggi del Paese A; i dati archiviati nel Paese B sono protetti dalle leggi del Paese B. Ma nell’economia globale di oggi, il luogo in cui i dati risiedono fisicamente non determina più quali governi possano richiederne l’accesso.

L’infrastruttura cloud ha introdotto una nuova complessità giurisdizionale. L’ubicazione fisica dei data center, la nazionalità della sede centrale del provider cloud e l’entità che controlla le operazioni possono generare rivendicazioni giurisdizionali concorrenti, consentendo potenzialmente a più governi di richiedere l’accesso agli stessi dati.

Che cos’è la sovranità digitale?

Questa sfida ha un nome: sovranità digitale. La sovranità digitale è il principio in base al quale le organizzazioni mantengono il controllo completo dei propri dati nel quadro giuridico della giurisdizione di appartenenza. Questo concetto è diventato una necessità per la resilienza organizzativa, mentre le aziende operano in un contesto geopolitico più frammentato e caratterizzato da minore fiducia. Le organizzazioni private e pubbliche hanno bisogno di un accesso sicuro a piattaforme basate sul cloud che siano conformi ai requisiti normativi locali e protette dai rischi geopolitici, noti o sconosciuti, che interessano la loro area geografica.

In che modo il CLOUD Act statunitense incide sulla residenza dei dati nell’UE

Il CLOUD Act statunitense del 2018 (Clarifying Lawful Overseas Use of Data) ha ulteriormente rafforzato queste preoccupazioni per le organizzazioni dell’UE. Questa legge conferisce alle autorità di contrasto statunitensi il potere di obbligare qualsiasi provider cloud con sede negli Stati Uniti a fornire dati archiviati in qualunque parte del mondo, indipendentemente dalla posizione fisica dei dati o dalla nazionalità del cliente.

Sia il CLOUD Act statunitense sia il Foreign Intelligence Surveillance Act (FISA) hanno dato motivo di preoccupazione alle aziende dell’Unione europea. Attraverso queste due normative, le autorità statunitensi potrebbero accedere ai dati contenuti nelle piattaforme cloud di qualsiasi organizzazione con sede centrale negli Stati Uniti, anche quando il data center cloud si trova in un altro Paese.

Per le aziende con sede nell’UE, l’utilizzo di strumenti statunitensi comporta specifici obblighi GDPR perché i dati personali escono dall’UE. Inoltre, da quando lo Scudo UE-USA per la privacy è stato invalidato (decisione nota come “Schrems II”), le aziende dell’UE hanno bisogno di altre misure di protezione. Le clausole contrattuali standard (SCC) restano valide, ma sono condizionate e complesse, poiché richiedono una valutazione caso per caso.

Da allora è stato introdotto un successivo Data Privacy Framework, ma la fiducia di fondo tra le nazioni coinvolte ha comunque dei limiti. Queste dinamiche hanno aumentato la pressione per garantire la protezione dei dati, rendendo necessarie soluzioni di cloud sovrano per assicurare la resilienza operativa.

Ivanti Neurons for MDM – Sovereign Edition: progettata per la sovranità cloud dell’UE

Per i nostri partner e clienti nell’UE, Ivanti Neurons for MDM Sovereign Edition risponde a questi requisiti attraverso un’architettura e un modello operativo radicalmente diversi. Situata in Germania e gestita in modo indipendente, questa soluzione è stata progettata per allinearsi al Cloud Sovereignty Framework della Commissione europea ed è stata valutata dall’autorevole cyberintelligence.institute, la cui valutazione esperta ha spiegato:

“Ivanti Sovereign Cloud dimostra un elevato livello di controllo europeo nelle aree dell’elaborazione dei dati, della sicurezza e della governance della conformità. Nella sua configurazione attuale, Ivanti Sovereign Cloud raggiunge almeno la certificazione SEAL 2, il che significa che la sovranità dei dati è garantita in tutte le aree. Inoltre, Ivanti Sovereign Cloud soddisfa i requisiti per la certificazione SEAL 3 in molte aree rilevanti, conseguendo così la resilienza digitale.”

È possibile leggere la valutazione tecnica completa per saperne di più.

Raggiungere la conformità alla sovranità dei dati con fiducia

Neurons for MDM – Sovereign Edition – EU offre alle aziende europee una base strategica per la loro piattaforma IT e di sicurezza, fornita da un leader affidabile, mantenendo al contempo le protezioni giurisdizionali locali per la gestione del rischio. Ciò significa che le entità pubbliche e private possono proseguire la propria trasformazione digitale con la certezza che i dati nel cloud resteranno sicuri e che le loro operazioni acquisiranno maggiore resilienza.

Prossimi passi? Leggi il nostro whitepaper Il cloud sovrano come necessità strategica per le organizzazioni europee per scoprire in che modo Ivanti Neurons for MDM Sovereign Edition raggiunge e supera la certificazione SEAL 2 e offre l’architettura di cloud sovrano di cui le organizzazioni europee hanno bisogno per mantenere la sovranità dei dati, abilitando al contempo una trasformazione digitale sicura.

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.

Come i CEO vogliono che i CISO comunichino la strategia di gestione del rischio di cybersicurezza

Tue, 17 Feb 2026 13:00:01 Z

La maggior parte dei CEO sa citare i benchmark trimestrali e i ricavi fino all’ultima cifra decimale, ma se si chiede loro dell’esposizione al rischio cyber della propria organizzazione, le risposte diventano più vaghe. Non è che i CEO di oggi non si interessino alla sicurezza: la cybersicurezza è tra le principali preoccupazioni di consigli di amministrazione e team executive. Il problema è più profondo: una rottura fondamentale nel modo in cui i rischi di sicurezza vengono spiegati ai leader aziendali, che trascura il loro impatto sui risultati di business.

La maggior parte dei problemi di comunicazione tra CISO e CEO non dipende da una mancanza di competenza. Derivano da un problema noto: la maledizione della conoscenza. La maledizione della conoscenza è una sfida comune in cui gli esperti, in questo caso i responsabili della sicurezza, possono dare per scontato che tutti i presenti abbiano una comprensione di base delle informazioni e della terminologia tecnica; di conseguenza, non riescono a spiegare rischi complessi in un linguaggio semplice né a inserirli in un contesto concreto.

Il Report sullo stato della cybersicurezza 2026 di Ivanti evidenzia questa disconnessione. Quasi sei professionisti della sicurezza su dieci affermano che i loro team sono solo moderatamente efficaci nel comunicare l’esposizione al rischio alla leadership executive.

Quando CEO e CISO non parlano la stessa lingua, vulnerabilità aziendali critiche possono essere oscurate dal gergo tecnico. Quando la comunicazione si interrompe, le organizzazioni sprecano tempo e denaro in investimenti non correttamente indirizzati, mentre le lacune nella protezione passano inosservate finché una violazione non costringe ad affrontare il tema.

Con l’aumento dei livelli di minaccia, gli attacchi abilitati dall’AI diventano sempre più sofisticati e le violazioni dei dati finiscono ogni settimana sui giornali. La posta in gioco per una comunicazione chiara tra CISO e leadership executive non è mai stata così alta.

Per capire perché questo divario comunicativo persiste, dobbiamo esaminare sia le sfide fondamentali sia le metriche utilizzate per misurare il successo.

Perché la comunicazione del rischio cyber fallisce: la maledizione della conoscenza

Questa disconnessione tra CEO e CISO non è causata da una mancanza di dati. Semmai, è vero il contrario. Dal punto di vista del CEO, la sfida non riguarda l’attenzione o l’intenzione. Consiste piuttosto nel vedere dashboard, metriche, acronimi e punteggi di gravità senza comprendere l’impatto di questi risultati sull’intera azienda.

I responsabili della sicurezza devono partire dal presupposto che molti dei presenti non comprendano le implicazioni di termini come punteggi CVSS, superfici di attacco e vulnerabilità zero-day. I CEO vogliono più di dashboard piene di metriche, acronimi e punteggi di gravità.

I briefing sulla cybersicurezza devono fare un passo in più e dimostrare le implicazioni finanziarie, legali e reputazionali di questi risultati per l’azienda. Un CISO potrebbe riferire "587 vulnerabilità critiche rilevate questo mese", mentre ciò che il CEO deve davvero sapere è: "Quali di queste minacciano la nostra capacità di servire i clienti e qual è il nostro piano per affrontarle?"

I KPI di cybersicurezza che contano per i CEO

I KPI utili collegano chiaramente le attività di gestione delle vulnerabilità al rischio aziendale. Tuttavia, la nostra ricerca sulla cybersicurezza rileva che i KPI più utilizzati dai team di sicurezza non riescono a riflettere il contesto del rischio.

Attualmente, solo la metà delle aziende (51%) monitora i punteggi di esposizione alla cybersicurezza o altri indici basati sul rischio. Molti team di sicurezza si affidano ancora a metriche di processo, come il tempo medio di correzione (47%) o la percentuale di esposizioni risolte (41%).

Metriche come MTTR, velocità di applicazione delle patch e percentuale di correzioni effettuate sono importanti per i team di sicurezza, ma misurano l’efficienza operativa, non l’esposizione aziendale o il potenziale impatto finanziario. Considerate isolatamente, possono sembrare rassicuranti, pur oscurando la vera domanda: stiamo gestendo il nostro rischio in modo efficace?

Queste metriche, incentrate su rapidità e copertura, possono apparire positive da sole, ma dicono poco sul fatto che le attuali attività di correzione migliorino davvero la postura di rischio. Conta meno quanto rapidamente le vulnerabilità vengono corrette e quante ne vengono affrontate. Ciò che conta di più è se vengono affrontati i problemi giusti.

Una comprensione condivisa tra team di sicurezza, consiglio di amministrazione e C-Suite richiede di collegare metriche poco leggibili a conseguenze concrete. Per i CEO, questo significa allinearsi con il proprio CISO sui rischi più importanti per la specifica organizzazione: la vostra organizzazione è un istituto finanziario che affronta spesso schemi di frode sofisticati, rigorosi requisiti di conformità come PCI-DSS e SOX e la minaccia costante di ransomware che prendono di mira i dati finanziari dei clienti? Oppure un’organizzazione sanitaria alle prese con la protezione di una rete in espansione di dispositivi medici connessi, mantenendo al contempo rigorosi standard di conformità per proteggere i dati sensibili dei pazienti?

Illustriamo la differenza tra un briefing executive sulla sicurezza che si basa solo su metriche tecniche e uno che aggiunge contesto e impatto sul business.

Cosa dice il CISO:

"Abbiamo rilevato 11.000 vulnerabilità".
"L’MTTR è sceso da 25 a 15 giorni".
"Abbiamo raggiunto un tasso di correzione dell’88% sulle CVE critiche".

Cosa deve davvero sapere il CEO:

"Abbiamo identificato dieci vulnerabilità critiche che potrebbero avere un impatto sui sistemi che generano ricavi".
"Se venissimo attaccati oggi, potremmo ripristinare le operazioni critiche in sei ore, rispetto alle 48 ore dello scorso anno".
"Questa protezione ci consente di puntare all’espansione nell’UE senza ulteriori rischi di conformità".

Costruire un framework di propensione al rischio a livello executive

La comunicazione executive dipende da framework condivisi e da un punto di riferimento comune per definire, misurare e discutere il rischio. Per eliminare incoerenze e confusione, tutti gli stakeholder dovrebbero essere coinvolti nella creazione e nell’applicazione di un framework di propensione al rischio.

Uno degli obiettivi principali di queste conversazioni è aiutare i leader aziendali a comprendere che lo scopo del programma di cybersicurezza non è essere completamente “senza rischio”: è impossibile per qualsiasi organizzazione moderna diventare completamente priva di rischi. In altre parole, i CEO devono saper distinguere tra la loro propensione al rischio e la postura di rischio.

1. Propensione al rischio: il livello di rischio che l’azienda è attualmente disposta a tollerare nel perseguimento dei propri obiettivi generali.

2. Postura di rischio: la realtà dell’attuale esposizione al rischio dell’organizzazione.

La maggior parte delle organizzazioni riconosce ormai la necessità di formalizzare il livello di rischio cyber che è disposta ad accettare. La ricerca di Ivanti mostra che oltre l’80% delle organizzazioni dispone di un framework di propensione al rischio documentato.

Tuttavia, meno della metà delle organizzazioni afferma che questi framework vengono seguiti attentamente nelle operazioni quotidiane. Quando i framework esistono sulla carta ma non guidano le decisioni effettive, è molto probabile che la propensione al rischio e la postura di rischio della vostra organizzazione non siano allineate.

In che modo la gestione dell’esposizione colma il divario comunicativo

La gestione dell’esposizione è un approccio basato sul rischio che identifica, prioritizza e convalida in modo continuo la portata delle potenziali minacce nell’intera superficie di attacco. Praticare la gestione dell’esposizione aiuta a unire responsabili della sicurezza e leader executive attorno a una strategia unica e completa, che riorienta la cybersicurezza sul rischio critico per il business.

Invece di trattare tutte le vulnerabilità come equivalenti, la gestione dell’esposizione si concentra sull’identificazione e sulla prioritizzazione dei rischi più elevati per l’organizzazione ponendo queste domande:

Quali esposizioni attuali vengono sfruttate attivamente dagli attori delle minacce?
Quali asset devono essere prioritizzati in base alle attuali operazioni aziendali?
Quali asset, se compromessi, avrebbero il maggiore impatto in termini di danni reputazionali, per i clienti o legali?

Il report di ricerca di Ivanti mostra che quasi due terzi delle organizzazioni investono oggi nella gestione dell’esposizione e che la comprensione da parte della leadership è aumentata anno su anno. Ma l’esecuzione è ancora in ritardo: solo circa un quarto delle organizzazioni valuta come eccellente la propria capacità di valutare l’esposizione al rischio.

Per colmare questo divario e rendere operativa in modo efficace la gestione dell’esposizione, i CISO dovrebbero basare la comunicazione executive su tre principi

1. Tradurre i segnali tecnici in contesto aziendale. Invece di riportare il numero di vulnerabilità, spiegate quali esposizioni incidono sui sistemi che generano ricavi, sui dati dei clienti o sugli ambienti regolamentati.

2. Prioritizzare le minacce emergenti in base all’impatto, non al volume. Gli executive non devono monitorare ogni nuova tecnica di attacco. Devono capire quali situazioni potrebbero interrompere in modo significativo l’attività aziendale e quanto l’organizzazione sia pronta a rispondere.

3. Usare scenari, non fogli di calcolo. Narrazioni basate sui dati, che collegano causa, impatto e risultato, aiutano i leader a interiorizzare il rischio e a prendere decisioni più rapide.

Questo approccio sposta la strategia di mitigazione del rischio da una difesa reattiva a un processo decisionale proattivo.

La strada da seguire

Quando executive e responsabili della sicurezza parlano la stessa lingua, la maledizione della conoscenza può essere superata e la cybersicurezza diventa un abilitatore strategico che protegge il valore aziendale, favorisce la crescita e trasforma la forza della sicurezza in vantaggio competitivo.

La maledizione della conoscenza può essere superata: una metrica tradotta, una conversazione incentrata sul business e una decisione chiara alla volta.

Gestione dell’esposizione vs. gestione delle vulnerabilità: quale consente una reale riduzione del rischio?

Thu, 29 Jan 2026 13:00:01 Z

La gestione delle vulnerabilità supporta da anni le organizzazioni e il settore della cybersecurity. È una pratica efficace che ha aiutato le aziende a difendere la propria superficie di attacco e a impedire agli autori delle minacce di sfruttare le vulnerabilità.

Ma la tecnologia e l’infrastruttura IT si sono evolute. La gestione delle vulnerabilità non è più in grado di affrontare le sfide introdotte da questa evoluzione. Ora la gestione dell’esposizione offre un approccio ancora più olistico alla sicurezza degli endpoint, coprendo le aree in cui la gestione delle vulnerabilità risulta insufficiente.

Analizziamo le differenze per aiutarti a decidere come proteggere la tua organizzazione.

Che cos’è la gestione delle vulnerabilità?

La gestione delle vulnerabilità è una pratica di cybersecurity che include l’identificazione, la valutazione, la prioritizzazione e la correzione continue e proattive delle vulnerabilità che gli hacker possono utilizzare per infiltrarsi nella tua organizzazione.

Tuttavia, è importante notare che esistono due diversi tipi di gestione delle vulnerabilità:

Gestione tradizionale delle vulnerabilità

Gestione delle vulnerabilità basata sul rischio

Consiste nel tentativo di correggere il maggior numero possibile di vulnerabilità. Questo spesso comporta un notevole impegno e aspettative di successo irrealistiche, offrendo al contempo un falso senso di sicurezza.

Una pratica evoluta di gestione delle vulnerabilità che tiene conto del rischio nella prioritizzazione delle vulnerabilità. Ciò consente alle organizzazioni di applicare patch alle vulnerabilità critiche che rappresentano una minaccia reale, proteggendo la tua organizzazione dagli autori delle minacce e garantendo al tempo stesso una solida postura di sicurezza e una gestione efficace delle risorse.

Un approccio di gestione delle vulnerabilità basata sul rischio va oltre la gestione tradizionale delle vulnerabilità, offrendo alla tua organizzazione i seguenti vantaggi:

Monitora continuamente le vulnerabilità per una sicurezza proattiva.
Identifica le esposizioni sfruttate attivamente.
Consente iniziative di correzione efficaci.
Riduce il rischio.
Aiuta le organizzazioni a raggiungere la conformità.

Sebbene la gestione delle vulnerabilità basata sul rischio copra molti aspetti, non offre ancora l’approccio olistico alla cybersecurity di cui le organizzazioni hanno bisogno per rimanere protette e sicure. È qui che entra in gioco la gestione dell’esposizione.

Che cos’è la gestione dell’esposizione?

La gestione dell’esposizione è una pratica di cybersecurity in evoluzione che offre una visibilità completa sull’intera superficie di attacco. Consente ai team IT e di sicurezza di individuare esattamente dove la tua organizzazione potrebbe essere esposta, includendo prioritizzazione basata sul rischio, correzione e molto altro. La gestione dell’esposizione si concentra sul mantenimento della propensione al rischio definita autonomamente dall’organizzazione. Comprende quindi quattro fasi:

Come la gestione delle vulnerabilità basata sul rischio, la gestione dell’esposizione aiuta a dare priorità alle vulnerabilità e alle esposizioni da affrontare per prime in base al rischio reale, ma va oltre considerando ciò che è più rilevante per il tuo specifico business. Questo approccio alla cybersecurity garantisce che le esposizioni a più alto rischio vengano corrette in modo proattivo, prima che possano essere sfruttate dagli attaccanti.

Gestione dell’esposizione vs. gestione delle vulnerabilità: qual è la differenza?

La gestione dell’esposizione rappresenta la successiva evoluzione rispetto alla gestione tradizionale delle vulnerabilità. Mentre la gestione delle vulnerabilità si concentra principalmente sull’identificazione e sulla risoluzione delle debolezze in server ed endpoint, la gestione dell’esposizione amplia questo ambito offrendo visibilità completa sull’intera superficie di attacco.

Le differenze principali includono:

La gestione dell’esposizione è progettata per tipologie di asset più recenti: gli ambienti IT moderni sono diventati sempre più complessi e oggi includono asset come applicazioni Software-as-a-Service (SaaS), dispositivi IoT, infrastrutture cloud e altro ancora. La gestione dell’esposizione è progettata per tenere conto di queste tipologie di asset più recenti, assicurando che i team IT e di sicurezza possano identificare i rischi ovunque si trovino nell’organizzazione. In questo modo, la gestione dell’esposizione offre una comprensione completa di tutti i potenziali punti di ingresso. Ciò consente alle organizzazioni di gestire e ridurre il rischio in modo più efficace che mai.
La gestione dell’esposizione comprende la realtà operativa e promuove un approccio basato sulla propensione al rischio: ancora una volta, la gestione delle vulnerabilità è incentrata sull’applicazione di patch alle vulnerabilità. Sebbene la gestione delle vulnerabilità basata sul rischio offra prioritizzazione del rischio e orchestrazione della correzione, questa pratica non riconosce che non è realistico per un’organizzazione applicare patch a ogni vulnerabilità. Il termine propensione al rischio indica la misura, definita autonomamente da un’organizzazione, del livello di rischio che è disposta ad accettare. È un approccio decisamente più realistico, che coinvolge l’intera organizzazione nel raggiungimento di KPI condivisi per misurare il successo in modo coerente tra i team.
La gestione dell’esposizione va oltre CVE e CVSS: la gestione delle vulnerabilità si concentra principalmente su vulnerabilità ed esposizioni comuni (CVE). Sebbene le CVE siano un obiettivo importante per la maggior parte delle organizzazioni, non sono gli unici fattori che gli autori delle minacce possono usare per causare danni alla tua organizzazione. Gli hacker possono comunque sfruttare le seguenti esposizioni, non coperte dalla gestione delle vulnerabilità, per infiltrarsi nella tua organizzazione:
Configurazioni errate.
Problemi di sicurezza delle applicazioni.
Policy dei sistemi IT.
Controlli degli accessi privilegiati.

Ricollegandoci all’approccio olistico, la gestione dell’esposizione copre tutti questi asset moderni. Inoltre, la gestione delle vulnerabilità dipende fortemente dal Common Vulnerability Scoring System (CVSS) per la prioritizzazione della correzione. Sebbene il CVSS sia una valida misura della gravità, non offre una prospettiva efficace corretta per il rischio.

Il rischio è un fattore importante da tenere presente, perché include elementi come l’eventuale sfruttamento di una vulnerabilità, il suo collegamento a ransomware o malware oppure la sua attuale diffusione. Non considerare il rischio crea un falso senso di urgenza con il CVSS, portando i team IT e di sicurezza a sprecare tempo e risorse su vulnerabilità che non sono realmente urgenti.

Come proteggere la tua organizzazione

Ora che abbiamo esaminato le differenze tra gestione dell’esposizione e gestione delle vulnerabilità, è il momento di sfruttare i vantaggi offerti dalla gestione dell’esposizione. Scopri come il portfolio di gestione dell’esposizione di Ivanti può valorizzare i tuoi team IT e di sicurezza.

DLL hijacking: rischi, esempi reali e come prevenire gli attacchi

Wed, 17 Dec 2025 14:00:02 Z

Si è parlato molto di CVE-2025-56383 (pubblicata il 26 settembre 2025), una vulnerabilità di hijacking in Notepad++ v8.8.3 in cui un file DLL può essere sostituito per eseguire codice dannoso.

La CVE è stata contestata da più parti, ma non è questo l’aspetto su cui intendiamo soffermarci. Vogliamo invece approfondire il DLL hijacking e discutere della minaccia concreta che rappresenta per un’organizzazione. Vediamo cos’è il DLL hijacking e quali misure è possibile adottare per mantenere le DLL al sicuro.

Cos’è il DLL hijacking e come avviene

Il DLL hijacking (noto anche come attacco di preloading delle DLL) è una vulnerabilità di sicurezza in cui un file Dynamic Link Library (DLL) legittimo e attendibile in un’applicazione Windows viene sostituito con un file dannoso.

Questo metodo sfrutta il modo in cui le applicazioni caricano i file DLL, che contengono codice e dati utilizzati da più programmi. Caricando una DLL dannosa, un threat actor può eseguire il proprio codice con gli stessi privilegi dell’applicazione legittima, provocando escalation dei privilegi, persistenza ed evasione delle difese.

Quando un programma si avvia, spesso deve caricare diverse DLL per eseguire funzioni specifiche, in genere da directory di sistema attendibili. Tuttavia, se un’applicazione non presta attenzione al percorso in cui cerca queste DLL, potrebbe caricare una DLL dannosa da una posizione non sicura o prevedibile (ad esempio, la directory di lavoro corrente o una condivisione di rete). Questo può accadere se l’applicazione non specifica il percorso completo della DLL o se la cerca in una directory accessibile o modificabile da un aggressore.

Sebbene questo tipo di attacco non sia nuovo, rimane efficace grazie alla sua semplicità. E anche se questo problema specifico riguarda le applicazioni Windows, è importante sottolineare che vulnerabilità simili possono interessare altri sistemi operativi (come Linux e macOS, che utilizzano il caricamento dinamico per le librerie condivise).

Il DLL hijacking introduce molteplici rischi per la sicurezza, tra cui:

Furto di dati: la DLL dannosa può intercettare e rubare dati sensibili, come password o informazioni personali.
Sistemi compromessi: l’aggressore può ottenere il controllo del sistema, con il rischio di ulteriori attacchi o dell’installazione di malware aggiuntivo.
Malware: la DLL dannosa può fungere da canale per la diffusione di malware, infettando altre parti del sistema o della rete.

Una DLL può essere sottoposta a hijacking in diversi modi; ecco alcune delle tecniche più comuni:

Ordine di ricerca delle DLL non sicuro: gli aggressori inseriscono DLL dannose in directory cercate prima della posizione della DLL legittima.
Manipolazione dei percorsi relativi: le DLL dannose vengono caricate quando le applicazioni utilizzano percorsi relativi.
Reindirizzamento delle DLL: tecniche come la manipolazione dei percorsi reindirizzano il processo di caricamento delle DLL.
Autorizzazioni deboli: gli aggressori sostituiscono DLL legittime con DLL dannose in directory con autorizzazioni deboli.
Phantom DLL hijacking: gli aggressori sfruttano le applicazioni che caricano DLL inesistenti inserendo DLL dannose con lo stesso nome nelle directory oggetto di ricerca.

Queste potenziali vulnerabilità evidenziano l’importanza di pratiche di sviluppo sicuro e della gestione delle autorizzazioni delle directory per prevenire questa forma di attacco.

Come prevenire il DLL hijacking e mantenere le DLL al sicuro

Sebbene il DLL hijacking rimanga una minaccia, esistono best practice da seguire e implementare per ridurre il rischio e creare un ambiente IT più sicuro e protetto.

Caricamento sicuro delle DLL:

Utilizzare percorsi completi: specificare sempre il percorso completo della DLL quando viene caricata. In questo modo l’applicazione carica la DLL da una posizione attendibile (e non da una directory non sicura).
Impostare un percorso di ricerca sicuro: utilizzare la funzione SetDllDirectory in Windows per aggiungere directory attendibili al percorso di ricerca ed escludere quelle non sicure. Questo può aiutare a impedire all’applicazione di caricare DLL da posizioni inattese.

Controlli di integrità dei file:

Firme digitali: assicurarsi che le DLL siano firmate con una firma digitale e verificare la firma prima di caricare la DLL. Questo può aiutare a confermare che la DLL non sia stata manomessa.
Verifica dell’hash: utilizzare funzioni hash crittografiche per verificare l’integrità dei file DLL. Se l’hash della DLL non corrisponde al valore previsto, il file potrebbe essere stato modificato.

Autorizzazioni degli utenti:

Principio del privilegio minimo: eseguire le applicazioni con il privilegio minimo necessario. Ciò limita il potenziale danno di un DLL hijacking, poiché il codice dannoso disporrà di meno autorizzazioni per eseguire azioni nocive.
Controllo dell’account utente (UAC): abilitare UAC sui sistemi Windows per richiedere agli utenti l’autorizzazione prima di eseguire applicazioni con privilegi elevati. Questo può aiutare a prevenire modifiche non autorizzate ai file di sistema.

Controllo delle applicazioni e gestione dei privilegi:

Applicazioni note e attendibili: il controllo delle applicazioni garantisce che possano essere avviate solo applicazioni note e attendibili, eliminando il rischio di introdurre applicazioni non autorizzate.
Controllo dei privilegi: una gestione efficace dei privilegi è fondamentale per prevenire il DLL hijacking. Assicurando che le applicazioni dispongano dei diritti e dei privilegi corretti per l’avvio, si limita la possibilità per gli utenti non autorizzati di introdurre file dannosi. Questo controllo agisce come una barriera chiave, limitando l’accesso di cui un aggressore ha bisogno per sfruttare il meccanismo di ricerca delle DLL e migliorando così la sicurezza dell’ambiente.

Software di sicurezza:

Antivirus e anti-malware: utilizzare software antivirus e anti-malware affidabili per rilevare e impedire il caricamento di DLL dannose. Questi strumenti possono eseguire scansioni alla ricerca di file e comportamenti dannosi noti.
Sistemi di rilevamento delle intrusioni (IDS): implementare IDS per monitorare attività insolite, come modifiche inattese ai file DLL o tentativi di caricare DLL da posizioni non sicure.

Gestione delle patch:

Mantenere aggiornato il software: aggiornare regolarmente applicazioni e sistemi operativi con le patch di sicurezza più recenti. Molte vulnerabilità di DLL hijacking vengono risolte tramite aggiornamenti, quindi restare al passo aiuta a proteggersi dalle minacce note.
Patching automatizzato: utilizzare uno strumento di gestione automatizzata delle patch per garantire che tutti i sistemi siano mantenuti aggiornati senza intervento manuale. Questo riduce la finestra di opportunità per gli aggressori di sfruttare vulnerabilità note, incluse quelle che potrebbero essere utilizzate per il DLL hijacking. Questo approccio proattivo aiuta a mantenere l’integrità delle applicazioni e dei sistemi operativi, rendendo molto più difficile per gli aggressori inserire DLL dannose.

Implementando queste best practice, è possibile ridurre in modo significativo il rischio di DLL hijacking e migliorare la sicurezza complessiva di applicazioni e sistemi.

Combinare strumenti e tattiche adeguati per prevenire il DLL hijacking

Il DLL hijacking è una forma di attacco persistente da anni, a dimostrazione del fatto che è ancora efficace e continuerà quindi a rappresentare un problema per le organizzazioni.

Prepara la tua organizzazione al futuro utilizzando le best practice citate sopra insieme a soluzioni comprovate come Ivanti Neurons for App Control per contribuire a mantenere sicure le DLL. Funzionalità come Trusted Ownership rilevano e impediscono l’esecuzione di una DLL sottoposta a hijacking verificando che la proprietà degli elementi corrisponda all’elenco approvato di proprietari attendibili.

Inoltre, mantieni aggiornate le app per limitare l’esposizione alle vulnerabilità note. Elimina il rischio di errore umano automatizzando il patching con Ivanti Neurons for Patch Management, assicurando che i sistemi siano aggiornati e protetti automaticamente.

ITAM: la prima linea di difesa inattesa contro le minacce informatiche

Tue, 16 Dec 2025 14:00:02 Z

Quando si parla di cybersecurity, spesso si pensa a firewall, sistemi di rilevamento delle intrusioni o protezione degli endpoint all’avanguardia. Tuttavia, sotto questi scudi sofisticati si trova una base essenziale, e spesso poco celebrata: un solido IT Asset Management (ITAM).

Per i CIO che guidano organizzazioni di medie dimensioni ed enterprise in uno scenario digitale sempre più rischioso, l’ITAM offre non solo chiarezza operativa, ma anche una potente prima linea di difesa contro le minacce informatiche.

Di seguito analizzeremo in che modo un ITAM completo offre una visibilità fondamentale sull’ambiente tecnologico dell’organizzazione, rafforza le difese contro minacce informatiche in continua evoluzione, supporta la conformità normativa e accelera le operazioni di sicurezza. Continua a leggere per scoprire come rendere l’ITAM una parte centrale della tua strategia possa contribuire a prevenire violazioni costose e a costruire una vera resilienza informatica.

Gli attacchi informatici globali sono aumentati del 30% su base annua e gli attacchi ransomware registrano oggi in media 20–25 incidenti gravi al giorno.

Perché l’ITAM è importante: le sfide della cybersecurity iniziano da una visibilità limitata

Le minacce informatiche sfruttano quasi sempre le debolezze che le organizzazioni non riescono a vedere. Shadow IT, dispositivi obsoleti, software non autorizzato e punti di accesso non approvati sono vulnerabilità invisibili che sfuggono ai controlli della sicurezza tradizionale. Un inventario completo degli asset non è solo una buona pratica di gestione: è il punto di partenza per un’efficace gestione del rischio informatico.

Nonostante il 90% delle organizzazioni dichiari solide capacità di rilevamento, il 57% ha comunque subito incidenti di sicurezza gravi a causa della mancanza di piena visibilità.

Considera questo dato: nel 2023 Data Breach Investigations Report, Verizon ha rilevato che una quota significativa degli incidenti di intrusione derivava da asset trascurati: server rimasti senza patch perché dimenticati, endpoint provisionati senza visibilità sul loro ciclo di vita e così via.

In questo contesto, l’ITAM è un prezioso sistema di allerta precoce. Fornendo una mappa in tempo reale, continuamente aggiornata, di tutti gli asset hardware, software e cloud, consente ai responsabili IT di individuare i rischi prima degli attaccanti.

I vantaggi dell’ITAM per la resilienza informatica

Di seguito vedremo come i diversi vantaggi di un ITAM solido contribuiscano a una postura di sicurezza più robusta per la tua organizzazione.

La gestione del ciclo di vita elimina gli anelli deboli

Gli asset non comportano rischi solo al momento dell’acquisizione. Il ciclo di vita, dall’onboarding alla manutenzione e agli aggiornamenti fino alla dismissione finale, è ricco di occasioni di gestione inadeguata che possono aprire potenziali varchi agli avversari informatici. Sistemi obsoleti senza supporto del fornitore, software a fine vita ancora in esecuzione per applicazioni mission-critical, dispositivi dismessi senza cancellazione dei dati: sono situazioni comuni negli ambienti complessi.

Il 45% delle organizzazioni non ha piena fiducia nella propria capacità di conoscere tutte le applicazioni in uso, creando punti ciechi che gli attaccanti sfruttano.

Un ITAM solido garantisce che ogni asset venga tracciato, valutato regolarmente e dismesso in modo sicuro, eliminando sia esposizioni accidentali sia attacchi sofisticati mirati all’infrastruttura legacy.

La conformità normativa dimostra il controllo e previene le sanzioni

Sempre più spesso, i CIO operano in contesti normativi che richiedono un controllo dimostrabile sugli asset IT. Framework come NIST, ISO 27001 e GDPR pongono tutti l’accento sulla visibilità degli asset come prerequisito per un controllo efficace dei dati sensibili e delle infrastrutture critiche. Una pratica ITAM matura si allinea direttamente a questi requisiti, fornendo la documentazione e la supervisione dimostrabile necessarie per audit e richieste normative.

Oltre l’80% delle violazioni è collegato a lacune nella gestione della superficie di attacco, determinate da asset esposti a Internet vulnerabili e da pratiche carenti di inventario degli asset.

Ad esempio, ai sensi del GDPR, la capacità di identificare e correggere rapidamente gli asset vulnerabili che trattano dati personali non è solo una buona pratica di sicurezza: è una necessità legale.

La partnership tra ITAM e sicurezza: oltre il semplice monitoraggio dell’inventario

Un vero ITAM va oltre la gestione di elenchi. L’asset management integrato alimenta direttamente gli strumenti per le operazioni di sicurezza con il contesto necessario. Gli scanner di vulnerabilità dipendono da inventari accurati per rilevare le esposizioni. La risposta agli incidenti si basa sulla conoscenza precisa dei sistemi coinvolti. L’applicazione delle policy di sicurezza richiede una chiara comprensione dei ruoli e delle relazioni degli asset.

A titolo di esempio, un istituto finanziario ha dimezzato i tempi di risposta agli incidenti dopo aver integrato i dati ITAM nella propria piattaforma SIEM, consentendo ai team di sicurezza di individuare e isolare immediatamente gli asset interessati durante una violazione. Il valore, in questo caso, è misurabile e replicabile.

Una difesa informatica resiliente richiede un asset management solido

L’IT Asset Management non è semplicemente una questione di igiene operativa. È un componente essenziale di una strategia di cybersecurity proattiva e resiliente. Per i CIO, investire in una solida soluzione ITAM può fare la differenza tra una sicurezza superficiale e una reale mitigazione del rischio.

Se desideri scoprire come la nostra soluzione ITAM può rafforzare la postura di sicurezza della tua organizzazione dalle fondamenta, contatta il nostro team oggi stesso e compi il primo passo verso la costruzione di una vera resilienza informatica.

La shadow AI sta ridefinendo in silenzio la postura di sicurezza del tuo ambiente di lavoro?

Mon, 15 Dec 2025 14:00:01 Z

Gli strumenti di IA hanno registrato una crescita rapidissima sul luogo di lavoro. Quello che un tempo era appannaggio di ruoli tecnologici altamente specializzati oggi è diventato comune: il Technology at Work Report 2025 di Ivanti ha rilevato che il 42% degli impiegati dichiara di utilizzare strumenti di IA generativa, come ChatGPT, al lavoro: 16 punti in più rispetto all’anno precedente.

Il problema? Questi incrementi di produttività avvengono sottotraccia. Tra coloro che hanno dichiarato di utilizzare strumenti di IA generativa, il 46% afferma che alcuni, o tutti, gli strumenti che utilizza non sono forniti dal datore di lavoro. Inoltre, un lavoratore su tre tiene nascosti al proprio datore di lavoro gli strumenti di IA per la produttività.

Gli strumenti di IA generativa possono moltiplicare la produttività. Ma rappresentano anche un rischio per la sicurezza dei dati, soprattutto quando vengono utilizzati senza la supervisione del datore di lavoro.

Che cos’è la shadow AI?

L’uso non autorizzato dell’IA è semplicemente un’altra forma di shadow IT, ossia l’utilizzo di tecnologie senza l’approvazione dell’IT.

I rischi introdotti dalla shadow AI sono simili ad altri rischi della shadow IT, ma con un ulteriore livello di preoccupazione: l’enorme quantità di dati proprietari di cui l’IA generativa ha bisogno per essere efficace. Gli strumenti gratuiti di IA generativa, e anche alcuni strumenti a pagamento, possono utilizzare i dati di un’organizzazione o le ricerche dei dipendenti per addestrare il proprio modello, amplificando il rischio di fughe di dati e di non conformità.

La recente rivelazione secondo cui le conversazioni ChatGPT condivise erano indicizzabili dai motori di ricerca (sebbene OpenAI abbia rapidamente cambiato rotta) dovrebbe essere un campanello d’allarme: senza controlli adeguati, terze parti possono utilizzare i tuoi dati in modi che non approvi. Alcuni strumenti gratuiti, incluso ChatGPT, possono essere configurati per soddisfare le policy di sicurezza, ma questo non è semplicemente possibile quando i dipendenti li utilizzano di nascosto.

Gli strumenti gratuiti come ChatGPT non sono l’unico rischio di shadow AI. Una fonte inaspettata è in realtà il software esistente. Con la corsa all’aggiunta di funzionalità di IA, strumenti che in precedenza potevano essere stati approvati dall’IT potrebbero ora comportare nuovi rischi e, se i team infosec non conoscono e non valutano queste nuove funzionalità, di fatto aggirano i processi di gestione del rischio di terze parti.

Perché un approccio risk-first all’IA è fondamentale

Che si tratti di IA generativa o di altri strumenti, la shadow IT è il risultato dell’assenza di un modo definito e ragionevole per testare gli strumenti o portare a termine il lavoro. Dato che l’IA non è destinata a scomparire, le aziende devono affrontarne l’adozione in modo proattivo, perché vietare gli strumenti non significa che i dipendenti non cercheranno di utilizzarli per aumentare la produttività e semplificare il proprio lavoro.

Dedico gran parte del mio tempo alla valutazione del rischio, inclusi i rischi posti dagli strumenti di IA. Spesso dobbiamo valutare il rischio in relazione a un’opportunità di migliorare il business: in questo caso, gli incrementi di produttività dei dipendenti e gli impatti di secondo livello, come la soddisfazione dei dipendenti o il tempo disponibile per lavorare su progetti più strategici.

In breve, dobbiamo chiederci: esiste un modo per introdurre gli strumenti richiesti dai dipendenti e coglierne i vantaggi mantenendo il rischio a un livello accettabile?

È qui che entra in gioco un approccio risk-first. Un approccio risk-first all’adozione dell’IA si concentra sui dati che devono essere immessi nell’IA e su come la terza parte gestisce tali dati. Questo approccio è simile alla gestione del rischio dei fornitori, consentendo alle organizzazioni di utilizzare pratiche e processi consolidati, ma adattati a domande specifiche sull’IA.

Le domande chiave da porsi includono:

I nostri dati verranno utilizzati per addestrare il modello di IA?
Per quanto tempo vengono conservati i nostri dati?
Quali protezioni esistono per ridurre il rischio di esposizione dei nostri dati?
Chi detiene i diritti sulla proprietà intellettuale generata utilizzando l’IA?

Ridurre al minimo la proliferazione dell’IA è una parte essenziale di questo lavoro. Man mano che un numero crescente di fornitori introduce strumenti di IA specializzati, e che si aggiungono nuovi fornitori concedendo ai loro strumenti di IA l’accesso ai dati, il rischio aumenta. Lo stesso vale per gli strumenti esistenti che introducono improvvisamente l’IA senza modifiche ai costi o ai contratti, rendendo difficile mantenere un inventario accurato degli strumenti di IA.

Adottare un framework di governance dell’IA in Ivanti

In Ivanti contrastiamo la shadow AI con un approccio risk-first che inizia e finisce con il coinvolgimento dei dipendenti.

Portare l’uso dell’IA fuori dall’ombra

Sebbene non incoraggeremmo mai la shadow AI, i dipendenti che la utilizzano hanno conoscenze preziose da condividere su come integrare l’IA nei workflow. Quindi, invece di vietare qualsiasi utilizzo dell’IA, dobbiamo assicurarci che i dipendenti dispongano di un percorso chiaro per richiedere strumenti di IA da usare al lavoro e che vi siano occasioni regolari di dialogo aperto.

Favorire un dialogo aperto mette i dipendenti a proprio agio nel discutere quali strumenti li aiutano ad avere successo e, in ultima analisi, significa che li useranno, o useranno strumenti equivalenti, in modo sicuro. Questo offre ai dipendenti l’opportunità di essere partner attivi nello sviluppo di una governance adeguata, anziché cercare di aggirare le restrizioni.

Un approccio misurato all’implementazione e all’adozione dell’IA

Una volta approvato uno strumento, è importante garantirne la corretta implementazione e comprendere a quali dati gli è stato concesso accesso. Questo è particolarmente importante se si considerano la governance dei dati e il rischio per la sicurezza che gli strumenti di IA generativa comportano per le organizzazioni. Osservare l’IA attraverso la lente della governance dei dati può aiutare ad affrontare molte componenti del rischio legato all’IA.

In Ivanti adottiamo un approccio misurato: dedichiamo un team all’esecuzione di test controllati degli strumenti di IA generativa con altri team. Quindi definiamo cicli di feedback e l’adozione procede gradualmente per evitare interruzioni.

Creare un ciclo di feedback per gli strumenti di IA

Dobbiamo chiederci costantemente:

In che modo i dipendenti di Ivanti utilizzano l’IA?
La trovano utile?
Quali feedback hanno?
Come possiamo migliorare lo strumento?

Questa conversazione continua garantisce che utilizziamo l’IA in modo responsabile, soddisfacendo al contempo le esigenze di produttività dei dipendenti.

Non si tratta di salire sul carro dell’IA. Si tratta di capire se ne vale la pena, per l’azienda e per le persone che la utilizzano. La shadow AI aumenta la produttività di una singola persona. Ma se si estende quella produttività, si ottiene un miglioramento significativo per l’azienda nel suo complesso.

Contrastare proattivamente la shadow AI

Il filo conduttore è che, anche se l’IA, e in particolare la shadow AI, comporta rischi nuovi e preoccupanti, è destinata a rimanere. I dipendenti che usano l’IA sottotraccia non hanno cattive intenzioni; semmai, stanno cercando di portare beneficio all’azienda, anche se lo fanno nel modo sbagliato.

Un approccio proattivo e risk-first all’adozione dell’IA riconosce questa realtà. Invece di divieti reattivi che non fanno che incoraggiare l’aggiramento delle regole, dobbiamo coinvolgere i dipendenti per comprendere i problemi che cercano di risolvere con l’IA, così da poter offrire loro opzioni sicure che soddisfino i nostri requisiti di sicurezza e privacy dei dati.

Perché SELinux è importante per la sicurezza aziendale

Thu, 23 Oct 2025 14:03:35 Z

Quando si valutano prodotti di cybersecurity, è facile concentrarsi su funzionalità di superficie come dashboard, avvisi e integrazioni. Ma la vera solidità spesso risiede più in profondità, nell’architettura stessa. Una funzionalità integrata che dimostra principi rigorosi di progettazione della sicurezza è Security-Enhanced Linux (SELinux).

Sviluppato originariamente dalla National Security Agency (NSA) degli Stati Uniti e rilasciato alla community open source, SELinux è un framework di controllo di accesso obbligatorio (mandatory access control, MAC) integrato nel kernel Linux. Applica regole rigorose, basate su policy, che governano il modo in cui applicazioni, servizi e utenti interagiscono con le risorse di sistema, rendendolo una difesa efficace contro l’escalation dei privilegi, il movimento laterale e gli exploit zero-day.

Se il prodotto di cybersecurity che stai valutando include SELinux, soprattutto in modalità enforcing, è un forte indicatore di maturità architetturale e di contenimento proattivo delle minacce.

Cosa rende SELinux diverso e migliore?

SELinux etichetta ogni processo e file con un contesto di sicurezza e utilizza policy predefinite per controllare il modo in cui interagiscono. A differenza dei controlli di accesso tradizionali, che si basano sui permessi utente, SELinux applica policy di sicurezza a tutti gli utenti e processi, anche a quelli con privilegi root (amministratore).

Questo è un aspetto fondamentale perché impedisce agli aggressori di sfruttare l’accesso root per muoversi lateralmente, esfiltrare dati o disabilitare i controlli di sicurezza. In sostanza, SELinux elimina lo status di “superpotere” di root, applicando limiti di sicurezza definiti dalle policy, non dai privilegi.

Ciò significa che, anche se un aggressore ottiene un accesso privilegiato (ovvero root), SELinux può impedirgli di eseguire azioni non autorizzate che deviano dalla policy preimpostata. Questo livello di sicurezza va oltre il rilevamento, includendo la prevenzione a livello di sistema operativo.

Come funziona SELinux

SELinux opera in più modalità:

Disabilitata: non attiva, nessuna applicazione della sicurezza.
Permissiva: registra le violazioni ma non le blocca; utile per i test.
Enforcing: blocca attivamente le azioni non autorizzate in base alla policy.
Applicazione rigorosa: si riferisce alla modalità enforcing combinata con una policy rigorosa applicata per impostazione predefinita.

I prodotti che eseguono SELinux in modalità enforcing rigorosa offrono protezione in tempo reale dei processi e delle risorse del sistema. La superficie di attacco è ridotta al minimo, rendendo significativamente più difficile per gli aggressori muoversi all’interno del sistema. Ogni utente, servizio e daemon è soggetto a un controllo di accesso obbligatorio basato sul principio del privilegio minimo. L’applicazione rigorosa è tipicamente utilizzata in ambienti ad alta sicurezza (ad esempio pubblica amministrazione, finanza, difesa), dove nessun processo è considerato attendibile per impostazione predefinita e ogni interazione deve essere esplicitamente consentita dalla policy.

Anche se non configurerai SELinux direttamente, è utile comprendere come vendor come Ivanti lo utilizzano per rafforzare i propri prodotti:

1. Avvio in modalità permissiva: iniziamo osservando il comportamento del sistema in base alle policy SELinux senza bloccare nulla.

2. Test estesi: registriamo le violazioni, identifichiamo le operazioni legittime e perfezioniamo le policy per evitare falsi positivi.

3. Sviluppo di policy personalizzate: le policy sono adattate all’architettura e ai casi d’uso del prodotto.

4. Convalida in laboratorio in modalità enforcing: prima del rilascio, testiamo SELinux nelle modalità enforcing e di applicazione rigorosa in condizioni simulate del mondo reale.

Questo processo garantisce che SELinux migliori la sicurezza senza compromettere le funzionalità e che gli utenti ottengano una protezione ottimale senza compromessi sulle prestazioni. Inoltre, il processo descritto sopra viene eseguito per ogni release: ciò significa che, man mano che il software evolve verso versioni più recenti, la policy SELinux deve essere testata, ottimizzata e ripetuta con ogni nuova versione del prodotto software.

Questo processo richiede tempo e notevoli risorse di sviluppo per essere eseguito correttamente. Solo i vendor di sicurezza più impegnati e proattivi configurano SELinux con applicazione rigorosa.

Esempio reale: distribuzione di Oracle Linux

Oracle Linux supporta SELinux in modalità enforcing ed è ampiamente utilizzato per proteggere ambienti di database Oracle e workload su Oracle Cloud Infrastructure. SELinux contribuisce a isolare i processi, applicare il privilegio minimo e proteggere i dati sensibili dall’accesso non autorizzato, anche in implementazioni aziendali complesse.

Per gli acquirenti, questo significa che i prodotti basati su Oracle Linux con SELinux abilitato, incluso Ivanti Connect Secure, sono già rafforzati contro molte classi di attacco. (Puoi trovare maggiori dettagli nella guida ufficiale di Oracle.)

Tecnologia di sicurezza che offre valore di business

Quando SELinux è integrato in una soluzione di cybersecurity, la tecnologia offre vantaggi strategici allineati alle priorità aziendali.

Preparazione ad audit e conformità: SELinux registra ogni tentativo di accesso, riuscito o negato, creando una ricca traccia di audit. L’applicazione e la traccia di audit di SELinux aiutano a soddisfare requisiti normativi come CIS Level-1/2 Hardening, STIG, NIST-800 e altre normative che richiedono l’hardening del sistema.
Controllo granulare degli accessi: regole dettagliate vengono applicate a livello di processo, limitando l’accesso anche agli utenti root. Questo riduce il rischio di escalation dei privilegi e di minacce interne, aspetto particolarmente importante negli ambienti con dati sensibili o ruoli utente complessi.
Superficie di attacco ridotta: SELinux isola i processi e applica l’accesso con privilegio minimo, impedendo il movimento laterale all’interno del sistema. Questa strategia di contenimento è fondamentale per limitare il raggio d’impatto di qualsiasi violazione. SELinux blocca le azioni non autorizzate a livello di sistema operativo, rendendo più difficile per gli aggressori sfruttare le vulnerabilità, inclusi gli zero-day.
Garanzia di livello enterprise: vendor come Ivanti, che utilizzano SELinux nei propri prodotti, dimostrano un impegno significativo verso le best practice di sicurezza. Questo approccio supporta la gestione del rischio, rafforza la fiducia e differenzia nettamente la soluzione in un mercato competitivo.
Stabilità operativa: quando le policy sono configurate correttamente, SELinux opera silenziosamente in background, applicando la sicurezza senza impattare sulle prestazioni: un aspetto ideale per ambienti mission-critical in cui l’uptime è essenziale.

Considerazioni finali sul valore di SELinux

Gli acquirenti che valutano prodotti di cybersecurity dovrebbero guardare oltre le funzionalità di superficie e chiedersi cosa protegga il sistema al suo livello più profondo. SELinux è una di quelle tecnologie “sotto il cofano” che applica silenziosamente una protezione reale, bloccando le azioni non autorizzate (anche da parte di utenti privilegiati) e contenendo le minacce prima che si diffondano.

La sua presenza in un prodotto segnala un’architettura rafforzata, un contenimento proattivo delle minacce e un vendor che prende sul serio l’integrità del sistema. Non dovrai configurarlo direttamente, ma ne trarrai vantaggio ogni volta che un exploit non riuscirà a prendere piede.

L’impegno di Ivanti per la sicurezza

Ivanti è stata tra le prime aziende ad aderire all’impegno “Secure by Design” di CISA nel 2024. Nell’ambito di questa iniziativa, Ivanti ha investito significativamente nell’hardening del prodotto Connect Secure, nella modernizzazione del suo sistema operativo e nell’integrazione della sicurezza in ogni livello dello sviluppo.

Alla base della filosofia di sviluppo di Ivanti c’è il nostro Secure Software Development Lifecycle (SSDLC), che abilita i sette elementi chiave del Secure Software Design: Security as Code (SaC), Secure by Default, Least Privilege, Separation of Duties (SoD), Minimize Attack Surface Area (ASA), Complete Mediation e Failing Securely. Inoltre, Ivanti segue anche il proprio rigoroso Secure Application Development Standard, che impone la conformità agli OWASP Application Security Verification Standards (ASVS). Insieme, questi framework rigorosi garantiscono che ogni funzionalità del prodotto sia progettata e implementata considerando la sicurezza come priorità, offrendo ai clienti soluzioni che soddisfano i più elevati benchmark del settore.

Individuazione della superficie di attacco: come identificare la superficie di attacco della tua organizzazione

Mon, 18 Aug 2025 09:54:55 Z

Proprio come un prato dopo una bella pioggia, la tua superficie di attacco crescerà rapidamente se non viene tenuta sotto controllo. E all’aumento delle dimensioni della superficie di attacco corrisponde un aumento del rischio di cybersecurity. Sebbene il rischio non possa essere eliminato del tutto (perché le superfici di attacco sono in continua evoluzione), puoi gestirlo per mantenere i livelli di rischio complessivi in linea con la tua propensione al rischio.

Perché l’individuazione della superficie di attacco è così importante?

La gestione del rischio di cybersecurity inizia con l’identificazione della superficie di attacco della tua organizzazione. Più nello specifico, devi identificare ciò che si nasconde sotto la superficie: endpoint, vulnerabilità e altri vettori di attacco che espongono il tuo ambiente.

I principali framework di sicurezza concordano sul fatto che l’individuazione della superficie di attacco sia essenziale per una solida postura di sicurezza. Ad esempio, la prima Funzione del National Institute of Standards and Technology Cybersecurity Framework (NIST CSF) Versione 1.1 è Identify, e il NIST afferma: “Le attività nella Funzione Identify sono fondamentali per un uso efficace del Framework”. Analogamente, CIS Controls v8 include i seguenti Controlli:

Controllo 1 — Inventario e controllo degli asset aziendali
Controllo 2 — Inventario e controllo degli asset software
Controllo 7 — Gestione continua delle vulnerabilità

In parole semplici, non puoi difendere ciò che non sai di avere. Ma come fai a capire di che cosa disponi?

Come iniziare con l’individuazione della superficie di attacco?

L’individuazione della superficie di attacco richiede di osservare la tua organizzazione dal punto di vista di un attaccante, per individuare asset sfruttabili e vulnerabilità associate.

La tua superficie di attacco ha tre componenti: una superficie di attacco digitale, una superficie di attacco fisica e una superficie di attacco umana. Qui ci concentreremo principalmente sull’individuazione della superficie di attacco digitale, pur accennando brevemente anche agli altri due aspetti.

La tua superficie di attacco digitale include gli asset IT tradizionali — hardware, come endpoint e server, oltre alle applicazioni software — e gli asset esterni esposti a Internet, come applicazioni web, IP, nomi di dominio, certificati SSL e servizi cloud.

Il primo passo consiste nel censire ogni elemento della superficie di attacco digitale e identificare le lacune di visibilità. Puoi classificare ogni elemento come segue:

Noto noto: asset cyber che sai far parte della tua superficie di attacco.
Noto ignoto: asset cyber che sai far parte della tua superficie di attacco, ma sui quali potresti non avere visibilità e/o che non hai sotto gestione.
Ignoto ignoto: asset cyber che potrebbero far parte o meno della tua superficie di attacco: non lo sai.
N/D: asset cyber che sai con certezza al 100% non far parte della tua superficie di attacco.

Per una panoramica più completa degli elementi della tua superficie di attacco, usa la nostra checklist modificabile per la superficie di attacco per effettuare l’inventario.

Strumenti per individuare e gestire la superficie di attacco

Il passo successivo, dopo aver classificato le tipologie di asset, è capire quali strumenti o approcci ti consentiranno di colmare le lacune di visibilità, trasformando i noti ignoti e gli ignoti ignoti in noti noti.

Esistono soluzioni più specifiche che rientrano nell’ampio ambito della gestione della superficie di attacco — cyber asset attack surface management (CAASM), external attack surface management (EASM) e digital risk protection services (DRPS). Questi strumenti aggregano i risultati per identificare più facilmente le vulnerabilità; alcuni offrono anche funzionalità per assegnare priorità e correggere tali vulnerabilità, consentendoti di agire rapidamente sugli insight relativi alla superficie di attacco e ridurre il rischio.

Tuttavia, le organizzazioni avevano bisogno di individuare e gestire le proprie superfici di attacco digitali già prima che fossero disponibili le soluzioni ASM. Al posto delle soluzioni ASM, molte organizzazioni hanno adottato — e continuano ad adottare — altri approcci per farlo.

Approccio	Descrizione	Pro	Contro
Strumenti di individuazione degli asset	Individuano e inventariano gli asset hardware e software che si connettono alla rete.	Già implementati nella maggior parte delle organizzazioni. Meglio dei fogli di calcolo.	Possono presentare punti ciechi, come shadow IT, sistemi di terze parti e applicazioni line-of-business.
Simulazione di violazioni e attacchi (BAS)	Testa automaticamente i vettori di minaccia per comprendere più a fondo le vulnerabilità della postura di sicurezza e convalidare i controlli di sicurezza.	Genera report sui gap di sicurezza e assegna priorità agli interventi di correzione in base al rischio.	Si concentra solo sugli attacchi noti. Non fornisce funzionalità di correzione.
Cloud security posture management (CSPM)	Comprende i cambiamenti nelle configurazioni cloud.	Offre visibilità in tempo reale sulle configurazioni cloud.	Non rileva quando le configurazioni si discostano dalla conformità né il potenziale impatto delle minacce emergenti.
Configuration management database (CMDB)	Tiene traccia delle modifiche apportate ai sistemi.	Già implementato nella maggior parte delle organizzazioni.	Non rileva quando le configurazioni si discostano dalla conformità né il potenziale impatto delle minacce emergenti.
Approccio sviluppato internamente	Combina fogli di calcolo, script e processi manuali per gestire la superficie di attacco.	Economico o gratuito dal solo punto di vista dei costi (senza considerare le ore degli analisti).	Richiede molto tempo ed è soggetto a errori. Non è scalabile né in tempo reale.
IT asset management (ITAM)	Tiene traccia degli asset e li monitora lungo tutto il loro ciclo di vita.	Già implementato nella maggior parte delle organizzazioni. Meglio dei fogli di calcolo.	Copre solo gli asset noti e gestiti, trascurando le componenti sconosciute o non gestite della superficie di attacco.
Penetration testing (ad es. strumenti di penetration testing automatizzato e penetration testing as a service)	Identifica le vulnerabilità all’interno della rete e delle applicazioni simulando un cyberattacco.	Fornisce esempi della postura di sicurezza e delle relative priorità di budget.	Si concentra solo sulla prima fase della cyber kill chain: la ricognizione. Inoltre, i risultati sono in genere puntuali e validi solo quanto lo sono i penetration tester che eseguono la simulazione.
Red teaming	Fornisce un quadro completo della postura di cybersecurity di un’organizzazione attraverso una simulazione di cyberattacco contro reti, applicazioni, misure di protezione fisiche e dipendenti.	Va oltre il penetration testing concentrandosi su altre fasi della cyber kill chain. Inoltre, va oltre la superficie di attacco digitale e tocca anche le superfici di attacco fisica e umana.	I risultati sono in genere puntuali e validi solo quanto lo sono i penetration tester che eseguono la simulazione.
Threat intelligence	Accede a informazioni su minacce e altre problematiche di cybersecurity.	Fornisce agli esperti di sicurezza intelligence su minacce e vulnerabilità.	Pensata per organizzazioni con operazioni di sicurezza molto mature, composte da personale qualificato e risorse estese.
Strumenti di gestione delle vulnerabilità (ad es. scanner)	Identificano e gestiscono le vulnerabilità all’interno dell’infrastruttura e delle applicazioni.	Già implementati nella maggior parte delle organizzazioni.	Nessuna visibilità sugli asset sconosciuti. Quantità di dati eccessive.

Sebbene questi metodi non offrano tutte le funzionalità di una soluzione ASM appositamente progettata, svolgono comunque un ruolo importante nelle pratiche IT e di sicurezza di un’organizzazione.

Di fatto, gli strumenti CAASM non possono funzionare senza i dati provenienti da strumenti di individuazione degli asset, ITAM, gestione delle vulnerabilità e/o gestione delle patch. Allo stesso modo, EASM integra i servizi di threat intelligence e security testing elencati sopra.

Come identificare la superficie di attacco fisica della mia organizzazione?

La prima componente principale della superficie di attacco fisica della tua organizzazione si sovrappone alla superficie di attacco digitale. Viene definita superficie di attacco degli endpoint ed è composta principalmente da tutti gli endpoint che si connettono alla rete: computer desktop, laptop, dispositivi mobili e dispositivi IoT. Gli strumenti e le tecniche che utilizzi per individuare la superficie di attacco digitale si applicano anche in questo caso.

La seconda componente principale della superficie di attacco fisica è costituita da uffici, data center e altre strutture. Anche in questo caso, le tecniche già utilizzate per identificare la superficie di attacco digitale si sovrappongono alla superficie di attacco fisica. Nello specifico, si tratta della componente di penetration testing fisico del red teaming.

Come identificare la superficie di attacco umana della mia organizzazione?

L’identificazione della superficie di attacco umana inizia dall’analisi dell’organigramma. Chiunque sia associato alla tua organizzazione e possa accedere a informazioni sensibili — o impedire ad altri di accedervi — contribuisce alla superficie di attacco umana. Questo include non solo i dipendenti a tempo pieno, ma anche quelli part-time, i membri del consiglio di amministrazione, i collaboratori esterni, i partner, i vendor, i fornitori, il personale temporaneo e altri soggetti.

Il red teaming, una pratica utilizzata per identificare elementi sia della superficie di attacco digitale sia di quella fisica, può essere usato anche per identificare una componente importante della superficie di attacco umana: la suscettibilità dei dipendenti al social engineering.

L’assegnazione impropria dei privilegi utente è un altro fattore importante che contribuisce alle superfici di attacco umane. Esaminare i sistemi e i dati a cui hanno accesso le persone che contribuiscono alla superficie di attacco umana, insieme ai livelli di accesso di cui dispongono, è un altro modo per identificarne alcune parti.

Ho identificato la superficie di attacco della mia organizzazione. E adesso?

Individuare la superficie di attacco è il primo passo verso l’obiettivo finale: correggere le vulnerabilità che comportano il rischio maggiore per la tua organizzazione. Nel suo complesso, questo processo è chiamato gestione dell’esposizione.

L’individuazione della superficie di attacco, come abbiamo già visto, è una delle basi della strategia di sicurezza: se non sai che esiste, non puoi proteggerla. La gestione dell’esposizione aggiunge un ulteriore pilastro fondamentale: determinare la tua propensione al rischio. Questo definisce quanto rischio la tua organizzazione è disposta ad assumersi nel perseguire i propri obiettivi. (Puoi utilizzare questo modello modificabile per la dichiarazione della tua propensione al rischio.)

Una volta affrontati questi due elementi fondamentali, puoi valutare le vulnerabilità individuate nella tua superficie di attacco per determinare quanto rischio comportano per la tua organizzazione e se rientrano nella tua propensione al rischio (un processo che approfondiamo in questa guida alla valutazione oggettiva del rischio cyber).

Le vulnerabilità che superano la tua propensione al rischio sono le priorità di correzione, consentendoti di concentrare gli sforzi dove hanno il maggiore impatto.

Che cosa significa davvero cybersecurity proattiva? Misure per proteggere la tua organizzazione

Mon, 04 Aug 2025 19:26:10 Z

Il report Ivanti 2025 State of Cybersecurity ha rilevato un dato tutt’altro che sorprendente: le organizzazioni segnalano un significativo divario di preparazione (ovvero la differenza tra il livello di minaccia percepito e il loro grado di preparazione) in tutti i vettori di minaccia e le vulnerabilità oggetto della nostra indagine.

Sebbene i team di sicurezza dedichino giustamente risorse alla creazione di resilienza per poter rispondere rapidamente agli attacchi e riprendersi da essi, colmare questi divari di preparazione richiede misure di cybersecurity proattiva.

Cybersecurity reattiva e proattiva: qual è la differenza?

La cybersecurity proattiva si riferisce a ciò che fai prima di un attacco informatico per migliorare la postura di sicurezza e ridurre la superficie di attacco; la cybersecurity reattiva interrompe un attacco che ha già violato i sistemi, contenendolo e riducendo al minimo i danni che potrebbe causare.

Questi due approcci non si escludono affatto a vicenda. La sicurezza proattiva riduce il rischio, ma non lo elimina. “Reattivo” può avere una connotazione leggermente negativa, ma le capacità che consentono di rispondere a un attacco, per quanto sia stata ridotta l’esposizione al rischio, sono di importanza vitale.

Esempi di misure di cybersecurity proattiva

La sicurezza proattiva è una filosofia, non un modello prestabilito. Si basa sull’idea che adottare misure per ridurre al minimo l’esposizione molto prima che un rischio si concretizzi sia il modo migliore di utilizzare tempo e risorse dedicati alla sicurezza.

Detto questo, esistono capacità specifiche che puoi sviluppare per adottare questa filosofia, tra cui, a titolo esemplificativo ma non esaustivo, scansione delle vulnerabilità, gestione della superficie di attacco, gestione delle vulnerabilità, validazione dell’esposizione, gestione delle patch, gestione della configurazione e formazione degli utenti.

Gestione della superficie di attacco

La gestione della superficie di attacco mira a comprendere tutti i punti di accesso di un’organizzazione, digitali, fisici o umani, che possono essere utilizzati dagli hacker per accedere al suo ambiente IT.

La superficie di attacco include i dispositivi (noti e sconosciuti), ma l’ambiente va oltre i dispositivi. Sono incluse anche applicazioni, software, account sui social media e altri spazi o asset digitali utilizzati da persone associate all’azienda.

Correlato:Checklist della superficie di attacco

Scansione delle vulnerabilità

La scansione delle vulnerabilità è esattamente ciò che suggerisce il nome: scanner specializzati valutano reti e asset IT alla ricerca di vulnerabilità che possono essere sfruttate, quindi le segnalano ai team di sicurezza affinché le affrontino. Poiché esistono migliaia di vulnerabilità note (e ogni giorno ne emergono di nuove), la scansione delle vulnerabilità è più efficace quando è automatizzata.

Le scansioni esterne delle vulnerabilità esaminano una rete dall’esterno verso l’interno, cercando di individuare i modi in cui un hacker potrebbe accedere alla rete. Le scansioni interne assumono il punto di vista di chi ha già violato la rete e delle vulnerabilità che potrebbe sfruttare dall’interno.

Gestione delle vulnerabilità

La scansione delle vulnerabilità e la gestione della superficie di attacco alimentano il ciclo più lungo e completo della gestione delle vulnerabilità. Si tratta di un processo continuo in cui le vulnerabilità vengono identificate e classificate in base a un determinato livello di priorità, prima che i team stabiliscano il modo migliore per risolverle.

Un approccio predefinito alla gestione delle vulnerabilità consiste nel dare priorità in base alla gravità, ma questo approccio può enfatizzare eccessivamente alcune vulnerabilità trascurandone altre. Integrare il contesto della minaccia – questa vulnerabilità viene sfruttata attivamente? – e il contesto del rischio – quanto sarebbe dannoso lo sfruttamento di questa vulnerabilità per la mia organizzazione? – permette di ottenere un quadro più chiaro della reale priorità.

Validazione dell’esposizione

La validazione dell’esposizione verifica la fattibilità di un attacco e la solidità delle contromisure eseguendo scenari di attacco. Questo approccio è chiamato anche offensive security. I due metodi più comuni sono il penetration testing e il red teaming.

Penetration testing (o pen testing) è l’attività in cui hacker etici tentano di violare il tuo sistema, quindi forniscono un feedback su ciò che ha funzionato bene e sulle aree che richiedono ulteriori miglioramenti. Il pen testing può essere eseguito anche con strumenti automatizzati.
Red teaming, analogamente al pen testing, prevede che hacker etici conducano un attacco informatico pianificato con l’obiettivo di scoprire dove le difese possono essere migliorate. Il red teaming è una simulazione basata su scenari, mentre il pen testing consiste nel cercare il maggior numero possibile di vulnerabilità diverse.

Anche l’adversarial exposure validation, o AEV, si sta affermando come pratica: utilizza software per eseguire simulazioni di attacco in modo continuo e autonomo, al fine di dimostrare l’esistenza di esposizioni.

Gestione delle patch

Una volta che le vulnerabilità sono state identificate tramite la gestione della superficie di attacco e la scansione delle vulnerabilità, prioritizzate tramite la gestione delle vulnerabilità e quindi validate tramite la validazione dell’esposizione, la domanda diventa: come devo reagire?La gestione delle patch è un modo per rispondere alle vulnerabilità e chiuderle, in particolare alle vulnerabilità software per le quali esistono patch.

La gestione delle patch è particolarmente adatta all’automazione, soprattutto se abbinata alla gestione delle vulnerabilità basata sul rischio. I workflow che passano automaticamente dal rilevamento al processo decisionale fino alla distribuzione riducono il tempo medio di remediation e minimizzano gli errori umani.

La gestione delle patch presenta però un importante punto cieco: lo shadow IT. Senza un inventario accurato del software utilizzato dai dipendenti, è impossibile applicare la conformità delle patch. Ecco perché la componente di discovery della gestione della superficie di attacco è così fondamentale.

Gestione della configurazione

La gestione della configurazione, come la gestione delle patch, è un modo per rispondere alle vulnerabilità identificate; in questo caso, vulnerabilità che riguardano i dispositivi stessi anziché il software eseguito su di essi. La configurazione si riferisce alle misure di cybersecurity proattiva impostate a livello di dispositivo, come l’applicazione dell’autenticazione a più fattori o della crittografia. Sebbene queste misure possano essere applicate singolarmente dall’utente finale, vengono applicate in modo più efficace utilizzando un software di gestione degli endpoint.

Ancora una volta, come per la gestione delle patch, lo shadow IT complica il quadro. I dispositivi sconosciuti e non gestiti potrebbero non essere conformi agli standard di sicurezza della tua organizzazione: non c’è modo di saperlo. E, proprio come per la gestione delle patch, la componente di discovery della gestione della superficie di attacco è fondamentale. Identificando dispositivi precedentemente sconosciuti e portandoli sotto gestione, i team IT possono applicare la conformità.

Formazione degli utenti

La superficie di attacco non è solo digitale: esiste anche una componente umana. Il phishing e altre forme di social engineering sfruttano le vulnerabilità umane, spesso concatenandole con esposizioni digitali (vulnerabilità software, configurazioni non corrette, ecc.) per lanciare un attacco. Formare i dipendenti aiuta a ridurre al minimo le esposizioni, proprio come avviene con la remediation delle vulnerabilità digitali.

Ottenere supporto per le misure di cybersecurity proattiva

Ottenere supporto per le misure di cybersecurity proattiva è, per certi versi, più difficile rispetto alle misure di cybersecurity reattiva. La minaccia non si è ancora concretizzata, quindi per gli stakeholder non appartenenti alla sicurezza è più difficile comprendere i compromessi necessari, come interruzioni temporanee delle attività aziendali o altri elementi che ostacolano la produttività, almeno nel breve termine. La formazione degli utenti sottrae tempo ad agende già fitte. La distribuzione delle patch può portare le applicazioni offline o richiedere attività di troubleshooting.

Per ottenere e mantenere il supporto a questo tipo di misure, i team di sicurezza dovrebbero prestare attenzione a ridurre al minimo le interruzioni che la remediation può causare (ad esempio, utilizzando la distribuzione ad anelli, che implementa gli aggiornamenti software in “anelli” progressivamente più ampi, identificando i problemi ed eseguendo il troubleshooting in ogni fase prima di estenderli all’intera base utenti).

Anche un esercizio di valutazione del rischio può essere utile per rendere concreta, agli occhi degli altri stakeholder, una minaccia che non si è ancora materializzata. Una misura oggettiva della tua esposizione e del costo dei rischi associati, in particolare se sei in grado di quantificare tale esposizione in termini finanziari, può fare la differenza tra un’accettazione riluttante e un autentico supporto alla sicurezza proattiva.

Correlato:Valutare il rischio informatico in modo oggettivo: una guida alle valutazioni del rischio basate sui dati

Perché la cybersecurity proattiva è importante

Una strategia di cybersecurity proattiva non è in contrapposizione con la sicurezza reattiva: un’organizzazione sana dispone di capacità solide per affrontare il rischio prima e dopo che si concretizzi. Ma le azioni preventive migliorano la postura di rischio e rendono meno frequenti le occasioni in cui un rischio si concretizza. Misure di cybersecurity proattiva come la gestione della superficie di attacco, l’applicazione delle patch, configurazioni efficaci e la consapevolezza degli utenti sono investimenti chiari nella sicurezza a lungo termine della tua organizzazione.

Perché non potete permettervi di ignorare gli attacchi alla supply chain del software

Mon, 05 May 2025 12:34:43 Z

Il report Ivanti 2025 State of Cybersecurity ha rivelato che solo 1 organizzazione su 3 si sente pronta a proteggersi dalle minacce alla supply chain del software. Poiché gli autori degli attacchi prendono sempre più di mira le dipendenze di terze parti, gli attacchi alla supply chain possono diventare un doloroso tallone d'Achille per la cybersecurity se le organizzazioni continueranno a sottovalutarli.

Il rischio crescente degli attacchi alla supply chain del software

Le superfici di attacco si stanno ampliando rapidamente e le supply chain del software delle organizzazioni sono uno dei principali vettori di questa espansione. Le imprese moderne si affidano a numerose applicazioni software, strumenti e dipendenze all'interno della propria infrastruttura tecnologica. Secondo un report 2024 di BetterCloud, una singola organizzazione utilizza in media 112 applicazioni SaaS. E questa rete diventa sempre più complessa. In media, ogni applicazione software ha 150 dipendenze — il 90% delle quali sono dipendenze indirette — responsabili della grande maggioranza delle vulnerabilità.

Il numero di autori delle minacce che prendono di mira le dipendenze di terze parti è aumentato rapidamente negli ultimi anni, con il 75% di tutte le supply chain del software che ha segnalato attacchi nel 2024. Anche le minacce alla supply chain del software sono diventate più sofisticate, poiché gli autori degli attacchi cercano qualsiasi debolezza da sfruttare nel codice di un fornitore. Tuttavia, i team di sicurezza spesso faticano a verificare correttamente tutti i componenti software.

La ricerca sulla cybersecurity di Ivanti ha rilevato che, sebbene l'84% dei leader aziendali dichiari che monitorare la supply chain del software sia “molto importante”, quasi la metà (48%) non ha ancora identificato i componenti più vulnerabili della propria supply chain. Questa mancanza di due diligence espone le aziende a notevoli rischi finanziari e reputazionali.

Tipi comuni di attacchi alla supply chain del software

Secondo Gartner, entro il 2025 il 45% delle organizzazioni avrà subito un attacco alla supply chain del software. Ecco una breve panoramica di alcune delle tipologie più comuni di vulnerabilità della supply chain del software prese di mira dagli autori degli attacchi:

Gli attacchi ai server upstream sono gli attacchi alla supply chain più comuni. Si verificano quando gli hacker compromettono un sistema posizionato “upstream” rispetto agli utenti, ad esempio un repository di codice, e iniettano un payload dannoso / malware. Questo payload si diffonde poi agli utenti “downstream” tramite elementi come un aggiornamento software.
Gli attacchi midstream indicano incidenti in cui gli autori degli attacchi compromettono sistemi intermedi, come strumenti di sviluppo software, anziché la codebase originale.
Gli attacchi di dependency confusion tentano di indurre uno sviluppatore o un sistema a scaricare una dipendenza software compromessa da una fonte esterna. Tra i metodi di attacco comuni vi è l'uso, per il caricamento di software dannoso, di un nome simile a quello di una libreria interna attendibile. La versione dannosa viene spesso integrata nella build del software al posto della dipendenza legittima.
Gli attacchi ai certificati di firma del codice si verificano quando gli hacker iniettano software dannoso nei certificati digitali di firma del codice destinati a verificare la sicurezza e l'autenticità del software. Questi attacchi avvengono quando gli autori delle minacce compromettono l'ambiente di sviluppo tramite social engineering o un'altra tattica.
Gli attacchi all'infrastruttura CI/CD prendono di mira le pipeline di sviluppo automatizzate introducendo malware, ad esempio clonando repository GitHub autentici per finalità dannose.

Esempi recenti di attacchi alla supply chain

Non serve cercare a lungo nelle notizie per trovare esempi reali di questi tipi di attacchi arrivati a un punto critico. Ecco alcuni incidenti di attacchi alla supply chain degli ultimi anni che hanno attirato l'attenzione globale.

Attacco di social engineering a Okta
- Nell'ottobre 2023, Okta, fornitore di servizi di gestione delle identità e degli accessi, ha subito una grave violazione dei dati del proprio sistema di assistenza clienti dopo che quattro diversi clienti Okta sono stati vittime di attacchi di social engineering rivolti al loro service desk IT. Gli autori degli attacchi hanno utilizzato queste credenziali amministrative per lanciare molteplici attacchi downstream, causando accessi non autorizzati ai dati di migliaia di clienti Okta, tra cui 1Password, BeyondTrust e Cloudflare.
Attacco ransomware a Kaseya
- In questo caso del luglio 2021, gli hacker hanno sfruttato sei vulnerabilità zero-day nello strumento di gestione remota di Kaseya e hanno utilizzato queste vulnerabilità per distribuire un payload ransomware dannoso tramite un aggiornamento software che ha infettato centinaia di managed service provider (MSP) e i loro clienti. L'attacco ha bloccato le attività di quasi 2.000 aziende in tutto il mondo ed è finito sui titoli dei giornali quando gli autori degli attacchi hanno richiesto l'enorme riscatto di 70 milioni di dollari (che alla fine non è stato pagato).
Attacco CI/CD a Codecov
- Nel gennaio 2021, attori malevoli si sono infiltrati nel popolare strumento di test del codice Codecov, che all'epoca era utilizzato da oltre 29.000 clienti. Gli autori degli attacchi hanno ottenuto accesso non autorizzato allo script Bash Uploader di Codecov e hanno introdotto codice dannoso, poi utilizzato dai clienti Codecov nelle loro pipeline CI/CD. Codecov non ha rilevato né segnalato l'attacco fino ad aprile 2021: ciò significa che questi attori malevoli potrebbero aver avuto accesso per mesi a dati sensibili in migliaia di sistemi dei clienti.
- Ognuna di queste violazioni della supply chain ha causato danni a cascata e di ampia portata sia al provider sfruttato, sia alle sue migliaia di clienti e oltre.

Impatti gravi degli attacchi alla supply chain

La portata dei danni derivanti dagli attacchi alla supply chain del software non può essere sottovalutata. Ognuno degli attacchi citati ha provocato danni finanziari e reputazionali significativi e ha spinto molte organizzazioni a riconsiderare il proprio approccio alla sicurezza dei fornitori.

Impatti finanziari

Cybersecurity Ventures prevede che il costo annuo globale degli attacchi alla supply chain del software per le aziende raggiungerà l'impressionante cifra di 138 miliardi di dollari entro il 2031, rispetto ai 60 miliardi del 2025. Queste perdite includono tutto: mancati ricavi, costi di remediation, spese legali e potenziali sanzioni per non conformità. In seguito alla violazione dei dati del 2023, le azioni Okta sono scese dell'11%. Dopo un'altra importante violazione dei dati nel 2022, Okta è stata poi colpita da una causa intentata dagli azionisti interessati ed è stata tenuta a pagare 60 milioni di dollari.

Impatti operativi

Gli attacchi alla supply chain possono causare interruzioni e arresti dei sistemi per migliaia di clienti, bloccando operazioni critiche e provocando ritardi che incidono ulteriormente su altri fornitori. Consideriamo solo alcune delle istituzioni colpite dalla violazione di Kaseya. In Svezia, un grande rivenditore alimentare è stato costretto a chiudere 800 negozi durante il fine settimana, e anche le ferrovie statali hanno subito interruzioni. Undici scuole e oltre 100 asili in Nuova Zelanda hanno inoltre dovuto interrompere tutte le attività online, ricorrendo a carta e penna fino alla risoluzione dell'incidente.

Danno reputazionale

Una reputazione compromessa pubblicamente può far arretrare un'azienda in termini di fiducia da parte di clienti e azionisti. Le imprese possono perdere fornitori e una fidelizzazione dei clienti costruita in anni. Nel marzo 2023, il popolare software di comunicazione aziendale 3CX è stato compromesso quando gli hacker hanno iniettato codice dannoso nella sua applicazione, esponendo potenzialmente i dati sensibili di oltre 600.000 clienti e causando all'azienda mesi di attenzione mediatica negativa e reazioni pubbliche critiche.

Dove si ferma la responsabilità? Debito tecnico e responsabilità condivisa

Con minacce alla supply chain del software destinate ad aumentare in frequenza e gravità, per le imprese è indispensabile definire responsabilità chiare e attenersi a rigorose best practice di sicurezza per i fornitori terzi e per la cybersecurity della supply chain del software.

A chi spetta la sicurezza del software?

Attualmente, molte organizzazioni non dispongono di processi rigorosi e standardizzati per valutare la sicurezza dei fornitori terzi. Inoltre, molti clienti e fornitori non sono nemmeno allineati su chi sia responsabile della gestione della sicurezza del software di terze parti.

Il Report State of Cybersecurity Trends ha analizzato organizzazioni con diversi livelli di capacità di cybersecurity per sviluppare la nostra Cybersecurity Maturity Scale. Questa scala va dalle organizzazioni meno mature (livelli 1 e 2) a quelle con capacità di cybersecurity più avanzate (livello 4).

Attraverso questa ricerca abbiamo rilevato che le organizzazioni meno mature ritenevano più spesso che la cybersecurity fosse esclusivamente responsabilità del fornitore. Al contrario, quelle con i livelli più elevati di preparazione in materia di cybersecurity sostenevano una responsabilità condivisa tra fornitore del software e cliente.

Come proteggersi dalle minacce alla supply chain del software

La sicurezza della supply chain del software è una parte essenziale di una strategia di cybersecurity completa e proattiva.

Rafforzare la supply chain del software e difendersi da potenziali attacchi richiede alle organizzazioni di trattare tutti i fornitori e i componenti di terze parti come un'estensione dell'intera superficie di attacco. Ecco le nostre principali raccomandazioni per aiutare le organizzazioni a prepararsi meglio a prevenire gli attacchi alla supply chain, oltre che a rilevare e rispondere a eventuali minacce alla supply chain.

1. Gestione rigorosa dei fornitori e valutazione del rischio

Eseguite la due diligence prima di collaborare con fornitori di software. Cercate fornitori conformi agli standard di settore e dotati di una policy di divulgazione delle vulnerabilità pubblicata. Audit periodici, revisioni del codice e valutazioni proattive da parte sia del fornitore sia del cliente sono fondamentali per mitigare i rischi.

La nostra ricerca mostra che le organizzazioni con i livelli più avanzati di cybersecurity sono più propense a eseguire la due diligence nella valutazione della cybersecurity dei fornitori terzi, ad esempio:

Integrare questionari di valutazione della sicurezza (SAQ) nella valutazione.
Prendere in considerazione le certificazioni di sicurezza dei fornitori, come ISO 27001 e SOC 2.
Esaminare gli standard di conformità specifici del settore.
Assicurarsi che i fornitori dispongano di piani e processi di risposta agli incidenti per gestire potenziali violazioni della sicurezza.
Richiedere una Software Bill of Materials (SBOM) per comprendere i componenti open source e di terze parti utilizzati nel loro software.

2. Monitoraggio continuo e remediation proattiva su tutte le dipendenze

È fondamentale utilizzare strumenti e processi automatizzati di rilevamento delle minacce per monitorare e valutare tutti i componenti software. Le dipendenze, in particolare nei componenti software open source, vengono spesso trascurate e rappresentano un importante rischio di vulnerabilità se non vengono monitorate e aggiornate regolarmente.

Gli strumenti di AI e automazione possono fornire insight in tempo reale sulle prestazioni di dispositivi, applicazioni e reti per rilevare potenziali problemi. Le soluzioni di self-healing e remediation automatizzata offrono modalità efficaci per risolvere i problemi con un intervento umano minimo o nullo.

3. Comunicazione regolare con i fornitori terzi

Un elemento fondamentale per stabilire una responsabilità reciproca nella sicurezza della supply chain del software è una comunicazione frequente e aperta tra clienti e fornitori terzi. I team di sicurezza e IT devono rimanere informati su eventuali aggiornamenti software, patch per correggere vulnerabilità note e minacce alla sicurezza emergenti.

Scoprite di più sulla sicurezza della supply chain del software

Volete saperne di più? Leggete il Report State of Cybersecurity Trends completo per ottenere insight approfonditi sulle minacce di cybersecurity più urgenti di oggi e sulle strategie per una gestione proattiva del rischio.

Come trasformare la valutazione quantitativa del rischio in azione

Tue, 15 Apr 2025 13:50:58 Z

Riepilogo
La valutazione quantitativa del rischio traduce il rischio di cybersecurity in termini finanziari.
È possibile usare l’output di una valutazione quantitativa del rischio per decidere la risposta al rischio: evitarlo, accettarlo, trasferirlo o mitigarlo.
Un framework di propensione al rischio consente di gestire casi sfumati o ambigui in cui la risposta al rischio appropriata non è chiara.
Nel complesso, questi processi aiutano le organizzazioni a trovare un equilibrio tra esigenze di sicurezza e obiettivi aziendali.

La valutazione quantitativa del rischio offre un approccio oggettivo all’analisi del rischio, ma comprenderlo è solo il primo passo. Questo articolo spiega come interpretare i risultati e trasformare queste informazioni in decisioni significative in un contesto reale.

(Sebbene questo articolo non spieghi come eseguire un’analisi quantitativa del rischio, potete approfondire il processo nella nostra Guida alla valutazione del rischio basata sui dati.)

Comprendere la quantificazione del rischio

Partiamo dalle basi: che cos’è, esattamente, la valutazione quantitativa del rischio?

Che cos’è la quantificazione del rischio?

La valutazione quantitativa del rischio (talvolta abbreviata in QRA) assegna un valore monetario a un rischio di cybersecurity in base al suo potenziale impatto e alla sua probabilità. Si pone la domanda: Se questo asset viene esposto attraverso questa vulnerabilità, quanto ci costerà? A differenza dei metodi qualitativi, che classificano i rischi in categorie di gravità, un approccio quantitativo offre un quadro più oggettivo.

Perché è importante? Le valutazioni qualitative del rischio di cybersecurity lasciano molto più spazio all’interpretazione. Tradurre il rischio nel linguaggio del business, cioè in termini economici, elimina gran parte di questa ambiguità e aiuta i leader non specializzati in sicurezza a comprendere che cosa significhi davvero un rischio “alto” nel contesto specifico.

Come si inserisce la quantificazione del rischio nella strategia di cybersecurity più ampia?

Quantificare il rischio è uno strumento essenziale per gestire l’esposizione, ma non è l’obiettivo finale. Costituisce invece la base per prendere decisioni di mitigazione del rischio.

Ad esempio, quando potete presentare l’esposizione al rischio come “1,5 milioni di dollari in potenziali danni dovuti a un fornitore che utilizza comunicazioni cloud non crittografate”, diventa più facile valutare le opzioni per rispondere a quel rischio, che esamineremo più nel dettaglio più avanti in questo articolo.

Interpretare l’analisi quantitativa del rischio: elementi chiave

Ci sono alcuni elementi chiave di un’analisi quantitativa del rischio che è importante comprendere per interpretarne i risultati.

Valore dell’asset (AV): Il valore dell’asset protetto per la vostra organizzazione.
Fattore di esposizione (EF): La percentuale del valore dell’asset che potrebbe andare persa o essere compromessa se il rischio si materializza.
Tasso annuo di occorrenza (ARO): La frequenza con cui si prevede che quel rischio si materializzi ogni anno. (Può essere inferiore a 1 per i rischi che si materializzano meno di una volta all’anno.)

Queste tre cifre consentono di calcolare:

Perdita singola attesa (SLE): Il valore finanziario che andrebbe perso in un singolo evento di minaccia se il rischio si materializza. Questo valore si calcola usando la formula AV x EF.
Perdita annua attesa (ALE): Il valore finanziario che andrebbe perso ogni anno se il rischio si materializza. Questo valore si calcola usando la formula SLE x ARO.
ALE residua: Il valore finanziario che andrebbe perso ogni anno se il rischio si materializza dopo l’applicazione delle mitigazioni. Le mitigazioni riducono l’EF, l’ARO o entrambi, ma per il resto i calcoli rimangono invariati.

L’ALE è il principale output dell’analisi del rischio ed è la cifra più importante da usare per valutare le opzioni di risposta al rischio. Ma non è un numero perfetto: per questo c’è un altro elemento chiave, l’incertezza.

AV, EF e ARO sono tutte stime. Idealmente sono stime molto accurate, basate su ricerche approfondite, ma restano comunque stime. Il livello di fiducia che dovreste avere in tali stime è solitamente rappresentato da un livello di confidenza (ad esempio 80%), seguito da un elenco di incognite.

Dal rischio all’azione: la risposta al rischio

Finora abbiamo visto come interpretare una valutazione quantitativa del rischio. Ma lo scopo ultimo dell’analisi del rischio è decidere cosa fare rispetto a quel rischio.

Tutte le risposte al rischio rientrano, in linea generale, in una di quattro categorie: evitare, accettare, trasferire o mitigare.

Evitare

Evitare il rischio significa eliminare completamente l’esposizione. È l’unica risposta al rischio che lo riduce effettivamente a zero. In termini pratici, significa chiudere un processo o un sistema che comporta rischio.

L’eliminazione del rischio è sostanzialmente un’opzione estrema, raramente praticabile. Ad esempio, potete ridurre a zero il rischio di phishing interrompendo tutti gli scambi di email con l’esterno. Se operate in ambiti di sicurezza nazionale, potrebbe effettivamente valerne la pena. Per tutti gli altri, questo bloccherebbe bruscamente le attività aziendali.

L’analisi del rischio potrebbe supportare questa risposta in due situazioni: se l’ALE è così estrema che nessuna strategia di mitigazione può ridurla a un livello accettabile, oppure se esiste un’alternativa 1:1 al processo o al sistema che comporta rischio e che ridurrebbe l’EF o l’ARO a zero.

Accettare

Accettare il rischio significa scegliere di non fare nulla. Anche se a prima vista può sembrare irragionevole, è un’opzione che merita seria considerazione.

Esiste uno scenario molto semplice in cui accettare il rischio è l’opzione migliore: quando il costo della mitigazione supera l’ALE residua (cioè l’ALE dopo la mitigazione). In questa situazione, proteggere l’organizzazione costa più di quanto essa rischia di perdere.

Ma esistono anche situazioni più sfumate in cui l’accettazione ha senso. Queste tengono conto del costo opportunità della mitigazione di un rischio, sia che riguardi in modo circoscritto il team di sicurezza, sia che rappresenti un costo opportunità per l’azienda nel suo complesso.

Nessun team di sicurezza dispone di risorse illimitate. L’accettazione è un’opzione ragionevole (anche se scomoda) se scegliere di mitigare questo rischio significa sottrarre risorse alla gestione di un’esposizione più preoccupante. Soprattutto quando la strategia di mitigazione è molto manuale e richiederebbe molte ore di lavoro del personale per essere implementata, a quali altre attività si rinuncia per dedicare tempo a questo intervento?

C’è anche un costo opportunità più ampio da considerare: quali opportunità l’azienda dovrebbe rinunciare per mitigare o evitare il rischio. In altre parole, l’accettazione può avere senso quando l’opportunità di business è superiore all’ALE. Potrebbe essere il caso, ad esempio, dell’apertura di un data center in un Paese estero per fornire servizi cloud a un nuovo mercato. Pur esponendovi a nuovi rischi di sicurezza, esiste un chiaro vantaggio per il business.

Trasferire

Trasferire il rischio significa spostarne l’onere su un’altra parte, di solito un’assicurazione per la cybersecurity. In generale, trasferire il rischio a un’assicurazione è un’opzione quando il costo dell’assicurazione è inferiore alla vostra ALE, ma ci sono alcune avvertenze.

Innanzitutto, l’assicurazione copre solo il costo finanziario di un incidente di sicurezza. Agli incidenti di sicurezza sono associati anche danni legali e reputazionali. Se la vostra ALE ha tenuto conto di questi danni e ha assegnato loro un valore monetario (cosa che idealmente dovrebbe aver fatto), dovrete scomporre quella cifra per considerare solo i costi finanziari immediati. Trasferire il rischio ha senso quando il rischio finanziario è elevato, ma i rischi legali e reputazionali sono bassi.

In secondo luogo, l’assicurazione richiederà quasi certamente la presenza di alcuni controlli di sicurezza e potrebbe anche interrompere la copertura per incidenti ricorrenti. Ciò significa che dovrete aggiungere il costo di tali controlli al costo dell’assicurazione, con la possibilità di modificare il vostro calcolo. Significa anche che trasferire il rischio a un’assicurazione può essere solo una misura temporanea per un rischio con un ARO elevato.

Mitigare

La mitigazione è la risposta più proattiva: consente di ridurre l’esposizione applicando controlli di sicurezza, correggendo vulnerabilità, risolvendo configurazioni errate e così via.

La mitigazione non eliminerà l’esposizione: l’unico modo per farlo è evitare del tutto il rischio. La mitigazione, invece, riduce il rischio attraverso interventi che abbassano l’EF, l’ARO o entrambi. È quindi possibile calcolare una nuova ALE, nota come ALE residua.

In generale, la mitigazione è una buona opzione quando la differenza tra l’ALE originale e l’ALE residua è superiore al costo della mitigazione.

Integrare la propensione al rischio (o come gestire i casi limite)

Non tutte le valutazioni del rischio offrono una scelta di risposta netta. Ci saranno sempre casi in cui i margini tra due opzioni sono ridotti o il livello di incertezza è elevato. Integrare la propensione al rischio vi aiuterà a interpretare questi casi limite. La propensione al rischio di solito non fa parte di un’analisi del rischio, ma è una prospettiva utile attraverso cui interpretarla.

(Se la vostra organizzazione non ha già documentato la propria propensione al rischio, potete usare questo modello di dichiarazione della propensione al rischio modificabile come punto di partenza.)

La propensione al rischio è il livello di rischio che un’organizzazione è disposta ad accettare nel perseguire i propri obiettivi. Una propensione al rischio elevata significa essere aperti ad accettare rischi maggiori in cambio di possibili ricompense più elevate, mentre una bassa propensione al rischio significa preferire ridurre il rischio il più possibile. La propensione al rischio esiste su più dimensioni: potreste avere un’elevata propensione al rischio operativo ma una bassa propensione al rischio di conformità.

All’interno di ciascuna di queste dimensioni (rischio di sicurezza, rischio di conformità, rischio di innovazione e così via), ci sono diversi fattori chiave da considerare:

Capacità di rischio è la quantità massima di rischio che un’organizzazione può sostenere, generalmente determinata da risorse finanziarie, capacità operative e vincoli normativi.
Tolleranza al rischio è una deviazione accettabile rispetto all’obiettivo.
Soglie di rischio sono “linee rosse” che indicano la necessità di un cambio di strategia.

La soglia tra tolleranza e capacità, o persino tra diversi gradi di tolleranza, può aiutarvi a orientarvi nelle aree grigie, in cui non è chiaro quale sia la risposta al rischio appropriata.

Trasformare gli insight in azione

Comprendere una valutazione quantitativa del rischio è solo il primo passo: il vero valore nasce dall’uso di questi insight per passare all’azione. Che si tratti di evitare, accettare, trasferire o mitigare il rischio, l’obiettivo è lo stesso: bilanciare i rischi di sicurezza con le priorità aziendali, così da poter agire con decisione.

FAQ
Che cos’è la valutazione quantitativa del rischio?La valutazione quantitativa del rischio, talvolta abbreviata in QRA, è un processo formale per assegnare un valore finanziario a un rischio di cybersecurity, in base al suo potenziale impatto e alla probabilità che si verifichi.
Che cos’è la perdita annua attesa? La perdita annua attesa è il principale output di una valutazione quantitativa del rischio. È il valore finanziario che andrebbe perso ogni anno se questo rischio si materializzasse. Si calcola usando la formula Perdita singola attesa (SLE) x Tasso annuo di occorrenza (ARO), dove la perdita singola attesa è Valore dell’asset (AV) x Fattore di esposizione (EF).
Che cos’è la propensione al rischio?La propensione al rischio è il livello di rischio che un’organizzazione è disposta ad accettare nel perseguire i propri obiettivi. Influenza le decisioni di risposta al rischio fornendo un framework per valutare i compromessi tra rischi di sicurezza e priorità aziendali.

Come i responsabili IT possono valutare le dichiarazioni sul software secure by design

Mon, 24 Feb 2025 16:47:03 Z

Ripubblicato con l’autorizzazione di CIO.com

Non è un segreto che le minacce informatiche siano in aumento. Il costo della criminalità informatica denunciata negli Stati Uniti è aumentato del 22% nel corso del 2023, superando i 12,5 miliardi di dollari, secondo l’Internet Crime Complaint Center dell’FBI. Un problema è rappresentato dalle vulnerabilità rimaste nel software a causa degli approcci tradizionali alla codifica e alla sicurezza. Per contrastare questi rischi, è ora in corso uno sforzo coordinato per creare software che sia secure by design. Ad esempio, la Cybersecurity and Infrastructure Security Agency (CISA) degli Stati Uniti ha delineato una serie di azioni che i fornitori possono intraprendere per dimostrare che stanno adottando i principi secure by design.

Ma senza standard e metriche applicabili, per i responsabili IT e della sicurezza è difficile valutare se e in che modo i fornitori stiano attuando questo approccio secure by design. Ecco alcuni passaggi che è possibile seguire.

Integrare le pratiche secure by design nelle valutazioni del rischio di sicurezza

La valutazione del rischio dei fornitori è un processo standard mediante il quale le aziende identificano e valutano i potenziali rischi associati ai prodotti e alle attività di un fornitore. I responsabili IT e della sicurezza possono utilizzare questo processo per concentrarsi sui principi e sulle pratiche secure by design, afferma Michael Riemer, Field Chief Information Security Officer di Ivanti.

“Per noi, in qualità di fornitore di software, significa assumerci la piena responsabilità dei nostri prodotti”, afferma Riemer. “Si esamina l’intera architettura della soluzione e si considera la sicurezza in tutte le aree, come progettazione dell’architettura, storage, connettività, utilizzo e così via.”

Nell’ambito della valutazione del rischio di sicurezza, le aziende dovrebbero anche valutare la possibilità di richiedere un report SOC 2 Type 2. Questo tipo di valutazione offre maggiori garanzie su come un fornitore protegge i dati e le informazioni dei clienti. Prevede un audit di cybersecurity condotto da terze parti, che valuta il funzionamento dei controlli e delle pratiche di sicurezza interne del fornitore per un periodo di tempo prolungato.

Ecco alcune domande chiave a cui ogni fornitore dovrebbe saper rispondere:

Con quale frequenza eseguite i penetration test?
Quali tipi di penetration test vengono eseguiti?
Eseguite sia l’analisi statica sia l’analisi dinamica del codice?

Valutare le pratiche di codifica

Le pratiche di codifica tradizionali sono sequenziali: un team lavora su un modulo, quindi lo passa al team successivo e così via. Ma questo mantiene le vulnerabilità introdotte nella base di codice, afferma Riemer. Riorganizzando i team in “pod” o gruppi, ciascuno con un security architect dedicato, le vulnerabilità possono essere eliminate fin dall’inizio. È stato un cambiamento importante per Ivanti, afferma Riemer. I fornitori dovrebbero essere in grado di dimostrare questi cambiamenti organizzativi e le nuove pratiche.

Valutare la trasparenza dell’approccio secure by design

I fornitori dovrebbero essere in grado di rendere pubblici i propri obiettivi secure by design e dimostrare che comunicano, o comunicheranno, le metriche su base regolare. I clienti dovrebbero anche poter monitorare i progressi del fornitore attraverso i suoi moduli software.

“Abbiamo definito obiettivi specifici e stabilito una baseline e delle metriche”, afferma Riemer. “Ci assumiamo la responsabilità dei nostri progressi secure by design. Queste metriche mostreranno quali moduli software abbiamo analizzato e quanto le analisi siano andate in profondità nell’identificare e correggere pratiche di codifica deboli.”

In sintesi

I leader aziendali e IT possono utilizzare i principi secure by design per valutare i progressi compiuti dai propri fornitori di software nella creazione di codice intrinsecamente più sicuro. L’approccio secure by design consente a questi leader di ridurre al minimo i rischi aziendali.

Come CIO e CISO possono collaborare per migliorare la produttività della forza lavoro e la sicurezza

Mon, 24 Feb 2025 16:46:54 Z

Ripubblicato con l’autorizzazione di CIO.com

Molte organizzazioni faticano ancora ad adattarsi ai requisiti del lavoro flessibile, mantenendo al contempo la cybersecurity aziendale. Un motivo chiave è che i CIO e i Chief Information Security Officer (CISO) non sono sempre allineati su come abilitare un lavoro produttivo e sicuro.

I requisiti del lavoro flessibile comportano cambiamenti sia per i team ITOps sia per i team SecOps. Nella pratica, però, i team IT e sicurezza spesso lavorano separatamente, senza condividere conoscenze, dati, obiettivi, priorità e pratiche. Di conseguenza, entrambi i team possono concentrarsi sulle rispettive priorità, il che significa anche che i dati relativi alla produttività dei lavoratori della conoscenza e alla sicurezza restano intrappolati in silos.

“I clienti ci dicono che, per chi opera nell’IT ops e nella security ops, l’allineamento esiste in teoria, ma spesso solo a livello C-level”, afferma Corinna Fulton, VP of Solutions Marketing, Ivanti. “Non si traduce nelle rispettive organizzazioni in termini di modelli di leadership, processi e così via. E spesso il CIO e il CISO potrebbero persino non vedere questo divario”.

Questo mancato allineamento a livello senior sta creando una disconnessione in termini di esperienza dei dipendenti. Il report Everywhere Work 2024 di Ivanti ha rilevato che il 40% dei lavoratori d’ufficio e il 49% dei professionisti IT prenderebbe in considerazione l’idea di cambiare lavoro per ottenere maggiore flessibilità, dimostrando quanto sia importante, soprattutto per i lavoratori più giovani. Inoltre, solo il 57% dei lavoratori d’ufficio afferma che potrebbe accedere facilmente agli stessi strumenti se dovesse lavorare da remoto già domani, sebbene oltre il 90% dei leader intervistati ritenga che i propri dipendenti da remoto dispongano di tutto il necessario per essere produttivi. I leader IT e della sicurezza hanno chiaramente ancora molto lavoro da fare per soddisfare le aspettative di dipendenti e business leader in materia di lavoro flessibile.

In caso contrario, il protrarsi del mancato allineamento è una ricetta per frustrazione, debolezze di sicurezza e produttività non ottimale. “In definitiva, si finisce per incidere sui ricavi”, afferma Fulton. “Sia il CIO sia il CISO vogliono evitarlo”.

Come CIO e CISO possono costruire una partnership efficace

Per integrare gli sforzi IT e di sicurezza e abilitare un lavoro flessibile sicuro e produttivo, questi leader possono iniziare con sei azioni:

Definire con precisione i rischi reali associati al lavoro flessibile. Alla luce della propensione al rischio dell’organizzazione, CIO e CISO dovrebbero chiarire il livello di rischio accettabile, come ridurlo al minimo e quali processi di mitigazione possono essere stabiliti congiuntamente. Questo accordo è la base per allineare obiettivi e priorità di IT e sicurezza, afferma Fulton.
Stabilire un insieme comune di standard e metriche concreti. Può essere utilizzato per valutare i rischi del lavoro flessibile. Un esempio di base è il “tempo di risoluzione”, dal momento in cui un rischio viene identificato (dal team SecOps) a quando viene completamente risolto (dal team ITOps). La condivisione porta a una risposta coordinata ed efficace.
Fare l’inventario dell’infrastruttura per il lavoro flessibile.La gestione degli asset IT è passata da semplice inventario a fattore abilitante per produttività e sicurezza, afferma Fulton. Sapere di cosa si dispone significa poter individuare potenziali vulnerabilità e intervenire per correggerle.
Sbloccare i silos di dati. La visibilità sulle principali fonti di dati è fondamentale per offrire ai team IT e sicurezza accesso e comprensione di un set comune di dati rilevanti per la produttività e la sicurezza dei dipendenti. Avviare un programma graduale per accedere a questi dati tanto necessari, oggi isolati in silos.
Creare una roadmap congiunta IT-sicurezza. Stabilire come e quando verranno implementati obiettivi e priorità comuni. Comunicare quindi questa roadmap a entrambi i team per guidarne la comprensione e assicurarsi che tutti lavorino verso gli stessi obiettivi.
Considerare l’impatto sul personale. Tenere conto dell’effetto che le policy IT e di sicurezza avranno sui lavoratori della conoscenza. Coordinarle con le esigenze e le preferenze degli utenti finali è fondamentale per ottimizzare la produttività dei dipendenti e la sicurezza aziendale.

In sintesi

CIO e CISO possono adottare misure concrete per superare gli ostacoli a un lavoro produttivo e sicuro, stabilendo una strategia e una struttura comuni che consentano alle loro organizzazioni di collaborare.

Comprendere la propensione al rischio: un componente critico della gestione dell’esposizione

Mon, 10 Feb 2025 14:44:03 Z

Il rischio è intrinseco a qualsiasi azienda. A fare la differenza è il modo in cui un’organizzazione lo comprende e lo gestisce.

Dalle sfide operative alla volatilità del mercato, dai cambiamenti normativi ai progressi tecnologici, le aziende devono affrontare un ampio spettro di incertezze che possono generare crescita o causare perdite.

Per gestirle in modo efficace, un’azienda deve definire un framework che la aiuti a stabilire quanto rischio è disposta ad accettare per perseguire i propri obiettivi. È qui che entra in gioco il concetto di “propensione al rischio”.

Ma per definire la propria propensione al rischio, un’azienda deve vedere e comprendere tutti i rischi che deve affrontare. E per i team di sicurezza che stanno gettando le basi della loro strategia di gestione dell’esposizione, definire la propensione al rischio della propria organizzazione è un passaggio critico.

Che cos’è la propensione al rischio?

La propensione al rischio è il livello di rischio che un’organizzazione è disposta ad accettare per perseguire i propri obiettivi. Definirla stabilisce i confini dell’organizzazione rispetto a quali rischi assumerà e in quale misura. Una propensione al rischio elevata significa essere aperti ad accettare rischi maggiori in vista di possibili ricompense più alte, mentre una propensione al rischio bassa significa che l’organizzazione preferisce ridurre il rischio il più possibile.

Si consideri una startup tecnologica che vuole investire in ricerca e sviluppo all’avanguardia. Potrebbe adottare una propensione al rischio più elevata per ottenere innovazioni dirompenti e rivoluzionarie, sapendo che i potenziali vantaggi valgono l’incertezza. Al contrario, una grande azienda consolidata potrebbe avere una propensione al rischio più bassa, puntando su una crescita stabile ed evitando progetti che potrebbero danneggiare in modo significativo la sua posizione di mercato o la sua reputazione.

La propensione al rischio è sia quantitativa sia qualitativa

La propensione al rischio non è mai statica: è una misura dinamica che dovrebbe essere adeguata in base a fattori quali settore, dimensioni e stato di salute dell’azienda, obiettivi strategici, requisiti normativi e contesto generale del mercato.

Né riguarda solo i numeri: la propensione al rischio è una combinazione di fattori sia quantitativi sia qualitativi.

Da un lato, un’azienda può avere elementi misurabili, come l’ammontare delle perdite che è disposta a tollerare, i suoi rapporti di indebitamento e il tipo di ritorno sull’investimento (ROI) a cui mira. Può anche dover considerare aspetti soggettivi, come il potenziale impatto sulla reputazione aziendale, le considerazioni etiche e quanto le sue decisioni siano allineate ai valori fondamentali.

Perché è importante definire la propensione al rischio?

Quasi ogni organizzazione che vuole avere successo deve assumersi rischi calcolati. Ma senza una chiara comprensione della propria propensione al rischio, può ritrovarsi a prendere decisioni incoerenti, reattive o eccessivamente prudenti. Questo può portare a opportunità mancate o perdite aziendali. Ecco perché definire la propensione al rischio è essenziale:

Allineare strategia e gestione del rischio

Disporre di una propensione al rischio chiaramente definita fornisce un framework strategico che allinea le pratiche di gestione del rischio agli obiettivi aziendali complessivi. Quando un’impresa sa quanto rischio è disposta ad accettare, può perseguire le opportunità coerenti con la propria propensione al rischio, evitando quelle che potrebbero esporla a rischi eccessivi.

Migliorare il processo decisionale

Definire la propensione al rischio consente a leader e manager di prendere decisioni informate comprendendo chiaramente cosa costituisce un rischio accettabile. Stabilisce inoltre le aspettative per i comportamenti orientati sia all’assunzione sia all’evitamento del rischio in tutta l’organizzazione, aiutando i manager a valutare i compromessi tra rischio e ricompensa in diversi scenari.

Rafforzare la fiducia degli stakeholder

Una propensione al rischio chiaramente definita rassicura investitori, autorità di regolamentazione, dipendenti e altri stakeholder sul fatto che l’organizzazione attribuisce priorità alla gestione del rischio. Dimostra inoltre un approccio metodico e affidabile nel bilanciare rischio e rendimento, rafforzando ulteriormente la fiducia degli stakeholder.

Promuovere la coerenza

Quando tutti in un’organizzazione sono allineati su quanto rischio sia consentito, riescono a prendere decisioni coerenti perché comprendono tutti cosa rappresenti una scommessa accettabile. Questo riduce le probabilità di lavorare con obiettivi divergenti o persino in direzioni opposte. Ad esempio, un reparto legale potrebbe frenare la grande idea di un team marketing se non condivide la stessa concezione di rischio accettabile.

Supportare un monitoraggio efficace del rischio

Quando le aziende definiscono la propria propensione al rischio, possono implementare sistemi per monitorare i livelli di rischio in tutta l’impresa, dalla finanza alle operation. In questo modo, sono in grado di individuare tempestivamente potenziali problemi e garantire che le attività rimangano entro i limiti di ciò che è considerato sicuro, o almeno accettabile. Definire e monitorare gli indicatori chiave di rischio (KRI) fornisce segnali di allarme precoce quando ci si avvicina troppo a quei limiti.

Come definisce un’azienda la propria propensione al rischio?

In genere, un’organizzazione lo fa redigendo una dichiarazione di propensione al rischio (RAS). Le prime parti di una RAS illustrano gli obiettivi strategici dell’azienda e i rischi coinvolti.

Un’azienda potrebbe voler diventare il principale fornitore di software nel proprio settore. Dovrebbe elencare gli obiettivi strategici essenziali per raggiungere tale traguardo, insieme ai rischi associati. Ad esempio, Ivanti opera nel settore della fornitura di servizi IT basati su cloud e soluzioni di gestione della sicurezza. Ciò significa che la nostra dichiarazione di propensione al rischio deve catalogare tutti i rischi legati a questa linea di business e spiegare come li gestiremo.

Ecco un esempio di come potrebbe apparire una sezione di una dichiarazione di propensione al rischio per un fornitore di software:

Propensione generale al rischio
[Azienda XYZ] adotta un approccio equilibrato al rischio, riconoscendo che non tutti i rischi sono uguali e che un certo livello di rischio è necessario per raggiungere i nostri obiettivi strategici.
Rischio di innovazione Abbiamo un’elevata propensione al rischio per gli investimenti in tecnologie avanzate e soluzioni innovative che differenziano i nostri prodotti nel panorama competitivo. Comprendiamo che ciò richiede l’accettazione di un certo grado di incertezza nelle attività di R&S e nello sviluppo prodotto.
Rischio operativo Manteniamo una propensione al rischio da bassa a moderata. Pur puntando all’eccellenza operativa, diamo priorità alle iniziative che migliorano l’efficienza e la qualità del servizio senza compromettere i nostri standard di erogazione.
Rischio di sicurezza Abbiamo una propensione al rischio estremamente bassa per minacce e violazioni della sicurezza. Il nostro impegno per la sicurezza di rete e la protezione dei dati è fondamentale e investiamo in modo significativo per salvaguardare i nostri sistemi e i dati dei nostri clienti.
Rischio di conformità Abbiamo una bassa propensione al rischio di non conformità ai requisiti legali e normativi. Garantire l’aderenza a leggi, standard e best practice pertinenti in tutte le aree operative è fondamentale.

Propensione generale al rischio [Azienda XYZ] adotta un approccio equilibrato al rischio, riconoscendo che non tutti i rischi sono uguali e che un certo livello di rischio è necessario per raggiungere i nostri obiettivi strategici.
Rischio di innovazione	Abbiamo un’elevata propensione al rischio per gli investimenti in tecnologie avanzate e soluzioni innovative che differenziano i nostri prodotti nel panorama competitivo. Comprendiamo che ciò richiede l’accettazione di un certo grado di incertezza nelle attività di R&S e nello sviluppo prodotto.
Rischio operativo	Manteniamo una propensione al rischio da bassa a moderata. Pur puntando all’eccellenza operativa, diamo priorità alle iniziative che migliorano l’efficienza e la qualità del servizio senza compromettere i nostri standard di erogazione.
Rischio di sicurezza	Abbiamo una propensione al rischio estremamente bassa per minacce e violazioni della sicurezza. Il nostro impegno per la sicurezza di rete e la protezione dei dati è fondamentale e investiamo in modo significativo per salvaguardare i nostri sistemi e i dati dei nostri clienti.
Rischio di conformità	Abbiamo una bassa propensione al rischio di non conformità ai requisiti legali e normativi. Garantire l’aderenza a leggi, standard e best practice pertinenti in tutte le aree operative è fondamentale.

La RAS dovrebbe definire i rischi che avrebbero il maggiore impatto sull’organizzazione, non i rischi quotidiani che fanno semplicemente parte dell’attività aziendale. Dovrebbe tenere conto di più scenari di rischio; ad esempio, una strategia specifica può comportare rischi della supply chain, come gli effetti di un vincolo con un fornitore o i pericoli di esposizione normativa se un fornitore gestisce in modo improprio i dati dei clienti.

Dovrebbe inoltre definire l’entità del rischio finanziario che un’azienda è disposta ad assumersi. Se i suoi obiettivi includono l’offerta di un nuovo prodotto o servizio, esiste sempre la possibilità di un insuccesso sul mercato.

Componenti della propensione al rischio

Questi sono i fattori chiave da considerare nella definizione della propensione al rischio:

Capacità di rischio

Si riferisce alla quantità massima di rischio che un’organizzazione può sostenere. A determinarla sono le risorse finanziarie, le capacità operative e i vincoli normativi. E la capacità di rischio è diversa dalla propensione al rischio: un’organizzazione può avere la capacità di assumersi un determinato livello di rischio, ma potrebbe scegliere di non farlo in base alla propria propensione al rischio.

Tolleranza al rischio

Mentre la capacità di rischio riguarda quanto rischio un’organizzazione è in grado di sopportare, la tolleranza al rischio è una deviazione accettabile rispetto all’obiettivo. Può persino stabilire tolleranze diverse per aree diverse. Ad esempio, un’organizzazione potrebbe essere favorevole ad assumersi un rischio su un nuovo prodotto, ma essere avversa al rischio nella gestione dei dati dei clienti.

Soglie di rischio

Abbiamo già menzionato il monitoraggio del rischio e i KRI, utilizzati per impedire a un’azienda di superare le soglie di rischio: le “linee rosse” che rappresentano un rischio eccessivo. Il superamento di una soglia di rischio potrebbe richiedere un cambiamento dei piani, maggiori misure di sicurezza o persino l’arresto completo delle attività in corso.

Correlato: report di ricerca Ivanti: Allineare le prospettive: gestione del rischio informatico nella C-suite

Perché la propensione al rischio è importante nella gestione dell’esposizione?

Un tempo, mitigare il rischio digitale era molto più semplice di oggi. Questo perché le superfici di attacco della maggior parte delle grandi organizzazioni si sono notevolmente ampliate nel tempo. L’aggiunta di più dispositivi e applicazioni, utilizzati dai dipendenti in un numero maggiore di luoghi, ha trasformato il workplace e ampliato il panorama delle minacce digitali.

È uno dei motivi per cui una ricerca Ivanti ha rilevato che oltre la metà dei professionisti IT non è molto sicura di poter prevenire un incidente di sicurezza dannoso nei prossimi 12 mesi. Più di uno su tre afferma persino di essere meno preparato a rilevare le minacce e rispondere agli incidenti rispetto a un anno fa.

La gestione delle vulnerabilità tradizionale si è a lungo concentrata sulla correzione reattiva delle vulnerabilità software e hardware e di altre CVE, ma di solito si basa solo su scansioni intermittenti. Tuttavia, lo scenario attuale delle minacce informatiche richiede un nuovo approccio.

La gestione moderna dell’esposizione si concentra sull’individuazione e sulla correzione continue e proattive di rischi e vulnerabilità nell’intera superficie di attacco digitale, indipendentemente dal fatto che derivino da asset IT esposti, endpoint e applicazioni non protetti, risorse basate su cloud o altri vettori. Che cosa rende così strettamente correlate gestione dell’esposizione e propensione al rischio?

Valutare l’esposizione in base ai livelli di rischio accettabili: La gestione dell’esposizione implica la quantificazione dei livelli di rischio associati alle diverse esposizioni. Definendo il rischio accettabile, le organizzazioni possono confrontare il possibile impatto dei diversi rischi con la propria propensione al rischio.
Distribuire le risorse in base al rischio: Le organizzazioni devono dare priorità alle esposizioni che rappresentano la maggiore minaccia per le loro strategie: una valutazione che possono effettuare solo con una chiara comprensione della propria propensione al rischio. Questa prioritizzazione consente loro di concentrare le risorse sulla mitigazione delle esposizioni più critiche, spesso con l’aiuto di uno strumento RBVM avanzato.
Adeguare la propensione al rischio: Quando un contesto aziendale cambia o emergono nuovi rischi, può essere necessario adeguare la propensione al rischio. I dati e gli insight che le organizzazioni ottengono nell’ambito della loro pratica di gestione dell’esposizione le aiutano a prendere decisioni informate su tali adeguamenti.
Garantire la conformità: Molti settori hanno requisiti normativi relativi alla gestione del rischio, che a loro volta influenzano la propensione al rischio di un’organizzazione. La gestione dell’esposizione comporta l’identificazione e la gestione dei rischi che potrebbero causare non conformità.

Correlato: report di ricerca Ivanti: Gestione della superficie di attacco

Osservare il rischio di sicurezza attraverso la lente della gestione dell’esposizione

Una differenza significativa tra la gestione dell’esposizione e altre pratiche di sicurezza è che la gestione dell’esposizione non si limita a dare priorità alla correzione dei rischi che rappresentano il rischio maggiore per l’organizzazione, ma definisce attivamente quali rischi rientrano nella tolleranza al rischio dell’organizzazione. Ad esempio, un’azienda di e-commerce può essere disposta ad accettare rischi di sicurezza più elevati per mantenere il proprio sito funzionante durante il Black Friday: per lei, il compromesso vale la pena.

Invece di considerare ogni rischio potenziale come una crisi che richiede una correzione immediata, le organizzazioni devono assegnare le priorità in base alle esigenze aziendali. In questo framework, la maggior parte dei rischi non è negativa: conta il modo in cui si reagisce, si controlla e si mitiga il rischio per portarlo a un livello accettabile.

In che modo la gestione delle patch basata sul rischio dà priorità alle vulnerabilità sfruttate attivamente

Fri, 03 Jan 2025 18:10:36 Z

La resistenza al cambiamento è sempre presente, soprattutto se si ritiene che i processi già in uso siano efficienti ed efficaci. Molte organizzazioni la pensano così riguardo alle proprie procedure di gestione del software, finché non subiscono una violazione o un incidente di sicurezza e si chiedono dove abbiano sbagliato.

La realtà è che la maggior parte dei programmi di gestione delle patch si basa su ipotesi e raccomandazioni, anziché su dati concreti relativi alle vulnerabilità sfruttate attivamente. La gestione delle patch basata sul rischio è la risposta a questo problema.

In questo articolo troverai:

Cosa non funziona nel mantenere le priorità tradizionali.
Che cos’è la gestione delle patch basata sul rischio.
Perché è il momento ideale per adottare la gestione delle patch basata sul rischio.

I problemi della prioritizzazione tradizionale delle patch

Gli aggiornamenti delle funzionalità software, le correzioni di sicurezza, le correzioni di bug, i miglioramenti delle prestazioni e molti altri tipi di release software esistono sin dagli inizi dell’industria del software. I vendor spesso assegnano a ciascuno di questi elementi un livello di gravità o un altro punteggio per indicare ai clienti ciò che ritengono più importante.

Purtroppo non esiste uno standard di settore associato a queste valutazioni, quindi ci troviamo a dover confrontare e prioritizzare le release da distribuire sui nostri sistemi sulla base di raccomandazioni. Inoltre, tali valutazioni vengono aggiornate raramente per tenere conto del contesto delle minacce attive, anche quando le vulnerabilità cambiano.

Trascurare una vulnerabilità sfruttata attivamente

Pur essendo meglio di niente, le valutazioni di gravità dei vendor spesso non sono sufficienti. Prendiamo in considerazione la vulnerabilità Follina (CVE-2022-30190) pubblicata a maggio 2022. Questa vulnerabilità nello strumento di diagnostica del supporto Microsoft Windows (MSDT) consente l’esecuzione di codice da remoto.

Follina è stata oggetto di attacchi per diversi mesi prima che Microsoft rispondesse infine con vari aggiornamenti. In modo preoccupante, Microsoft ha assegnato a questa vulnerabilità solo una valutazione Common Vulnerability Scoring System (CVSS) v3 pari a 7,8 e una gravità di livello Importante. Se si applicano le patch solo in base alla gravità Critica, questa vulnerabilità sarebbe passata inosservata, lasciando una lacuna significativa nella superficie di attacco.

Ancora peggio, il punteggio CVSS di Follina è rimasto a 7,8 anche dopo che è emerso che la vulnerabilità veniva sfruttata attivamente per distribuire il ransomware Bisamware, esponendo a un rischio ancora maggiore le organizzazioni che avevano trascurato la vulnerabilità.

Informazioni di intelligence sulla minaccia ransomware associata a CVE-2022-30190 visualizzate in Ivanti Neurons for VULN KB

Limiti del CVSS

Le valutazioni di gravità vengono “arricchite” con i punteggi CVSS di FIRST. A ogni CVE viene assegnato un numero CVSS, come il 7,8 attribuito a CVE-2022-30190 nell’esempio precedente.

Uno degli obiettivi principali del calcolo del numero CVSS effettivo è garantire la standardizzazione, in modo che tutti i CVE siano valutati in modo coerente e possano essere confrontati con precisione. Quanto più alto è il punteggio CVSS di una vulnerabilità e della patch associata, tanto più critica è la sua distribuzione nella maggior parte degli ambienti.

Per gli aggiornamenti software che risolvono più CVE, di solito viene preso in considerazione il valore CVSS più alto ai fini della prioritizzazione. Ma questo valore è davvero accurato?

I risultati di un’analisi dei punteggi CVSS in un articolo recente hanno mostrato una discrepanza in quasi il 20% dei punteggi CVSS (25.000). Questa analisi si basava su un confronto tra i punteggi riportati nel National Vulnerability Database (NVD) del NIST e quelli comunicati direttamente dai vendor stessi.

Incoerenze nelle valutazioni di gravità dei vendor

Un punto importante da tenere presente è che storicamente i vendor hanno assegnato una propria terminologia alla gravità (ad esempio, critica, importante). Usare il punteggio di gravità del vendor come meccanismo di prioritizzazione può funzionare bene quando si confrontano tutte le patch di un determinato vendor, ma non sempre offre un confronto accurato delle patch tra vendor diversi. Di fatto, molti utilizzano terminologie completamente differenti.

Analogamente, la gravità indicata dal vendor non è sempre un indicatore positivo. Molte vulnerabilità zero-day sono classificate da Microsoft solo come Importanti, pur avendo punteggi CVSS elevati. È evidente come l’applicazione delle patch utilizzando gravità e CVSS per la prioritizzazione si basi su ipotesi e raccomandazioni e possa tradursi in un ambiente vulnerabile.

Perché dare priorità agli exploit attivi rispetto a qualsiasi altro metodo di prioritizzazione?

Secondo la Cybersecurity and Infrastructure Security Agency (CISA) degli Stati Uniti, una vulnerabilità sfruttata attivamente è “una vulnerabilità per la quale esistono prove affidabili che l’esecuzione di codice dannoso sia stata effettuata da un attore su un sistema senza l’autorizzazione del proprietario del sistema”. In termini semplici, una vulnerabilità in fase di sfruttamento attivo è una vulnerabilità che è stata utilizzata da un attore della minaccia per lanciare un attacco informatico.

Pertanto, per ridurre al minimo il rischio di un attacco alla tua organizzazione, devi dare priorità alle vulnerabilità sfruttate attivamente rispetto a tutte le altre. La buona notizia è che la maggior parte delle vulnerabilità non viene sfruttata attivamente e quindi rappresenta un rischio minimo o nullo per la tua organizzazione. È possibile identificare quelle che sono state sfruttate tramite la gestione delle patch basata sul rischio.

Che cos’è la gestione delle patch basata sul rischio?

La gestione delle patch basata sul rischio è un’estensione della gestione delle vulnerabilità basata sul rischio, che va oltre la gravità indicata dai vendor e i punteggi CVSS di base per identificare e qualificare le vulnerabilità specifiche che pongono il rischio più significativo per un’organizzazione. Questo integra il contesto del rischio reale nel processo di gestione delle patch, affinché i team IT possano concentrare i propri sforzi sugli aggiornamenti con vulnerabilità note sfruttate che contano maggiormente per la postura di sicurezza dell’organizzazione.

In che modo la mia organizzazione può adottare la gestione delle patch basata sul rischio?

Per le organizzazioni pronte ad adottare un approccio alla gestione delle patch basato sul rischio, un buon punto di partenza è il catalogo CISA Known Exploited Vulnerabilities (KEV). CISA ha compiuto un importante passo avanti per aiutare a prioritizzare le vulnerabilità quando ha introdotto la Binding Operational Directive 22–01 insieme al suo catalogo KEV. Al momento della pubblicazione iniziale, il catalogo conteneva circa 200 vulnerabilità sfruttate attivamente. Da allora è cresciuto fino a quasi 900.

CISA costruisce l’elenco sapendo che le vulnerabilità incluse vengono sfruttate in contesti reali da minacce attive. Tuttavia, l’elenco presenta alcuni limiti, poiché attualmente esclude 131 vulnerabilità associate al ransomware.

Il catalogo CISA KEV è l’unica risorsa disponibile per la gestione delle patch basata sul rischio?

Le organizzazioni con pratiche di gestione delle patch basata sul rischio più mature sfruttano metodologie avanzate di scoring del rischio in sostituzione o in aggiunta al CVSS. Queste metodologie assegnano punteggi a ogni vulnerabilità identificata nell’ambiente di un’organizzazione, consentendo a tali organizzazioni di estendere il proprio approccio basato sul rischio oltre il CISA KEV.

Molti vendor nell’ambito della gestione delle vulnerabilità basata sul rischio hanno sviluppato metodologie di scoring proprietarie che rappresentano il rischio reale posto da una vulnerabilità. Lo fanno fornendo valutazioni dinamiche del rischio che attribuiscono un peso maggiore alle vulnerabilità sfruttate attivamente.

Ad esempio, il Vulnerability Risk Rating (VRR) di Ivanti ha assegnato a Follina un punteggio di 10, un punteggio che rappresenta il rischio posto da quella vulnerabilità in modo più accurato rispetto al suo punteggio CVSS di 7,8.

La differenza tra i punteggi VRR e CVSS v3 e i livelli di gravità per CVE-2022-30190, come mostrato in Ivanti Neurons for VULN KB

Perché è il momento ideale per adottare la gestione delle patch basata sul rischio

Se ritieni di essere rimasto indietro con gli aggiornamenti di sistema o di essere sopraffatto da nuovi sistemi e applicazioni nella tua azienda, questo è il momento ideale per adottare la gestione delle patch basata sul rischio.

Anche se ritieni di avere già un programma solido basato su valutazioni di gravità e punteggi CVSS, è il momento di superare la resistenza al cambiamento e avviare un nuovo processo prima che la tua azienda subisca gravi danni a causa di una violazione dei dati derivante da una vulnerabilità sfruttata.

Inizia utilizzando il CISA KEV per prioritizzare gli aggiornamenti e destina un budget a una soluzione di gestione delle vulnerabilità e delle patch basata sul rischio. Con gli strumenti adeguati a disposizione, puoi identificare rapidamente i sistemi a più alto rischio da aggiornare per primi e procedere lungo l’elenco per garantire la sicurezza dei tuoi sistemi.

Vuoi compiere il primo passo? Consulta questo eBook: una guida completa per implementare un moderno programma di gestione delle patch basata sul rischio.