Un tempo bastava un link phishing banale. Oggi gli attacchi arrivano con un look professionale – con nomi scritti correttamente, firme reali e tempistiche precise. L’IA genera voci, volti e inviti a riunioni; i deepfake imitano dirigenti, fornitori o autorità. Parallelamente, gli attacchi Adversary-in-the-Middle (AitM) aggirano i flussi MFA tradizionali catturando le sessioni in tempo reale. Non è fantascienza, è quotidianità. Il punto debole raramente è la tecnologia – sono approvazioni affrettate, mancanza di richiamate e una mentalità “ce la caviamo comunque”.

Tattiche Che Funzionano Oggi

• Imitazione della voce + pressione temporale: Una “chiamata del capo” poco prima della fine della giornata, accompagnata da “approvare urgentemente”. Il contenuto è banale, il contesto perfetto.
• Iniezione in calendario: Invito a riunione reale con link mascherato; la lista dei partecipanti appare legittima.
• AitM contro MFA: Login tramite portali falsi, token rubati, sessioni hijackate – nonostante la presenza di MFA.
• Falsificazione fornitori: Cambio del conto bancario “per fusione”. I documenti sembrano autentici, gli allegati ben formattati.
• Post-compromise phishing: Dopo l’accesso iniziale, gli attaccanti inviano email reali da caselle reali – ogni “verifica” risulta positiva.

Dove Falliscono le Aziende (Onestamente)

Due debolezze sono costanti: mancanza di ancore di processo e responsabilità poco chiare. Molte policy sono solo PDF decorativi, non comportamenti reali. Non ci sono verifiche obbligatorie fuori banda, nessun principio delle quattro occhi per i movimenti finanziari, e helpdesk o reparti non sono obbligati a segnalare subito “chiamate sospette”. Inoltre, i flussi legacy rimangono aperti (Basic/IMAP), rendendo la MFA inefficace nella pratica.

Come Fermare il Social Engineering – In Pratica

Concentrarsi prima sul comportamento, poi sulla tecnologia. L’ordine è intenzionale.

1. Processo prima della personalità. Nessun pagamento, cambio conto o aumento privilegi senza verifica documentata tramite un secondo canale conosciuto. Nessuna eccezione per persone “importanti” – proprio loro vengono imitate.
2. Rituali fuori banda obbligatori. Numeri di richiamo definiti (dal directory interna), parole chiave per approvazioni sensibili, richiamo solo tramite contatti centralizzati – non il numero nell’email.
3. Accesso sicuro contro phishing. MFA con passkey/FIDO2, disattivazione dei protocolli deboli, riconvalida sessione in caso di rischio. Contro AitM, tecnologia più verifica del contesto (es. binding dominio, binding dispositivo).
4. Rispetta il principio del least privilege. Meno diritti permanenti ci sono, minore l’impatto di approvazioni forzate. Diritti amministrativi temporanei (JIT) riducono situazioni di pressione.
5. Esercizi realistici. Niente slide. Simulare chiamate del capo, cambi fornitori, inviti di calendario – con pressione temporale e “per favore, velocemente”. Obiettivo: rendere riflessivo il segnale di stop (“richiamare!”).

Processi per Cambiamenti di Denaro & Identità (Standard Minimo)

• Principio delle quattro occhi per tutti i pagamenti oltre soglia X e per ogni modifica di dati bancari.
• Verifica a due canali: Richiamo tramite numero interno + conferma scritta con template memorizzato.
• Periodo di blocco: Nuovi dati bancari attivi solo dopo catena di verifica documentata.
• Whitelist fornitori: Cambiamenti solo se la persona e il canale corrispondono a un record memorizzato.
• Audit trail: Ogni approvazione genera ticket con timestamp, passaggi di verifica e partecipanti. Nessun ticket – nessuna modifica.

Tecnologia Che Aiuta Davvero (Senza Nomi di Vendor)

• Autenticazione email & rilevamento anomalie (SPF/DKIM/DMARC + controlli euristici) riducono il rumore – ma non sostituiscono mai il processo.
• Policy su link/allegati con controlli pre-esecuzione, sandboxing per file sconosciuti e blocco dei flussi di abuso noti.
• Isolamento browser per obiettivi ad alto rischio (Finance, HR) con link esterni da email o calendario.
• Sicurezza sessione: Binding token a dispositivo/browser, validità breve, logout automatico in caso di cambio contesto.
• Telemetria identità: Viaggi impossibili, deviazioni di ruolo, approvazioni insolite → immediata richiesta di conferma / step-up auth.

Metriche Che Contano (E Creano Pressione)

• Tasso di verifica per cambiamenti di denaro/identità: percentuale di casi con verifica a due canali riuscita.
• Time-to-verify: Tempo dalla richiesta alla verifica completata – obiettivo rapido e rigoroso.
• Tasso di segnalazione: Percentuale di dipendenti che segnalano contatti/chiamate sospette.
• Tasso di blocco AitM: Tentativi bloccati/interrotti grazie a binding dominio/dispositivo.
• Eventi push-fatigue: Tentativi MFA spam respinti e numero di flussi “click-to-approve” disattivati.
• Successo esercizi: Percentuale di scenari reali superati (chiamata capo, cambio fornitore) – senza preavviso.

Obiezioni Tipiche – Risposte Sobrie

• “Rallenta il nostro business.” – Giusto. Rallenta solo ciò che muove denaro o cambia identità. Tutto il resto continua.
• “Il nostro personale se ne accorgerebbe.” – Fino a stress, ferie o cambi turno. I processi proteggono le persone – non il contrario.
• “Abbiamo MFA.” – Se AitM cattura sessioni o flussi legacy sono aperti, è solo apparenza. Rinforzare o disattivare.

Conclusione

Il social engineering è preciso, cortese e credibile. Affidarsi al solo intuito fa perdere. Applicando processi, rinforzando MFA contro AitM e esercitandosi realisticamente, si riduce drasticamente il tasso di successo – misurabile in metriche di verifica ed esercizio. Non è opzionale; è mitigazione del danno in euro e ore. In breve: allenare la contro-voce, obbligare il richiamo, mantenere i diritti minimi. Così “per favore, approva velocemente” diventa “aspetta, stiamo verificando” – e questo salva denaro, dati e nervi.

FAQ sul post del blog

Un aggiornamento distribuito centralmente dell’agente o della piattaforma fallisce — improvvisamente i client si bloccano, le firme vanno in conflitto, le policy si applicano in modo errato o i servizi non si avviano più. Lo schema è sempre lo stesso: un interruttore globale, un canale di rollout, un presupposto (“andrà tutto bene”) — e all’improvviso un intero parco endpoint si ferma, le autenticazioni rallentano o le catene di monitoraggio si interrompono.

Per gli attaccanti non è stato necessario alcun accesso; il guasto è auto-inflitto a causa dell’accoppiamento. Chi si concentra solo sulle colpe perde la lezione: il problema è strutturale — lock-in senza una via di uscita.

Perché il rischio viene sottovalutato

In molti ambienti di sicurezza, controlli, telemetria e operation sono topologicamente accoppiati: una console, un agente, un formato dati, una finestra di manutenzione. Questo riduce lo sforzo — finché proprio questo vantaggio non diventa un single point of failure.

Anche negli audit la coerenza rassicura: report uniformi, un unico set di policy. Ma la coerenza non sostituisce la resilienza. Nasconde le dipendenze finché un rollout non va storto e il “vantaggio” si trasforma dall’oggi al domani in una valanga di costi (fermo operativo, supporto sul campo, comunicazione di crisi, esplosione di ticket).

Ridurre la dipendenza — senza proliferazione di tool

Non si tratta di ideologia (“piattaforma vs. best-of-breed”), ma di disaccoppiare consapevolmente nei punti in cui un errore farebbe più male. Quattro principi bastano per trasformare un rischio concentrato in un rischio gestibile:

• Rollout scaglionati invece del big bang. Prima un piccolo gruppo canary rappresentativo con profili reali di produzione, poi anelli successivi. Il rollback deve essere tecnicamente possibile (stati di policy specchiati, versioni firmate degli artefatti, percorsi di downgrade documentati).
• Garantire accesso out-of-band. Se l’agente primario si blocca, serve un secondo canale: KVM remoto, rete di management, un piano di emergenza locale per sbloccare/disattivare — con matrice di approvazione e logging.
• Imporre la portabilità dei dati. Allarmi, policy e artefatti devono essere esportabili (formati aperti, API). Senza questo, qualsiasi “alternativa” resta una fantasia da PowerPoint.
• Seconda protezione mirata. Niente zoo di strumenti — ma per i percorsi business-critical uno strato leggero e indipendente di protezione (ad es. ulteriore hardening del sign-in per le identità, backup immutabili, canale di log separato). Così si crea interoperabilità senza caos.

Meccanismi di uscita che funzionano già oggi

Un exit plan vale solo quanto la sua prova pratica. In concreto significa:

1. Predefinire fallback funzionali. Per isolamento endpoint, blocco account o terminazione sessione esiste un playbook tool-agnostico e almeno un secondo percorso testato.
2. Migrare gli artefatti in giorni, non mesi. Policy e use case possono essere esportati, mappati e attivati su un’alternativa; il 10% più critico è già convertito in anticipo.
3. Considerare la neutralità delle licenze. Concordare con i partner contingenti di emergenza o licenze attivabili a breve termine — in modo vincolante, non “dovrebbe funzionare”.
4. Cross-training. Un secondo team conosce operativamente l’alternativa. La dipendenza dall’“unico” amministratore è la forma silenziosa di lock-in.

Come misurare un accoppiamento sano

Le metriche rendono visibile l’illusione. Indicatori rilevanti includono:

• Time-to-Disable: minuti necessari per disattivare o ritirare un aggiornamento difettoso su larga scala.
• Rollback Rate: percentuale di sistemi che tornano all’ultima versione stabile senza intervento manuale.
• Copertura Canary: percentuale di nodi di test realistici (ruoli/sedi/immagini diverse).
• Raggiungibilità Out-of-Band: quota di sistemi critici con un secondo canale funzionante.
• Data Portability Score: esportabilità di incident, policy e artefatti (formato, completezza, re-import testato).
• Successo dei drill: prova documentata di “prodotto primario fuori uso” con tempo fino a visibilità/contenimento.

Queste metriche devono entrare nello stesso steering di patch SLO o MTTD/MTTR. Senza di esse, la sicurezza IT resta una questione di sensazioni.

Obiezioni tipiche — e la risposta sobria

• “Un guasto del genere è raro.” — Proprio per questo vi coglie impreparati. Resilienza significa superare eventi rari, non minimizzarli.
• “Con una strategia mono-vendor risparmiamo enormemente sui costi operativi.” — Vero, finché non arriva il Giorno X. La domanda è se l’ora risparmiata oggi giustifica un giorno di fermo domani.
• “Abbiamo i backup.” — I backup aiutano in caso di perdita di dati. Con errori di agent o policy serve controllo, non ripristino. Due classi diverse di emergenza.

Rafforzare la pratica — senza fare nomi

Non dovete cambiare fornitore per essere più sicuri. Dovete ridurre l’accoppiamento: rollout in anelli, test dei percorsi di ritorno, attivazione di canali di comunicazione secondari, validazione regolare delle esportazioni e una protezione parallela snella nei colli di bottiglia business-critical (identità, ripristino, visibilità). Tutto questo riduce l’impatto di un errore — ovunque si verifichi.

Conclusione

Un aggiornamento globale andato storto non è un evento esotico, ma una conseguenza inevitabile del controllo centralizzato. La risposta non è un bazar di tool, ma disciplina architetturale: rendere visibile il lock-in, predisporre vie di fuga, imporre interoperabilità ed esercitare i rollback.

Così restate operativi — anche quando l’“unico” fornitore inciampa. Questa è la differenza tra comodità e vera resilienza.

FAQ sul post del blog

Molti ambienti di sicurezza sono cresciuti in modo storico: ogni lacuna ha avuto il suo tool, ogni raccomandazione di audit una licenza, ogni nuova minaccia un’altra dashboard. Il risultato non è uno scudo, ma un patchwork. Le conseguenze sono misurabili: tempi di risposta più lunghi, segnali contraddittori, punti ciechi. Verità scomoda: più prodotti non significano automaticamente più sicurezza IT. Senza una solida interoperabilità, il rischio cyber aumenta – anche con budget più elevati.

Come riconoscere subito lo zoo dei tool

• Giostra degli allarmi: un evento genera cinque alert in tre sistemi – nessuno sa quale sia quello “vero”.
• Vuoti di consegna: il SOC segnala, l’IT Ops non comprende, il business non si sente responsabile.
• Deriva di configurazione: le policy sono gestite in modo diverso in ogni tool; dopo tre mesi nessuno sa più cosa sia “valido”.
• Stress da cambiamento: un aggiornamento nel prodotto A rompe l’integrazione con B; il workaround rende C cieco.
• Teatro del reporting: i report trimestrali sono belli – ma non correlati a MTTD/MTTR o alla disponibilità dei processi.

Se annuite su due punti, state pagando la complessità – non la protezione.

I costi nascosti (che non compaiono in nessuna offerta)

La voce più costosa non è la licenza, ma l’attrito: ogni interfaccia aggiuntiva richiede manutenzione, test, troubleshooting e competenze. Questo attrito divora tempo di reazione durante un incidente e riduce la tracciabilità – l’esatto opposto della resilienza. Si aggiunge il rischio strategico: più formati e agent proprietari accumulate, più alto sarà il costo di migrazione futura. Alla fine non scegliete il prodotto migliore, ma quello che fa meno male. Benvenuti nel lock-in strisciante.

Consolidare senza dogmi: i quattro principi

1. Use case prima delle feature. Definite i cinque casi di difesa più importanti (identità, email, endpoint, app esterne, supply chain). Un tool conta solo se migliora in modo evidente questi casi.
2. Un unico percorso dati, molti consumatori. La telemetria viene raccolta e normalizzata una sola volta, in modo pulito. Le analisi possono variare; la fonte no. Senza un percorso dati coerente, ogni correlazione è casuale.
3. Un’unica fonte per le policy. Le regole di sicurezza esistono in un solo luogo; le declinazioni per i tool sono generate, non copiate a mano. Così si evita la deriva – il modo più silenzioso per perdere la sicurezza IT.
4. Portabilità prima della perfezione. Nessun prodotto senza solidi meccanismi di export per incidenti, policy e artefatti. Questo riduce i costi di uscita e disciplina i fornitori – e voi stessi.

Il minimo di architettura che fa davvero la differenza

Consolidare non significa “un solo tool per tutto”, ma “il meno possibile, quanto necessario”. In pratica: una pipeline eventi centrale, un gate di identità con MFA resistente al phishing, un sensore endpoint coerente, reti segmentate, un percorso di backup/restore robusto con verifica di integrità – e playbook formulati in modo agnostico rispetto ai tool. Se “isolare”, “terminare sessione” e “disabilitare account” esistono solo come pulsanti nel vostro prodotto preferito, non avete un processo – ma una dipendenza.

Domande chiave a cui rispondere per iscritto:

• Dove nasce il nostro single point of truth per gli eventi – e cosa succede se fallisce?
• Quali controlli sono doppi per scelta e quali solo ridondanti per caso?
• Come migreremmo oggi una funzione core verso un’alternativa – in giorni, non in mesi?

Linee guida per una vera consolidazione dei tool

• Tagliate le sovrapposizioni, non le capacità. Due prodotti che fanno “più o meno” la stessa cosa sono un campanello d’allarme – non un vantaggio.
• Automatizzate le prime misure (isolamento, chiusura sessione, ticket/pager) tramite un orchestratore neutrale. Così la scelta dei sensori resta flessibile.
• Definite criteri di stop chiari: nessun prodotto senza export documentati, copertura API, strategia di test e canary rollout.
• Proteggete la catena di protezione: health check che verificano invio dei dati, funzionamento dei parser, escalation degli alert – incluso il failover.

Cosa deve essere misurato (altrimenti è solo percezione)

• Tempo alla prima effettiva azione di contenimento – non solo MTTR.
• Conformità agli SLO di patching: criticità esposte a internet in giorni, interne in settimane definite – in modo verificabile.
• Percentuale di alert correlati vs. rumore per use case.
• Tasso di deriva: quanto spesso le policy divergono tra tool – e per quanto tempo resta inosservato?
• Capacità di uscita: tempo e passaggi per migrare una funzione core (es. endpoint detection) verso un’alternativa – inclusa la migrazione dei dati.

Queste metriche mostrano se l’interoperabilità è pratica reale o solo slide.

Obiezioni frequenti – e la risposta sobria

• “Il best-of-breed batte la piattaforma.” – Solo se potete permettervi e gestire il dolore dell’integrazione. Altrimenti il best-of-breed diventa best-of-chaos.
• “Il nostro team ama il tool X.” – L’accettazione è importante, ma non è un criterio di sicurezza. Se X indebolisce la catena, X deve andare – punto.
• “Teniamo tutto, è ridondanza.” – La ridondanza senza ruoli chiari è solo complessità doppia. La ridondanza va nei punti critici – in modo consapevole, testato, documentato.

Conclusione: meno tool, più impatto

La via più rapida verso una resilienza robusta non è il prossimo acquisto, ma l’eliminazione della zavorra. La vera consolidazione dei tool crea focus, riduce l’attrito e rende la risposta misurabilmente più veloce. Riduce il rischio cyber perché restano meno fonti di errore, meno deriva e responsabilità più chiare. Consolidate con un piano, non con un’ideologia – e tenete aperta la porta d’uscita. Così deciderete per forza, non per abitudine.

FAQ sul post del blog

Il dibattito “un fornitore contro molti” viene spesso condotto in modo ideologico. Uno stack mono-vendor offre chiarezza e velocità? Sì. Crea dipendenza? Anche. Un approccio multi-vendor garantisce maggiore interoperabilità e resilienza? In alcuni casi sì. Ma richiede anche più disciplina architetturale e maggiore impegno operativo? Decisamente. La verità sta nel bilanciare: quanto rischio di concentrazione può tollerare il vostro business – e quale prezzo di integrazione siete disposti a pagare?

Il fascino dell’approccio Mono-Vendor

Un ecosistema coerente accelera le decisioni. Una console, un modello dati, un processo di supporto. Meno errori di interfaccia, meno discussioni su “chi è responsabile?”, onboarding più rapido per i team. In ambienti regolamentati facilita anche gli audit: responsabilità chiara, policy coerenti, report uniformi. A livello economico spesso esistono sconti di bundle – ma il vero vantaggio è la riduzione dell’attrito operativo.

In sintesi: la consolidazione degli strumenti può creare efficienza reale – purché la dipendenza venga gestita attivamente.

Il lato oscuro: Lock-in e rischio di concentrazione

Uno stack, un errore – e il problema è sistemico. Un aggiornamento difettoso di un grande fornitore di sicurezza può colpire milioni di endpoint in pochi minuti. Senza soluzioni di emergenza (EDR alternativo, login locale di emergenza, gestione out-of-band) l’operatività si blocca. Anche a livello strategico il lock-in è critico: la roadmap del fornitore diventa la vostra. Prezzi, priorità di sviluppo, fine vita dei prodotti – le conseguenze ricadono su di voi. “Migreremo rapidamente” è spesso un’illusione quando formati dati, playbook e agenti sono proprietari e radicati.

Il costo reale del Multi-Vendor

Più fornitori significano più lavoro di integrazione: normalizzare eventi, armonizzare policy, gestire agenti, rafforzare connettori, coordinare release. Senza un’architettura pulita si crea ciò che gli attaccanti sfruttano: ritardi nella rilevazione, responsabilità poco chiare, allarmi contraddittori. Il multi-vendor può aumentare la resilienza – ma solo se si decide consapevolmente dove la ridondanza è utile (ad esempio identità + e-mail + endpoint) e dove la complessità supera i benefici.

Griglia decisionale operativa

• Criticità per il business: più il caso d’uso è vicino al core di fatturato o produzione, minore deve essere il rischio di concentrazione → tendenza a resilienza multi-vendor mirata.
• Maturità di integrazione: esiste un modello dati unificato, pipeline di telemetria, playbook strutturati? Senza questo il multi-vendor rallenta.
• Costi di uscita attuali: tempo e sforzo per migrare funzioni chiave (dati, agenti, policy). Più sono alti, più il lock-in è pericoloso.
• Capacità operativa: chi costruisce e verifica connettori e correlazioni? Se le risorse sono limitate, il mono-vendor può essere pragmatico – con solide soluzioni di emergenza.
• Regolamentazione e audit: potete dimostrare l’efficacia anche con più strumenti sullo stesso percorso? Se no, meno complessità è meglio.
• Requisiti della supply chain: se clienti critici richiedono formati o tempi specifici, dovete rispettarli indipendentemente dall’architettura scelta.

Standard minimi, indipendentemente dalla scelta

• Obbligo di telemetria: percorso dati coerente (identità, endpoint, rete, applicazioni). Senza normalizzazione unificata, la correlazione è casuale.
• Fonte unica di policy: le regole di sicurezza vivono in una fonte autorevole; le implementazioni per tool derivano da essa.
• Disciplina nei cambiamenti: rollout graduali, rollback definiti, approvazioni documentate. Nessun aggiornamento massivo improvviso.
• Playbook trasversali: azioni della prima ora descritte in modo agnostico rispetto ai tool (isolamento, chiusura sessione, blocco account, comunicazione d’emergenza).
• Monitoraggio del monitoraggio: controlli watchdog per verificare che sensori e agenti funzionino e che gli allarmi vengano realmente escalati.

Piano di uscita: testarlo oggi, non sperarlo domani

Un exit plan non è un documento PDF, ma un processo esercitato. Tre elementi sono essenziali:

1. Portabilità dei dati: esportazioni definite di artefatti chiave (incident, policy, hash, SBOM) in formati aperti.
2. Fallback funzionali: alternative concrete per i tre controlli principali (endpoint, e-mail, identità). Non “potremmo”, ma “abbiamo configurato”.
3. Esercitazioni di caos: scenario trimestrale in cui il prodotto principale è indisponibile. Misurare tempo di visibilità, contenimento e ripristino – con prove documentate.

Se fallite qui, non avete un piano ma una speranza.

Quando il Mono-Vendor ha senso – e quando no

Ha senso quando:

• le risorse operative sono limitate,
• serve una governance uniforme rapidamente,
• i percorsi di uscita sono preparati concretamente,
• e i processi critici sono protetti anche da controlli indipendenti (identità rafforzata, backup immutabili, comunicazione out-of-band).

Non ha senso quando:

• i processi core dipendono da un unico canale di aggiornamento,
• si utilizzano formati proprietari senza possibilità di export,
• mancano ponti di emergenza o non vengono testati.

Cosa i consigli di amministrazione vogliono – e dovrebbero – vedere

• Qual è il nostro reale rischio di concentrazione in minuti di fermo?
• Quali percorsi di emergenza testati esistono? Chi decide e con quale autorizzazione?
• Quanto costerebbe una migrazione oggi – e cosa facciamo per ridurre quel costo?
• Quali metriche dimostrano che l’approccio funziona (time-to-contain, rispetto degli SLO di patch, copertura di autenticazione resistente al phishing, tempo di ripristino con prova di integrità)?

Conclusione

Non esiste una soluzione perfetta. Il mono-vendor riduce l’attrito ma aumenta la dipendenza. Il multi-vendor può aumentare la resilienza ma consuma rapidamente capacità. La chiave è scegliere consapevolmente, misurare la scelta e pagare in anticipo il prezzo dell’alternativa: portabilità dei dati, interoperabilità, esercitazioni di caos e meccanismi di uscita. Chi lo fa può adottare entrambi i modelli – senza illusioni e senza sorprese costose.

FAQ sul post del blog

La verità scomoda: una assicurazione cyber non sostituisce i controlli. Paga solo se gli obblighi definiti sono rispettati e il danno rientra nelle condizioni di polizza. Allo stesso tempo, le domande di underwriting diventano più rigorose, i sublimiti più stretti e le esclusioni più precise. Chi liquida tutto come burocrazia paga due volte: costi cyber più elevati durante l’incidente e una polizza che contribuisce poco nel momento critico. L’obiettivo deve essere integrare polizza e sicurezza IT in modo che i sinistri siano dimostrabili e i tempi di reazione si riducano.

Cosa è tipicamente assicurato – e cosa spesso no

Le polizze raggruppano diversi moduli. Sembra positivo, ma conta la clausola scritta in piccolo. Moduli tipici:

• Forensics e servizi di incident: Analisi esterna, contenimento, comunicazione.
• Interruzione di attività / perdita di profitto: Indennizzo per costi di fermo dopo periodi di carenza definiti.
• Responsabilità / violazioni dei dati: Costi di difesa, notifiche, determinate spese.
• Estorsione: Negoziazione/supporto; pagamento solo entro condizioni rigorose e limiti legali.

Altrettanto importanti sono i limiti. Esclusioni frequenti o condizioni restrittive riguardano, ad esempio, violazioni intenzionali, colpa grave, sistemi obsoleti senza disciplina di patching, violazioni di sanzioni, determinate multe (a seconda del quadro giuridico), nonché danni al di fuori di finestre temporali definite o senza approvazione preventiva dell’assicuratore. In altre parole: senza una pratica verificabile di risk management, molto resta teoria.

Cosa richiedono realmente oggi gli assicuratori

Gli underwriter non chiedono più “se”, ma “quanto bene” i controlli siano applicati nella pratica. Sono attesi, tra l’altro:

• MFA resistente al phishing su accessi amministrativi e critici; autenticazioni legacy disattivate.
• Incident playbook testato con percorsi decisionali chiari (24/7 raggiungibile, utilizzabile out-of-band).
• Backup offline/immutabili, test di ripristino documentati con prova di integrità.
• Patch management con SLO (sistemi esposti a internet in giorni), procedure di eccezione documentate.
• EDR/logging su endpoint/server critici con gestione degli allarmi tracciabile.
• Principi di accesso (least privilege, JIT per privilegi amministrativi), inventari aggiornati (sistemi e identità).
• Standard minimi per la supply chain: evidenze, canali di contatto, drill ad hoc con fornitori critici.

Questi requisiti non sono “nice to have” – sono la condizione di accesso a termini ragionevoli e alla liquidazione del sinistro.

Il punto centrale: prova invece di intenzione

Gli assicuratori liquidano sulla base di prove, non di buone intenzioni. Tre aspetti devono essere solidi:

1) Cronologia dell’incidente in minuti, non in opinioni.
Chi ha visto cosa, quando, deciso cosa, fatto cosa? Timestamp, ticket, log pager, snapshot forensi. Senza una cronologia completa, cala la credibilità – e con essa la probabilità di copertura.

2) Integrità del ripristino.
I backup hanno valore solo se si può dimostrare che sono invariati e funzionano sotto pressione temporale. Protocolli (checksum, durata del ripristino, approvazioni) devono essere archiviati centralmente.

3) Obblighi rispettati
Se la polizza prescrive MFA, termini di notifica o processi di approvazione, “quasi” equivale a “no”. Documentate che i requisiti esistevano prima del danno e sono stati rispettati durante l’incidente.

Errori tipici – e come evitarli

• Prima notifica tardiva: Molte condizioni richiedono una comunicazione tempestiva e strutturata (anche se non tutto è chiaro). Soluzione: notifica iniziale predefinita + elenco contatti, verificati legalmente.
• Pagamenti/decisioni autonome: Pagamento di riscatto, cambio di fornitore forense o PR senza approvazione possono compromettere la copertura. Soluzione: albero decisionale con controllo di approvazione.
• “Abbiamo MFA – tranne…”: Eccezioni su account privilegiati o accessi remoti sono punti di ingresso e motivi di rifiuto. Soluzione: applicare metodi resistenti al phishing senza eccezioni permanenti, limitare nel tempo e compensare.
• Backup senza drill: Nessun timestamp, nessun checksum, nessuna prova di integrità. Soluzione: esercitazione trimestrale di ripristino con tempi documentati.
• Supply chain senza evidenze: “Il nostro fornitore è sicuro” non basta. Soluzione: prove, protocolli di drill, contatto 24/7 – tutto archiviato.

Come integrare pragmaticamente polizza e operatività

Considerate la polizza parte della documentazione operativa. Tre elementi bastano per un impatto concreto:

A) Mappa della polizza nel runbook
Per ogni scenario (ransomware, compromissione e-mail, exploit web app), mezza pagina: termine di notifica, canale di contatto, regole di approvazione, limiti/sublimiti, do’s & don’ts. Questa pagina deve stare nella cartella incident – non solo nell’intranet.

B) Raccolta prove pre-strutturata
Cartelle standard con segnaposto: “Notifica iniziale”, “Log di contenimento”, “Snapshot forensi”, “Approvazioni assicuratore”, “Comunicazione”. Durante l’incidente, i team compilano in tempo reale. Obiettivo: niente lavoro investigativo a posteriori.

C) Allineamento trimestrale con underwriting
Non discutere nel sinistro se si è “abbastanza bravi”. Un breve confronto documentato (copertura MFA, SLO patch, tempi di ripristino, evidenze supply chain) crea chiarezza – e condizioni migliori.

Cosa misurare (e perché conta)

I KPI non sono un fine in sé; influenzano premio, franchigia e potere negoziale:

• Copertura MFA (resistente al phishing) su accessi privilegiati ed esposti esternamente.
• Conformità agli SLO di patch separata per sistemi esposti a internet/interni (incluse eccezioni documentate).
• Time-to-Contain e MTTR per criticità – dimostrabili tramite ticket e log pager.
• Tempo di ripristino & integrità dei due processi più critici, testati almeno annualmente.
• Fitness della supply chain: quota di partner critici con evidenze aggiornate/drill riusciti.
• Tempo di prima notifica ad assicuratore/autorità secondo le condizioni – nessuna stima intuitiva.

Più solidi sono questi numeri, più facile negoziare sublimiti, esclusioni e premi – e più probabile una liquidazione senza attriti.

Conclusione: la protezione nasce prima del danno

Una assicurazione cyber è sensata – come parte del risk management, non come sostituto. Funziona quando i controlli sono applicati, gli obblighi compresi e le prove pronte. Chi integra polizza, processi e tecnologia riduce i costi cyber prima ancora del primo euro di rimborso: decisioni più rapide, interruzioni più brevi, meno conflitti nella liquidazione. Tutto il resto è cosmetica costosa – e sulla cosmetica non si può contare in un incidente reale.

FAQ sul post del blog

Molte organizzazioni valutano in modo errato il proprio rischio ai sensi della NIS-2. Non perché siano disinformate, ma perché si concentrano solo su soglie formali: settore, dimensioni, definizioni legali. Nella realtà, il coinvolgimento nasce in tre modi – e due di essi funzionano senza una notifica formale. Chi lo ignora, in caso di crisi si ritrova senza prove, senza tutela contrattuale della catena di fornitura e senza procedure di segnalazione collaudate.

I tre percorsi di coinvolgimento

1. Direttamente coinvolti: aziende classificate formalmente come “essenziali” o “importanti”. Hanno obblighi espliciti in materia di governance, gestione del rischio, misure tecniche/organizzative e segnalazione degli incidenti.
2. Indirettamente coinvolti: fornitori di servizi e subfornitori che lavorano per clienti direttamente coinvolti. I requisiti vengono trasferiti per via contrattuale: controlli minimi (ad es. MFA resistente al phishing, patch-SLO), diritti di audit e di prova, termini di segnalazione, contatti di emergenza.
3. Fattualmente coinvolti: aziende senza classificazione formale il cui guasto bloccherebbe processi critici dei clienti. Al più tardi durante l’onboarding o la ricertificazione, vengono obbligate ad adottare gli stessi controlli – oppure perdono i contratti.

La differenza è giuridicamente rilevante, ma operativamente secondaria: in tutti e tre i casi occorre dimostrare che la propria sicurezza IT è adeguata, documentata ed efficace.

Perché la dimensione non è il criterio decisivo

Il coinvolgimento reale nasce dalle catene di impatto: se il vostro sistema si ferma e di conseguenza si interrompono produzione, logistica o servizi pubblici di un cliente, non conta il numero di dipendenti, ma il grado di dipendenza. I trigger tipici sono interfacce esposte a Internet, accessi amministrativi ai sistemi dei clienti, trattamento di dati sensibili o responsabilità operativa per piattaforme centrali. In breve: chi abilita o influenza una funzione critica viene valutato – formalmente o contrattualmente.

Pressione indiretta: compliance “dall’alto verso il basso”

I committenti direttamente coinvolti trasferiscono gli obblighi lungo la propria catena di fornitura. Non è un “nice to have”, ma una strategia di sopravvivenza: un punto debole presso il fornitore è un punto debole nel proprio audit. Sono quindi attesi standard minimi chiari – senza nomi di vendor, ma con effetti verificabili:

• Identità prima di tutto: MFA resistente al phishing per ruoli privilegiati, disattivazione dei protocolli legacy deboli.
• Disciplina nelle patch: scadenze vincolanti in base all’esposizione (Internet vs. interno), eccezioni documentate con misure compensative.
• Backup con prova: verifica di integrità e ripristino con tempi misurati.
• Canale di segnalazione & referenti: contatto 24/7, soglie definite, verbale della prima notifica.
• Logging: registri tracciabili degli accessi e delle modifiche critiche – a prova di audit, finalizzati.

Chi è in grado di fornirli supera l’onboarding; chi no, viene escluso dalle shortlist – indipendentemente dalla classificazione formale NIS-2.

Falsi presupposti frequenti – confutati con realismo

• “Siamo troppo piccoli.” – Finché un grande cliente non classifica la vostra piattaforma come critica. Da quel momento valgono subito le sue regole.
• “Un certificato basta.” – No. I certificati aiutano, ma non sostituiscono processi concreti, audit e prove.
• “Segnaliamo più tardi, quando tutto è chiaro.” – Gli obblighi di segnalazione richiedono notifiche iniziali tempestive e strutturate, con aggiornamenti.
• “Se ne occupa l’IT.” – La NIS-2 riguarda le responsabilità della direzione. Budget, rischi ed escalation sono temi di governance.

Cosa è sensato fare ora (senza attivismo)

Iniziate dove il fallimento è più costoso e create prove invece di dichiarazioni d’intento:

• Mappa dei rischi & responsabilità: quali servizi sono critici per i clienti? Chi decide in caso di incidente? Per iscritto, approvato, reperibile.
• Runbook dei controlli: una pagina per misura: obiettivo, trigger, passaggi, responsabile, prova (screenshot, log, ticket).
• Modello a livelli della catena di fornitura: desk review per tutti, prove remote per “alto”, test mirati per “critico”. Scadenze ed escalation regolati contrattualmente.
• Comunicazione degli incidenti: modelli e matrici di contatto (interno/esterno), soglie, canali out-of-band – provati una volta, non solo descritti.
• Disciplina della prova: “Non documentato” in audit equivale a “non avvenuto”. Raccogliere, versionare, archiviare centralmente.

KPI che reggono in caso di verifica

• Copertura MFA (resistente al phishing) per ruoli privilegiati.
• Conformità Patch-SLO separata per esposto a Internet/interno.
• Tempo di ripristino & verifica di integrità per due processi aziendali critici.
• Tempo fino alla prima notifica e completezza delle prime informazioni sull’incidente.
• Fitness della catena di fornitura: quota di partner critici con prove aggiornate e contatto 24/7 funzionante.

Questi KPI non sono un fine in sé; ogni deviazione richiede una conseguenza definita (escalation, change-freeze, verifica aggiuntiva). Solo così la governance diventa efficace.

Conclusione

La domanda “Siamo formalmente NIS-2?” è importante – ma non decisiva. Ciò che conta è poter dimostrare che i vostri controlli sono adeguati, funzionano e sono comprovabili in modo solido in caso di emergenza. Direttamente, indirettamente o fattualmente coinvolti: conta il risultato. Chi oggi chiarisce le responsabilità, redige runbook, tutela contrattualmente la catena di fornitura e raccoglie prove non solo supera il prossimo audit – ma riduce concretamente il rischio reale di interruzioni e costi conseguenti.

FAQ sul post del blog

La discussione su NIS-2 ruota spesso attorno a regolamenti di dettaglio e questioni interpretative. Comprensibile – ma pericoloso. Il punto centrale è già chiaro: le aziende di importanza essenziale per l’economia e la società devono professionalizzare in modo dimostrabile la propria sicurezza IT e la governance. Chi oggi sceglie di “aspettare e vedere” rischia esattamente ciò che NIS-2 intende prevenire: interruzioni più lunghe, reazioni a catena nella catena di fornitura e responsabilità del management senza prove solide di misure adeguate.

L’essenza di NIS-2 in cinque punti

• Responsabilità della direzione: Direzione/Consiglio di amministrazione sono esplicitamente tenuti a conoscere i rischi, approvare le misure e verificarne l’efficacia.
• Controlli basati sul rischio: Non una religione delle checklist, ma misure adeguate e documentate su identità, endpoint, reti, applicazioni e dati.
• Obblighi di notifica & Incident Reporting: Gli incidenti gravi devono essere notificati nei termini previsti e in modo qualificato – senza panico, ma con fatti.
• Sicurezza della supply chain: Le terze parti non sono “esterne”, ma parte della vostra superficie di attacco. Controlli minimi e prove vengono richiesti contrattualmente.
• Applicazione & sanzioni: La “sicurezza su carta” non basta. Mancanza di governance e processi inefficaci sono sanzionabili – indipendentemente dalle buone intenzioni.

Chi è coinvolto – direttamente, indirettamente, tramite contratti

Molte aziende rientrano direttamente nel campo di applicazione; altre subiscono NIS-2 attraverso i clienti: grandi committenti e operatori richiedono prove e diritti di audit, anche se formalmente non siete “in ambito”. In modo realistico esistono tre categorie:

1. Direttamente coinvolti (entità essenziali/importanti): obblighi formali e contatto con le autorità.
2. Indirettamente coinvolti (fornitori/servizi critici): obblighi contrattuali di prova, audit, standard minimi.
3. Di fatto coinvolti: nessuna classificazione formale, ma dipendenza da clienti che trasferiscono i requisiti NIS-2.

Errori comuni – e la risposta realistica

• “Servono prima le linee guida definitive.” – Falso. I controlli attesi sono best practice da anni: MFA resistente al phishing, patch SLO, segmentazione, backup con verifica d’integrità, processo di Incident Reporting.
• “Certificato = fatto.” – No. I certificati aiutano, ma non sostituiscono processi operativi o controlli sulla supply chain.
• “Ci pensa l’IT.” – Solo in parte. NIS-2 è governance: decisioni di rischio, budget, contratti, escalation – responsabilità del management.
• “Siamo troppo piccoli/irrilevanti.” – Finché un’interruzione non colpisce un cliente molto rilevante. Allora valgono le sue regole – immediatamente.

Dal testo normativo alla pratica – cosa significa “adeguato”

Iniziate dove il fallimento costa di più: identità, superfici di attacco esterne e ripristino. “Adeguato” significa: documentato, ripetibile, verificato.

Elementi fondamentali che contano:

• Prima le identità: MFA resistente al phishing (es. Passkeys/FIDO2) per ruoli critici, privilegi just-in-time, disattivazione dei protocolli legacy deboli.
• Patch SLO invece di “patchiamo regolarmente”: vulnerabilità critiche esposte su Internet risolte in giorni, interne con scadenze chiare; escalation automatizzata in caso di ritardo.
• Segmentazione & hardening: separazione delle zone critiche, workstation amministrative rafforzate, blocco predefinito degli strumenti di scripting rischiosi.
• Backup con prova: offline/immutabili, test di ripristino cronometrati con verifica d’integrità – documentati e ripetibili.
• Percorso di notifica e comunicazione: Incident Reporting esercitato con ruoli, scadenze, canali di contatto (interni/esterni) e linee guida legali.
• Protezione contrattuale della supply chain: controlli minimi (MFA, patch SLO, logging), obblighi di test, scadenze di notifica, diritti di audit.

Piano minimo senza drammi

Non tutto insieme, ma con coerenza e con prove.

1. Mappa dei rischi & responsabilità (delibera del management):
   Quali processi sono critici? Quali vettori di attacco sono realistici? Chi decide in caso di deviazioni? Documentare e approvare formalmente.

2. Inserire i controlli nel manuale operativo (non solo nelle slide):
   Per ogni controllo (es. MFA, patch SLO, test di ripristino) un runbook di una pagina: obiettivo, trigger, passi, responsabile, prove. Breve ma operativo.

3. Raccogliere e versionare le prove:
   Ticket, log, screenshot, registri dei test. Senza prova, non è successo. Tutto centralizzato, verificabile, reperibile.

4. Supply chain a livelli:
   Desk review per tutti, audit remoto per “alto”, test mirati per “critico”. Prove mancanti ⇒ scadenza, escalation, se necessario limitazione dell’accesso.

Cosa viene misurato – e come

I KPI non sostituiscono i controlli, ma rendono visibile il progresso – e misurabili le lacune. Pochi indicatori chiari con conseguenze definite:

• Copertura MFA (resistente al phishing) per ruoli critici.
• Conformità ai Patch SLO in base all’esposizione (Internet vs. interno).
• Tempo di ripristino & integrità per i due processi aziendali più importanti.
• Maturità degli incidenti: tempo alla prima valutazione, tempo alla notifica, completezza della notifica iniziale.
• Solidità della supply chain: percentuale di partner critici con prove/test superati e canale di contatto 24/7 funzionante.

Importante: Ogni deviazione richiede una conseguenza definita (es. escalation, blocco delle modifiche, revisione aggiuntiva). Reporting senza azione è solo burocrazia.

Consigli pratici per dirigenti scettici

• Chiedete prove, non intenzioni. “Mostratemi l’ultimo protocollo di ripristino con timestamp.”
• Priorità dove il tempo è denaro. Un ripristino stabile riduce i costi di inattività – e convince gli assicuratori.
• Collegate il budget all’impatto. Meno strumenti, più processi solidi.
• Rendetelo auditabile. Ciò che non è reperibile, di fatto non esiste – soprattutto sotto NIS-2.

Conclusione: Agire vale più delle scuse

NIS-2 non è un fine in sé, ma un catalizzatore per una governance solida. Chi oggi mette in ordine processi, prove e catena di fornitura ottiene un doppio vantaggio: meno rischio quotidiano e meno stress quando conta davvero. Aspettare la chiarezza perfetta è una strategia – ma non una buona. I requisiti sono noti, il percorso è realizzabile. Iniziate ora – e documentate di averlo fatto."

FAQ sul post del blog

Chi crede ancora che una password più "qualcosa con push" sia sufficiente, non ha compreso la realtà degli attacchi. Gli aggressori non rubano più solo le password, ma intercettano le sessioni, sfruttano dispositivi deboli, eludono i codici SMS e usano catene chiamate Adversary-in-the-Middle per rubare i login in tempo reale. MFA non è quindi un "nice-to-have", ma il minimo per aumentare il costo per attacco. Ma: MFA non è uguale a MFA. Tra i metodi vulnerabili al phishing (ad esempio codici usa e getta, push facilmente confermabili) e i metodi sicuri contro il phishing (ad esempio Passkeys/FIDO2 con binding del dispositivo) c'è un abisso di sicurezza. Risparmiare nel posto sbagliato compra una falsa sensazione di sicurezza – e si paga il doppio in caso di incidente: in tempo e nei costi di fermo.

Biometria senza romanticismo

Biometria funziona perché lega il fattore "possesso" a un dispositivo specifico e registrato, mentre utilizza contemporaneamente il fattore "inerenza" (ad esempio dito, viso) per rendere il sblocco locale sicuro e veloce. Ma la biometria non è un incantesimo. Ciò che conta è dove avviene la verifica e come appare la prova crittografica. Se lo sblocco avviene localmente nell'elemento sicuro del dispositivo e la chiave privata non lascia mai i suoi confini, si ottiene una protezione qualitativamente diversa rispetto alle soluzioni che valutano i dati biometrici sul lato server o inviano semplici approvazioni tramite app. Se implementata correttamente, la biometria porta velocità per gli utenti e integrità per l'organizzazione: meno reset delle password, meno superficie di ingegneria sociale, meno frizione nelle operazioni quotidiane. Se implementata male, crea nuovi rischi: registrazioni dubbie, dispositivi insicuri, mancanza di politiche per i casi di smarrimento e nessun fallback adeguato quando i sensori falliscono.

Perché MFA sicura contro il phishing fa la differenza

I metodi vulnerabili al phishing possono essere ingannati perché la persona nella catena non può verificare l'autenticità del destinatario. Un portale di login falsificato, un codice usa e getta inoltrato – e l'aggressore è nella sessione. MFA sicura contro il phishing lega il login crittograficamente al sito o all'app legittimi. Questo significa che anche se un utente "conferma" volontariamente, la conferma non può essere reindirizzata a un altro dominio. Zero Trust diventa qui tangibile: non credere, verificare; non fidarsi globalmente, ma legare al contesto – identità, dispositivo, applicazione. In pratica, questo si manifesta in attacchi con molto poco spazio di negoziazione: senza la chiave privata corretta e il destinatario giusto, la porta rimane chiusa. Questa è la differenza tra "avevamo MFA" e "l'attacco è fallito tecnicamente".

Le domande scomode sulla propria implementazione

Chi è serio in questo campo non lancia semplicemente parole di moda, ma risponde a qualche domanda scomoda: In quali punti accettiamo ancora codici SMS o link via email – e perché? Dove permettiamo conferme push senza un legame contestuale? Quali ruoli privilegiati (Admin, Finance, HR, Developers) sono già passati a MFA sicura contro il phishing, e quali no? Come gestiamo il "Legacy" – i servizi che supportano solo l'autenticazione di base? E cosa succede se i dispositivi vengono smarriti: il processo di recupero è documentato, verificabile e veloce, o improvvisiamo? Queste risposte determinano il vero rischio cibernetico, non il numero di licenze.

Guida pratica senza hype

Il percorso è chiaro e privo di religioni. Primo: inizia da dove una violazione farebbe più male – nei ruoli privilegiati e negli accessi esposti pubblicamente. Secondo: sostituisci i fattori deboli con quelli forti. MFA con Passkeys o chiavi di sicurezza FIDO2 sui dispositivi aziendali riduce drasticamente il successo del phishing perché il login e la pagina di destinazione sono legati crittograficamente. Terzo: impone una buona igiene delle sessioni. Un login sicuro è inutile se un token rubato vive per settimane. Quindi imposta durate brevi per le sessioni, re-challenge in caso di rischio (luogo insolito, nuovo dispositivo, operazione sensibile) e meccanismi di revoca chiari. Quarto: regola i fallback. Nessun metodo è perfetto. Il percorso sicuro di emergenza deve essere raro, breve e rigoroso – limitato nel tempo, approvato in modo chiaro e revocato immediatamente dopo. Quinto: non dimenticare le macchine. Gli account di servizio, i token CI/CD e i dispositivi IoT necessitano anche di credenziali di login forti e a breve durata, nonché di connessioni basate su mTLS, altrimenti la porta sul retro rimane aperta.

Ciò che può essere misurato può essere migliorato

Le metriche non sono un fine in sé, ma senza numeri tutto rimane una sensazione. Metriche utili includono la copertura MFA sicura contro il phishing per i ruoli critici, la durata media delle sessioni nelle applicazioni sensibili, il tempo dal smarrimento del dispositivo fino alla revoca completa di tutti gli accessi, il tasso di tentativi di login bloccati tramite binding del dominio e la percentuale di azioni privilegiate che richiedono una verifica aggiuntiva. Ciò che conta è la coerenza: una deviazione non deve scatenare un "stiamo osservando", ma una misura predefinita – bloccare, ruotare, perfezionare.

Conclusione: Velocità più integrità

La migliore sicurezza IT è quella che viene usata – quotidianamente, senza frizione, senza scuse. Biometria e MFA sicura contro il phishing forniscono proprio questo, se implementate correttamente: login rapidi, forte legame con obiettivi legittimi, chiari percorsi di revoca. Chi passa a questo approccio in modo coerente oggi riduce la superficie di attacco, abbrevia il tempo di risposta e riduce i costi nascosti che altrimenti si dissiperebbero in helpdesk, forense e tempi di inattività. Tutto il resto è solo cosmetica – e la cosmetica non ha mai fermato un attacco.

Valutazione onesta: in molti ambienti le identità macchina sono più pericolose degli account utente. Account di servizio con privilegi permanenti, segreti hard-coded, token eterni e telemetria assente sono punti di ingresso perfetti – invisibili, comodi, spesso dichiarati “tecnicamente necessari”. Chi prende sul serio Zero Trust deve verificare non solo le persone, ma anche workload, servizi e dispositivi. La strada è chiara: inventario coerente, privilegi minimi, credenziali a vita breve, rigorosa secrets rotation e mTLS applicato – dimostrato con KPI, non con dichiarazioni di intenti.

Perché le identità non umane sono sottovalutate

• Invisibilità nella quotidianità: non c’è un dipendente che “clicca male”. Per questo gli account di servizio raramente rientrano nei programmi di awareness – e sfuggono a ogni controllo.
• Comodità vs. sicurezza: privilegi permanenti e password statiche “semplicemente funzionano”. Finché non vengono copiati, trapelati o recuperati dai repo.
• Effetto di scala: un build token o un certificato IoT compromesso apre intere flotte – movimento laterale senza allarmi.
• Assenza di proprietà: chi “possiede” l’account? Dev? Ops? Business unit? Senza un owner chiaro, tutto resta in sospeso.

Debolezze tipiche

• Segreti hard-coded in codice, variabili CI/CD, template IaC → secret scanning obbligatorio, divieto di testo in chiaro, secrets store centrale, secrets rotation ≤ 30 giorni.
• Token/certificati di lunga durata → identità di workload firmate e a vita breve; rinnovo automatico, revoca in caso di anomalie.
• Account di servizio con troppi privilegi → scope rigorosi, least privilege, accesso basato su tempo o evento; niente account condivisi.
• Sicurezza di trasporto assente tra servizi → mTLS obbligatorio (verifica reciproca) con rotazione automatica dei certificati.
• Nessun inventario/nessuna telemetria → registro centrale delle identità macchina, log di utilizzo ed emissione, allarmi su pattern “impossibili”.

Principi per un’identità macchina resiliente

1. Esistenza esplicita: ogni identità non umana è registrata (owner, scopo, scope, data di scadenza).
2. Vita breve prima della comodità: token/certificati vivono ore–giorni, non mesi. La rotazione è obbligo, non obiettivo di progetto.
3. La fiducia è dimostrabile: mTLS + firme + attestazioni; niente “crediamo che …”.
4. Least privilege by design: i diritti sono specifici, ben separati e scadono automaticamente.
5. Rilevabilità: ogni utilizzo lascia correlazione (identità × destinazione × momento × fonte) – altrimenti niente impiego.

Piano di 90 giorni

Giorno 0–15 – Visibilità & criteri di stop

• Inventario completo di tutti gli account di servizio, token, certificati, API key (incl. owner, scope, scadenza).
• Policy: divieto di segreti hard-coded; durate minime; mTLS obbligatorio per percorsi service-to-service interni.
• Stabilire KPI di baseline (vedi sotto).

Giorno 16–45 – Rafforzamento & vita breve

• Introdurre/standardizzare un secrets store centrale; avviare secrets rotation automatizzata.
• Identità di workload a vita breve (credenziali firmate e a tempo) per i 3 servizi più critici.
• Attivare mTLS sui percorsi critici (verifica reciproca, auto-renew).

Giorno 46–75 – Automatizzare & cancellare

• Gate CI/CD: build fallisce con segreti hard-coded, certificati scaduti, scope eccessivi.
• Dieta dei privilegi: ridurre account di servizio sovraprivilegiati; eliminare identità inutilizzate.
• Rilevamento anomalie: uso insolito (tempo, fonte, volume) → auto-revoke + pager.

Giorno 76–90 – Consolidare & dimostrare

• Fissare cicli di rotazione (≤ 30 giorni token, ≤ 90 giorni certificati – secondo il rischio).
• Testare il processo break-glass per identità macchina (emettere, usare, revocare, auditare).
• Steering trimestrale con KPI; legare il budget all’impatto (es. “pinned rate”, “rotation rate”).

KPI che rendono misurabile la maturità

• Copertura inventario: % di identità macchina registrate con owner, scope, scadenza.
• Tasso di rotazione: % di segreti/certificati ruotati entro i cicli target.
• Punteggio di vita breve: durata mediana di token/certificati per criticità.
• Copertura mTLS: % di percorsi critici con mTLS applicato (incl. verifica reciproca).
• Igiene degli scope: quota di account di servizio con privilegi minimi (niente wildcard, niente admin-all).
• Leak/find rate: numero di segreti trovati al mese e tempo fino a revoca/rotazione.

Anti-pattern

• “Tecnicamente necessario” come scusa per privilegi permanenti – no. Dimostrare la necessità, limitarla, compensare il rischio.
• “mTLS più tardi” – più tardi significa mai. Senza verifica reciproca, la rete “interna” è un campo aperto.
• “Solo ambiente dev” – gli attaccanti amano il dev: modelli dati reali, chiavi reali, poco monitoring.
• “Non logghiamo – privacy” – la privacy non vieta il logging. Registrare in modo sobrio ma verificabile.

Checklist pratica

• Imporre secret scanning in tutti i repo/pipeline CI; fail della build in caso di ritrovamenti.
• Secrets store centrale con secrets rotation e prestiti a vita breve (just-in-time per i servizi).
• mTLS obbligatorio per servizi interni; emissione/rinnovo automatico dei certificati.
• Review dei permessi per account di servizio: minimizzare scope, impostare scadenze, assegnare owner.
• Obbligo di telemetria: correlare l’uso per identità; auto-revoke in caso di anomalie.
• Disciplina di cancellazione: rimuovere identità macchina inutilizzate – cadenza mensile.

Conclusione: l’identità è più dell’umano

Chi rafforza solo gli utenti costruisce una porta d’ingresso d’acciaio – e lascia aperta la porta laterale. Le identità macchina sono oggi la via d’attacco numero uno realistica: silenziose, scalabili, spesso senza allarmi. Con credenziali a vita breve, scope rigorosi, mTLS obbligatorio, secrets rotation praticata e KPI solidi, la sicurezza passa dall’intuizione al controllo. Tutto il resto è speranza costosa.

FAQ sul post del blog

Management Summary

L’era dei perimetri di rete è finita. Gli attacchi partono da email, browser, accessi remoti, identità e servizi che non vedono mai la vostra LAN. Chi continua a romanticizzare i packet filter perde in velocità e visibilità. La strada da seguire non è spettacolare: Zero Trust come principio operativo („verificare invece di fidarsi“), MFA forte, Least Privilege applicato con coerenza, autorizzazioni di breve durata ( JIT-Access ) e telemetria che collega le anomalie all’identità. Risultato: rilevamento più rapido, meno movimenti laterali, minori costi di fermo.

Perché il perimetro classico fallisce

Realtà ibrida: SaaS, lavoro remoto, accessi dei partner – l’“interno” di fatto non esiste più.
Furto di sessione invece di tentativi sulle password: le moderne catene di phishing puntano a token e cookie, non solo alle password.
Le identità macchina esplodono: service ID, token CI/CD, IoT – spesso con diritti permanenti, raramente monitorati.
Velocità del cambiamento: nuove app e integrazioni nascono più velocemente di quanto le regole firewall possano adattarsi.

Conclusione: il controllo deve spostarsi sull’identità – umana e macchina.

Zero Trust in cinque pilastri

Identità – Chi vuole cosa? Persone, servizi, dispositivi. MFA forte, processi di recupero robusti, policy di sessione rigide (re-challenge, binding al dispositivo).
Dispositivo – Da cosa avviene l’accesso? Stato di compliance, livello di patch, segnali di rischio. Dispositivi non conformi: modalità limitata.
Rete – Solo livello di trasporto e micro-segmentazione; nessuna zona di fiducia implicita.
Workload/Applicazione – Controllo davanti a ogni flusso sensibile (AuthN/Z, rate limit, igiene dei segreti).
Dati – Classificazione, permessi minimi, autorizzazioni dipendenti dal contesto, logging.

Principi: verifica esplicita, Least Privilege, assumere la compromissione, telemetry-first.

Piano di 90 giorni: dall’intenzione al controllo reale

Giorni 0–15 – Visione della situazione e decisioni difficili
Mappatura dei ruoli: admin, finance, sviluppatori, account di terze parti. Cosa è critico per il business?
Inventario dell’autenticazione: dove manca una MFA resistente al phishing? Quali flussi legacy sono ancora attivi (per esempio IMAP/POP, Basic/NTLM)?
Bozza di policy: le decisioni di accesso si baseranno su identità più stato del dispositivo più contesto.

Giorni 16–45 – Rafforzamento e disattivazioni
MFA per tutti i ruoli critici; disattivare i protocolli legacy; re-challenge della sessione in caso di rischio.
Pilotare il JIT-Access: diritti admin temporanei con ticket o approvazione a quattro occhi; durata massima in minuti o ore.
Rotazione dei segreti: passare gli account di servizio a token di breve durata; eliminare le password hard-coded.

Giorni 46–75 – Automatizzare e ottenere visibilità
Trasformare le decisioni di accesso in policy (policy engine): identità × dispositivo × posizione × sensibilità.
Rilevamento anomalie basato sull’identità: viaggi insoliti, login impossibili, deviazioni dal profilo di ruolo con contenimento automatico (chiusura sessione, step-up authentication).
Testare il processo break-glass: account di emergenza, uso tracciato, rotazione immediata.

Giorni 76–90 – Consolidare e misurare
Pulizia dei ruoli (RBAC/ABAC): chiudere account orfani, ridurre gruppi con troppi privilegi.
Percorso sviluppatori: vietare segreti nel codice, imporre firme, token CI/CD di breve durata.
Steering trimestrale: fissare obiettivi (per esempio 100 % MFA per ruoli critici, 90 % JIT-Access per azioni admin).

KPI che guidano davvero le decisioni

Copertura MFA (resistente al phishing): quota di ruoli critici con fattori forti.
Quota JIT: percentuale di azioni privilegiate approvate su base temporale.
Tasso di privilegi in eccesso: account con diritti oltre il profilo di ruolo.
Mean Time to Revoke: tempo tra offboarding o cambio ruolo e rimozione dei diritti.
Anomalie di sessione: rilevate, contenute automaticamente, confermate manualmente – in base alla criticità.
Identità macchina: quota di token di breve durata, intervalli di rotazione, ritrovamenti di segreti al mese.

Anti-pattern

„Abbiamo la MFA“ – ma con push spamming e fallback legacy consentiti. Risultato: falsa sicurezza.
„Una volta admin, per sempre admin“ – i diritti permanenti favoriscono il movimento laterale. Least Privilege non è un poster, è rimozione di diritti.
„Account di servizio dimenticati“ – password statiche, mai ruotate, onnipotenti. È una backdoor silenziosa.
„La rete è abbastanza sicura“ – finché una scheda del browser con un cookie rubato diventa prova di admin.
„Backup = tranquillità“ – senza rafforzare le identità, gli attaccanti tornano dopo il ripristino.

Checklist pratica (attuabile subito)

MFA resistente al phishing (passkey/FIDO2) per ruoli admin, finance, HR e sviluppatori.
Least Privilege: revisione dei ruoli, rimozione dei diritti non necessari, approvazioni tra pari.
JIT-Access: limiti di tempo, collegamento a ticket, logging completo, revoca automatica.
Account macchina: mTLS, token di breve durata, secrets scanning nel CI, rotazione entro 30 giorni o meno.
Sicurezza delle sessioni: binding del token a dispositivo o browser, re-challenge in caso di rischio, logout forzato dopo anomalie.
Offboarding in ore, non giorni; cascata automatica dei diritti fino ai sottosistemi.

Conclusione: prima l’identità – tutto il resto dopo

Chi prende sul serio la sicurezza IT costruisce il controllo attorno alle identità e ai loro contesti. Zero Trust non è un progetto ma uno standard operativo: MFA forte, Least Privilege rigoroso, JIT-Access applicato, telemetria solida. È meno appariscente di nuovi strumenti – ma riduce sensibilmente rischio, MTTR e costi. Chi inizia oggi e applica con coerenza i passi dei 90 giorni ottiene in pochi trimestri più impatto di qualsiasi ulteriore acquisto „best-of-breed“.

Chi non verifica i propri partner esternalizza i rischi di terze parti—direttamente nel proprio bilancio. La strada da seguire non è un progetto mostruoso, ma un modello a fasi per gli audit ben progettato: iniziare in piccolo, approfondire in base al rischio, tradurre i risultati in KPI e intervenire in modo coerente. L’obiettivo non è la carta, ma l’efficacia: controlli verificati, canali di contatto chiariti, percorsi di emergenza testati. Tutto il resto è auto-rassicurazione.

Perché molte verifiche della supply chain falliscono

• Questionari senza prove: belle risposte, zero evidenze.
• Profondità di audit uniforme: il cloud provider trattato come il servizio di manutenzione locale—insensato.
• Nessuna logica di escalation: i finding ristagnano, le scadenze non hanno forza.
• Nessun collegamento alla supply-chain security operativa: nessun percorso di logging, nessun contatto 24/7, nessuna esperienza di drill.
  In breve: formalità invece di due diligence. Questo non garantisce risultati.

Il modello a fasi: Tre livelli di verifica, trigger chiari

Fase 1 – Desk Review (tutti i partner)
Audit leggeri con evidenze: estratti di policy, certificati, prove di processo, contatti nominativi 24/7. Trigger: nuovo fornitore, refresh annuale, modifiche contrattuali.

Fase 2 – Remote Audit (servizi ad alto rischio)
Screen sharing/interviste, controlli a campione nei sistemi, prove dei controlli (es. schermate MFA, esportazioni di log). Trigger: esposizione internet, accesso a dati sensibili, storico incidenti.

Fase 3 – Onsite/Targeted Test (percorsi critici)
Verifiche in loco o test tecnici mirati (es. flussi di autenticazione, restore drill). Trigger: rilevanza per processi core, accessi admin, collegamento alle vostre operazioni di emergenza.

Contenuti obbligatori per fase (brevi ma sufficienti)

Fase 1 – Obbligatori

• Dati aziendali, responsabili, contatto 24/7 (emergenza).
• Controlli minimi: MFA resistente al phishing per admin, SLO di patching, strategia di backup, ruoli/permessi.
• Evidenze di compliance (se disponibili) + validità.
• Percorso di segnalazione incidenti: tempi, modalità, referenti.
• Percorso di logging: cosa viene registrato, per quanto tempo, come viene condiviso.

Fase 2 – Obbligatori

• Prove live: MFA su accessi critici, hardening delle sessioni, processo di offboarding.
• Vulnerability management: cicli, rispetto degli SLO, ticket di esempio.
• Backup/restore: log più recenti, prova di integrità.
• Processo di change/deployment: principio dei quattro occhi, tracce di approvazione.
• Evidenze di drill: contatti di emergenza del cliente coinvolti? Sì/No + data.

Fase 3 – Obbligatori

• Test mirati: catena di autenticazione, rate limits, accesso di emergenza, comunicazione out-of-band.
• Restore drill sotto pressione temporale, tempi documentati.
• Subfornitori del fornitore (N-tier): chi accede a cosa e dove? Evidenze.

KPI che contano (e impongono governance)

• Tasso di copertura dei partner verificati (Fase 1/2/3) per classe di rischio.
• Conformità agli SLO per i finding: % chiusi nei tempi, tempo medio di chiusura.
• Tasso di drill: quota di partner critici con drill 24/7 e restore superati ≤ X mesi.
• Tempo di segnalazione incidenti: dal primo indicatore alla notifica al partner.
• Escalation hit rate: quanto spesso vengono applicati i livelli di escalation (prova di vera governance).

Senza review trimestrali ed escalation rigorose, i KPI sono decorazione.

Piano di 90 giorni per audit di supply chain efficaci

Giorno 0–15 – Inventario e classi di rischio

• Elenco completo dei partner con accessi dati, esposizione, diritti admin.
• Classi di rischio (basso/medio/alto/critico) basate sui vostri processi aziendali.
• Mappatura delle fasi: chi rientra in Fase 1/2/3—con motivazione.

Giorno 16–45 – Template ed evidenze

• Tre questionari snelli (S1/S2/S3) con evidenze obbligatorie, niente romanzi in testo libero.
• Definire evidenze standard (screen, ID ticket, log, registri di drill).
• Ancore contrattuali: obblighi di evidenza e drill, tempi di notifica, diritti di due diligence.

Giorno 46–75 – Esecuzione ed escalation

• Rollout Fase 1 al 100% dei partner attivi.
• Fase 2 per tutti gli “alti”: pianificare sessioni remote, verificare evidenze.
• Logica di escalation rigorosa: scadenza → promemoria → coinvolgimento management → restrizione temporanea degli accessi.

Giorno 76–90 – Drill e consolidamento

• Fase 3 per i “critici”: un restore drill + test dei contatti di emergenza sotto carico.
• Review KPI vs. baseline, adeguare misure, roadmap per il prossimo trimestre.
• Integrare le lesson learned nei template (eliminare/rafforzare domande).

Governance efficace—senza overhead

• Un owner degli audit, un sistema: tutte le evidenze in un backlog ticket/GRC, prioritizzato per impatto business.
• “No evidence, no pass”: ogni risposta richiede prova—altrimenti resta aperta.
• Visione N-tier: i subfornitori critici devono essere nella vostra visibilità, altrimenti la supply chain resta cieca.
• Testare il percorso di emergenza: una volta l’anno insieme—non solo in un PDF.

Conclusione: efficacia invece di carta

Gli audit snelli e basati sul rischio non sono un fine. Costringono i partner a mostrare i controlli—e voi ad applicare conseguenze. Chi pensa la supply-chain security così riduce la reale superficie d’attacco, migliora i tempi di risposta e rende misurabili i rischi di terze parti. In breve: meno promesse, più prove. Tutto il resto è cosmetica costosa.

Gli attacchi tramite dipendenze non sono più un tema marginale, ma la scorciatoia più comoda verso il cuore dell’IT moderna. La verità: la maggior parte degli ambienti conosce la propria catena di fornitura software solo in modo frammentario. I gestori di pacchetti risolvono transitivamente, il CI/CD distribuisce diligentemente, e nessuno si accorge quando un componente viene avvelenato. Chi vuole davvero ridurre il rischio ha bisogno di tre cose: SBOM completa, politiche rigorose di Supply-Chain-Security e un’operatività che applichi aggiornamenti e blocklist con coerenza – senza discuterli.

Perché le catene di fornitura sono così vulnerabili

• Le dipendenze esplodono: un singolo servizio porta rapidamente con sé centinaia di pacchetti transitivi.
• Fiducia implicita: registri e mirror vengono trattati silenziosamente come “ok”.
• Vettori di attacco: typosquatting, dependency confusion, account di maintainer compromessi, script post-install malevoli, build-image avvelenate, CI-secrets trapelati.
• Mancanza di visibilità: senza SBOM e prove di provenienza nessuno sa cosa gira davvero – e dove applicare le patch.

In breve: il problema non è il singolo “pacchetto cattivo”, ma la mancanza di prove lungo la catena.

Controlli minimi che funzionano subito

1. SBOM come documento operativo, non come PDF decorativo

   • Generate SBOM per servizio e per build (non solo per repo).
   • Versionatele nell’artifact store, collegatele a ticket/modifiche.
   • Riferimenti a licenze, stato CVE, criticità e owner.

2. Igiene dei repository & policy sui pacchetti

   • Allowlist di registri, namespace e firme.
   • Version-pinning rigoroso; niente “latest”.
   • Blocklist per librerie dannose note, fail-build automatico.
   • Secret-scanning e firme dei commit in tutti i repo.

3. Provenance & integrità

   • Prove di “chi ha costruito cosa quando” (es. attestazioni sugli artefatti).
   • Build riproducibili, hash immutabili degli artefatti, approvazioni a quattro occhi in CI/CD.
   • Diritti minimi per i build-token, durate brevi, rotazione obbligatoria.

4. Operatività di update invece di speranza negli update

   • Dependency-PR automatizzate con labeling del rischio.
   • Fix-SLO dopo esposizione (Internet vs. interno) e criticità.
   • Percorso “break-glass” per rollback rapidi con fasi canary.

KPI che rendono visibile la maturità

• Copertura SBOM: % di servizi con SBOM aggiornata (precisa per build, ≤7 giorni).
• Time-to-Upgrade: tempo mediano fino alla patch per librerie critiche (esposte a Internet vs. interne).
• Pinned-Rate: quota di dipendenze rigidamente pinnate senza wildcard.
• Quota di Provenance: % di artefatti con origine firmata e prova hash.
• Hit di Blocklist: numero di build bloccate dalla policy – sì, qui i “fallimenti” sono un buon segno.
• Secret-Leaks: ritrovamenti al mese, tempo fino alla rotazione.

Queste metriche devono stare nello stesso steering di MTTD/MTTR – altrimenti la sicurezza della supply chain resta folklore.

Piano a 90 giorni (pragmatico, senza vendor lock-in)

Giorno 0–15 – Inventario & policy

• Inventariare i servizi, segnare i percorsi critici (Auth, Payment, Admin).
• Definire la policy dei pacchetti: registri consentiti, namespace, firme, regole di pinning, blocklist.
• Verificare i CI/CD-secrets: ridurre i diritti, accorciare le durate, pianificare la rotazione.

Giorno 16–45 – Visibilità & criteri di stop

• Attivare la generazione di SBOM integrata nel build e salvarla nell’artifact store.
• Rendere obbligatori attestati di provenance e hash degli artefatti; build interrotta se mancanti.
• Attivare secret-scanning e firme dei commit; fail-build in caso di ritrovamenti/unsigned.

Giorno 46–75 – Operatività di fix & esercitazione

• Attivare update-PR automatiche; inserire labeling del rischio (criticità/exposure).
• Applicare tecnicamente i Fix-SLO (es. auto-escalation in caso di ritardi).
• Drill: ritrovamento simulato di pacchetto malevolo → blocco, rollback, post-mortem con tempi.

Giorno 76–90 – Ancorare & contratti

• Confrontare i KPI con la baseline, rafforzare le misure.
• Requisiti minimi contrattuali nella Supply-Chain-Security: obbligo di consegna SBOM, contatto di emergenza 24/7, tempi di notifica, partecipazione ai drill.
• Riportare le lessons learned in policy e pipeline.

Governance senza teatro

• Un unico source of truth: SBOM, policy-files, attestati, blocklist – centrali, versionati, a prova di revisione.
• “No evidence, no deploy”: nessuna release senza SBOM e provenance.
• Visione N-tier: anche i sub-fornitori critici devono fornire SBOM/attestati – altrimenti niente accesso ai percorsi core.
• Security come gate nello SDLC: senza gate superato niente go-live, anche se la deadline della feature incombe.

Conclusione: prove invece di sensazioni

La catena di fornitura software è sicura solo quanto sono solide le sue prove. Con SBOM pulita, policy sui pacchetti rigorosa, provenance firmata e Fix-SLO applicati, il rischio diminuisce – in modo misurabile. Open Source resta un vantaggio competitivo se fate rispettare le regole. Altrimenti è un invito.

Scomodo ma vero: gli attaccanti non hanno bisogno di exploit esotici. In una percentuale superiore alla media dei casi bastano vulnerabilità aperte, una consapevolezza poco realistica e applicazioni web con una validazione degli input debole. Il resto è velocità. I difensori non perdono “intelligenza”, ma disciplina: SLO mancanti per il patching, rollout MFA a metà, assenza di uno standard vincolante di secure coding. Quando la sicurezza IT viene concepita come un progetto invece che come un’operazione continua, le falle restano aperte — talvolta per anni.

Chiudere le vulnerabilità: dal “patching” all’igiene guidata da SLO

“Patching regolare” non è un indicatore di qualità. Ciò che conta è quanto velocemente vengono chiuse le vulnerabilità critiche sul perimetro Internet — e in modo dimostrabile.
Controlli obbligatori:

• Inventario & esposizione: Inventario completo degli asset incl. esposizione a Internet (sistema, versione, responsabile, rilevanza per il business).
• SLO basati sul rischio: Vulnerabilità Internet critiche risolte in giorni, quelle interne in settimane definite. Violazione SLO ⇒ escalation automatica (slot di change, ping al management, obbligo di approvazione).
• Canary & rollout graduale: Prima anello di test, poi distribuzione scaglionata. Piano di rollback documentato e testato.
• Governance delle eccezioni: Ogni deviazione ha un owner, una scadenza e misure compensative (es. hardening/monitoraggio aggiuntivo).

KPI: Conformità agli SLO di patching (Internet vs. interno), MTTD/MTTR per criticità, percentuale di sistemi con agent/scanner aggiornati, Mean Exposure Time (MET) per CVE critiche.

Neutralizzare il phishing: tecnologia + comportamento, ancorati alla realtà

L’e-mail è lo strumento preferito degli attaccanti — non perché i difensori siano “stupidi”, ma perché pressione quotidiana, deleghe e approvazioni mobili favoriscono gli errori.
Controlli obbligatori:

• MFA resistente al phishing (passkey/FIDO2) per tutti i ruoli critici; disattivazione dei flussi legacy.
• Autenticazione e-mail (SPF/DKIM/DMARC) più rilevamento delle anomalie e policy su link/allegati.
• Protezione delle sessioni contro AitM (es. re-challenge in presenza di segnali di rischio, token binding).
• Esercitazioni realistiche: Scenari con pressione temporale, contesto dirigenziale, fornitori. Niente teatro del “non cliccare”, ma addestramento dei processi (es. verifica tramite richiamata, principio dei quattro occhi, approvazioni out-of-band).

KPI: Copertura MFA (resistente al phishing), percentuale di e-mail ad alto rischio bloccate, tempo fino alla conferma dell’allarme (SecOps), quota di verifiche positive per modifiche di pagamenti/identità.

Mettere in sicurezza le applicazioni web: dallo SDLC alla porta d’ingresso

Le applicazioni web insicure non sono un “problema degli sviluppatori”, ma un rischio di business. Portare in produzione funzionalità senza un gate di sicurezza significa risparmiare nel posto sbagliato.
Controlli obbligatori:

• Secure SDLC: Standard di coding vincolante, code review con controlli di sicurezza, secret scanning, gestione delle dipendenze (SBOM, equivalente Renovate/Dependabot).
• Test pre-produzione: DAST/SAST sui flussi critici (auth, upload, pagamento), casi di abuso (rate limit, enumeration, CSRF).
• Intorno all’applicazione: WAF/reverse proxy con regole chiare, hardening di TLS/header, bot management per gli endpoint di login.
• Esercizio operativo: Configurazioni versionate, deployment riproducibili, interruttori di emergenza (feature flag), telemetria fino all’evento di business.

KPI: “Time-to-fix” dei finding, percentuale di endpoint critici con policy WAF, finding aperti vs. risolti per sprint, hit di rate-limit vs. utilizzo legittimo.

Piano a 90 giorni: dalle buone intenzioni al controllo reale

Giorni 0–15 – trasparenza & baseline

• Inventario completo di asset e vulnerabilità con esposizione a Internet.
• Stato MFA: quali ruoli critici utilizzano metodi resistenti al phishing?
• Catalogazione delle applicazioni web: flussi critici, dipendenze, copertura dei test.
• Baseline KPI: conformità SLO di patching, copertura MFA, MTTD/MTTR, finding applicativi aperti.

Giorni 16–45 – hardening & applicazione degli SLO

• Rafforzare la policy SLO (Internet critico in giorni). Applicare la logica di escalation tecnicamente.
• Rollout di MFA resistente al phishing; disattivazione dei protocolli legacy; re-challenge di sessione in caso di rischio.
• Percorso SDLC obbligatorio: security review e test prima di ogni go-live. Baseline WAF per login/pagamenti/upload.

Giorni 46–75 – automatizzare & provare

• Ticketing automatico per CVE critiche; pipeline di deployment canary.
• Drill di phishing realistici (narrative dirigenti/fornitori) con policy di richiamata chiara.
• Drill applicativi: scenari di abuso (credential stuffing, download massivo, enumeration) incl. fine-tuning dei rate-limit.

Giorni 76–90 – consolidare l’impatto

• Review dei KPI vs. baseline; affinare le misure.
• Principio “never go alone”: nessun change in produzione senza checkpoint di sicurezza.
• Steering trimestrale: il budget segue la riduzione del rischio dimostrabile (rispetto SLO, tempo al containment, tasso di fix per sprint).

Architettura minima: meno attrito, più efficacia

• Backlog centrale dei finding: risultati di sicurezza da scanner, review, WAF in un unico sistema — prioritizzati per impatto sul business.
• Obbligo di telemetria: endpoint, identità, applicazioni web — un percorso dati coerente.
• Automazioni standard: isolamento, blocco account, creazione ticket, notifica stakeholder — senza orgie di clic manuali.
• Piano di uscita: Percorso di migrazione documentato per ogni componente core, così un problema del fornitore non blocca il programma.

Conclusione: la disciplina batte la speranza

Gli attaccanti vincono con velocità e semplicità. I difensori vincono con igiene guidata da SLO, autenticazione resistente al phishing e uno SDLC che impone la sicurezza come gate. Se chiudete queste tre porte in modo coerente, superficie d’attacco, tempi di reazione e costi diminuiscono — in modo misurabile, non “a sensazione”.

FAQ sul post del blog

Diagnosi scomoda: la Germania è economicamente attraente per gli attori del ransomware. Elevata profondità di creazione del valore, catene di fornitura dense, forte Mittelstand — e allo stesso tempo debolezze operative nella difesa dal phishing, nella chiusura delle vulnerabilità e nei processi decisionali. Inoltre, una disponibilità al pagamento relativamente alta alimenta l’economia degli attaccanti. Chi non contrasta subito con SLO chiari, incident response ben esercitata e una gestione delle vulnerabilità coerente, finisce per finanziare il problema.

Perché la Germania è particolarmente attraente

• Creazione di valore & dipendenze: Processi fortemente industriali, OT/IT interconnessi e catene just-in-time strette significano: ogni ora di fermo costa. Questo aumenta la pressione negoziale — e quindi l’attrattiva per il ransomware.
• PMI & Hidden Champions: Molti operatori sono “troppo grandi per essere ignorati, troppo piccoli per una sicurezza 24/7”. Mancano capacità per monitoraggio, hardening ed esercitazioni — un segnale rosso per gli attaccanti.
• Legacy & complessità: Ambienti cresciuti storicamente rendono difficile la standardizzazione. Sedi diverse, sistemi di terze parti, lacune nei passaggi — tutto ciò allunga MTTD/MTTR.
• Assicurazioni & regolamentazione: Requisiti più severi generano pressione di reporting. Senza controlli realmente applicati, questo si traduce in costosa rilavorazione invece che in prevenzione.

I veri punti di ingresso: 80/20 senza romanticismo

L’ingresso resta banale — ed è proprio per questo che funziona:

1. Phishing & social engineering: furto di sessioni, approvazioni affrettate, abuso delle autorizzazioni.
2. Vulnerabilità non patchate: VPN esposte, gateway, web-app — con exploit ampiamente disponibili.
3. Abuso di account obsoleti & protocolli deboli: il “legacy” non è romantico, è una porta d’ingresso.
4. Supply chain & accessi di terzi: requisiti minimi mancanti, contatti poco chiari, logging insufficiente.

Conclusione: il problema non è la mancanza di strumenti “nuovi”, ma la scarsa disciplina nei controlli di base. Zero Trust (“verificare invece di fidarsi”) qui non è uno slogan, ma un principio operativo.

Disponibilità al pagamento: l’acceleratore silenzioso

La logica economica è brutalmente semplice: se i pagamenti funzionano, il modello di business scala. La double/triple extortion (esfiltrazione prima della cifratura, pressione tramite protezione dei dati, minacce verso partner) aumenta la leva. Nelle catene di fornitura interconnesse, gli incidenti si propagano rapidamente ai clienti — la paura di danni secondari aumenta la disponibilità a negoziare. Senza una policy chiara, si decide sotto stress — quasi sempre a costi più alti.

Contromisure misurabili (attuabili subito)

• Identità prima di tutto: MFA resistente al phishing (passkey/FIDO2), disattivazione dei flussi legacy deboli, privilegi JIT per gli admin. Zero Trust impone verifiche continue e il minimo privilegio.
• Patch SLO con enforcement: Chiudere le falle critiche esposte a Internet in pochi giorni, quelle interne in settimane definite. L’escalation in caso di ritardo è automatica — non “un promemoria via e-mail”.
• Protezione e-mail + awareness realistica: Verifiche tecniche (autenticazione, anomalie) più training basati su scenari che simulano pressioni reali. Workshop di phishing senza pratica servono a poco.
• Freni di rete contro il movimento laterale: Segmentazione, allowlisting delle applicazioni, hardening delle workstation admin, blocco predefinito degli strumenti di scripting rischiosi.
• Backup che aiutano davvero: Offline/immutabili, drill di ripristino cronometrati con prova di integrità. Senza esercitazioni, i backup sono solo speranza.
• Mettere in sicurezza la supply chain: Controlli minimi, accessi verificati, logging obbligatorio, test a evento. Percorsi di contatto d’emergenza chiari — anche fuori dall’orario di lavoro.

KPI che i vertici devono vedere

• MTTD/MTTR per criticità: Quanto rapidamente rileviamo e risolviamo davvero?
• Conformità ai Patch SLO: Rispetto dopo l’esposizione (Internet vs. interno).
• Copertura MFA (resistente al phishing): Percentuale di ruoli critici con metodi forti.
• Tempo di ripristino & verificabilità: Quanto tempo serve perché il processo core X riparta — verificabile, non “percepito”.
• Igiene delle identità: Account orfani, rotazione chiavi/token, quota di autorizzazioni JIT.
• Fitness della supply chain: Percentuale di partner critici con controlli minimi comprovati e percorsi di emergenza testati.

Senza steering trimestrale, i KPI restano decorazione. Ogni deviazione richiede una reazione definita — altrimenti nulla cambia.

Piano 90 giorni per rischi tipici della Germania

Giorni 0–15 – Quadro iniziale & policy

• Identificare i 3 principali vettori di ingresso basati sui fatti (e-mail, app esterne, accesso remoto).
• Finalizzare la policy sui riscatti e l’albero decisionale (incl. legale/comunicazione).
• Baseline: MTTD/MTTR, conformità Patch SLO, copertura MFA, tempo di ripristino.

Giorni 16–45 – Hardening & consolidamento

• Distribuire MFA resistente al phishing, disattivare protocolli legacy, pilotare privilegi JIT.
• Applicare tecnicamente i Patch SLO; rendere stringenti finestre di change ed escalation.
• Standardizzare al minimo i controlli della supply chain; testare i contatti d’emergenza.

Giorni 46–75 – Automatizzare & fare esercitazioni

• Automatizzare le risposte standard (isolamento, blocco account, ticketing, conferma allarmi).
• Drill di ripristino cronometrato di un sistema critico con prova di integrità.
• Simulazione di social engineering con i reparti (approvazioni, principio dei quattro occhi, out-of-band).

Giorni 76–90 – Ancorare l’efficacia

• Confronto KPI con la baseline; chiudere i gap senza compromessi.
• Documentare piani di exit per i fornitori core (alternative, passi di migrazione).
• Istituire uno steering di sicurezza trimestrale: il budget segue una riduzione del rischio visibile.

Conclusione: velocità, chiarezza, disciplina

I numeri crescono perché l’economia dell’attacco funziona — e perché manca disciplina operativa. La buona notizia: con focus sulle identità, Patch SLO rigorosi, incident response esercitata e percorsi di supply chain solidi, il rischio cyber diminuisce sensibilibilmente. La Germania resta un obiettivo attraente — ma non per le aziende che agiscono con coerenza.

La dura verità: il ransomware non è più un “caso speciale”, ma attività industriale quotidiana per gli attaccanti. Il modello RaaS abbassa le barriere d’ingresso, professionalizza i processi e distribuisce i rischi su molti attori. Le aziende falliscono meno per mancanza di strumenti e più per carenza di disciplina nei controlli di base, percorsi decisionali chiari e playbook collaudati. Chi oggi non definisce obiettivi temporali solidi e ponti di emergenza paga due volte durante un incidente: una volta agli attaccanti e una seconda volta nella fase di ripristino.

Perché RaaS cambia tutto

In passato serviva un team completo di criminali con tecnologia, infrastruttura e canali di riciclaggio. RaaS separa questi elementi: gli sviluppatori forniscono kit, gli affiliati gestiscono l’accesso iniziale, altri curano negoziazione e monetizzazione. Il risultato: più campagne, iterazioni più rapide, migliore “assistenza clienti” dal lato degli attaccanti. Per i difensori significa attacchi più frequenti, più varianti e maggiore professionalità. Un caso isolato? No: un ecosistema scalabile con incentivi chiari.

Tattiche & punti di ingresso: le leve 80/20

La maggior parte dei casi di successo inizia ancora dalle stesse porte:

• Phishing e social engineering: credenziali, cookie di sessione, approvazioni affrettate.
• Vulnerabilità non patchate in servizi esposti a Internet (VPN, gateway, web app).
• Accessi compromessi da sistemi di terze parti o tramite credential stuffing.
• Abuso di tecniche LOTL (Living off the Land) per muoversi nella rete senza malware “rumoroso”.

I difensori perdono tempo in ecosistemi di strumenti complessi, mentre gli attaccanti accelerano con componenti standard. Conseguenza: ridurre l’attrito, aumentare l’affidabilità, fissare SLO rigorosi—anziché perdersi in misure cosmetiche.

Logica economica: perché i numeri crescono—e restano alti

Il ransomware resta attraente perché i margini funzionano. L’esfiltrazione dei dati prima della cifratura (“double/triple extortion”) massimizza la pressione, anche quando esistono backup. Inoltre, molte aziende sono integrate nelle catene di fornitura: un incidente non genera solo costi interni, ma attiva penali contrattuali, obblighi di notifica e fermi operativi per i partner. Finché queste cascata di effetti si traduce in denaro, l’incentivo per gli attaccanti rimane stabile—indipendentemente da arresti o takedown isolati.

Cosa funziona subito—senza edulcorare

• Rafforzare le identità: MFA resistente al phishing (es. passkey/FIDO2), disattivazione dei flussi legacy deboli, monitoraggio end-to-end delle sessioni. Zero Trust significa: verificare, non sperare.
• Rendere vincolanti gli SLO di patching: criticità esposte a Internet in giorni; vulnerabilità interne con scadenze chiare. Le violazioni degli SLO attivano escalation automatiche—non e-mail.
• Protezione e-mail + awareness realistica: controlli tecnici (autenticazione, anomalie) combinati con formazione basata su scenari che simulano vere tattiche di pressione.
• Backup che aiutano davvero: offline/immutabili, test di ripristino sotto pressione temporale, prova di integrità. Senza esercitazioni, i backup sono solo speranza.
• Frenare il movimento laterale: segmentazione di rete, allowlisting delle applicazioni, blocco predefinito degli strumenti di scripting pericolosi, hardening delle workstation amministrative.
• Mettere in sicurezza le interfacce di filiera: requisiti minimi, accesso solo tramite ponti verificati, obblighi di logging e test su evento.

Piano di 90 giorni contro il ransomware

Giorni 0–15 – Quadro iniziale & baseline

• Identificare i 3 principali vettori (e-mail, app esterne, accessi remoti) e documentarli con dati.
• Rilevare la baseline dei KPI: MTTD/MTTR per criticità, conformità agli SLO di patching, copertura MFA, tempi di ripristino.
• Aggiornare ruoli e matrice di approvazione per la incident response (incluse autorità e canali di comunicazione).

Giorni 16–45 – Hardening & accelerazione

• Distribuire MFA resistente al phishing, disattivare protocolli legacy, pilotare privilegi JIT per gli admin.
• Imporre gli SLO di patching (finestre di change, poteri di intervento, logica di escalation).
• Rafforzare la segmentazione; applicare policy elevate a workstation amministrative e server critici.

Giorni 46–75 – Automatizzare & testare

• Automatizzare le risposte standard: isolamento, blocco account, ticketing, conferma allarmi.
• Esercitazione di ripristino: recovery cronometrato di un sistema critico con prova di integrità.
• Filiera: provare contatti di emergenza, processi di change-freeze e protocolli per fornitori di accesso.

Giorni 76–90 – Consolidare l’impatto

• Verifica KPI vs baseline: MTTD/MTTR in calo, tasso SLO di patching in aumento, tempi di ripristino ridotti.
• Finalizzare policy sul riscatto e albero decisionale (con paletti legali).
• Fissare uno steering trimestrale: il budget segue la riduzione del rischio dimostrabile, non l’intuizione.

Comunicazione & logica decisionale durante l’incidente

Il maggiore driver di costo è il tempo perso per incertezza. Definire in anticipo:

• Chi decide su fermo produttivo, forensica esterna, comunicazioni a clienti/autorità?
• Quali criteri attivano quali escalation (es. indicatori di esfiltrazione, cifratura attiva, filiera coinvolta)?
• Quali canali out-of-band usare se i sistemi primari sono inaffidabili?

Conclusione: la disciplina batte lo zoo di strumenti

Il ransomware non scomparirà—è redditizio. I difensori vincono con velocità, chiarezza e pratica: mettere in sicurezza le identità, chiudere le falle in giorni, provare il ripristino con evidenze e cablare in anticipo le decisioni. Non è un “nice to have”, è l’airbag dei costi. Chi esegue correttamente il piano dei 90 giorni riduce i danni e la pressione negoziale—e rende RaaS un po’ meno profittevole.