È necessario comprenderne le relazioni

Una mappa cambiò la cura. Londra, 1854

Tra la fine di agosto e i primi giorni di settembre, nel quartiere di Soho, più di 500 persone morirono per aver contratto il colera, in una manciata di giorni. Era un momento molto delicato per Londra, ma i decessi vennero comunque tutti registrati, corredati non solo delle generalità della vittima ma anche di dove abitava.

Londra non aveva quindi un problema di dati. Aveva un problema nel modo in cui quei dati venivano interpretati.

Le informazioni che si avevano sulla trasmissione del colera, all’epoca, portavano a correlare il proliferare della malattia in zone molto circoscritte e la virulenza della stessa, con la conseguente attribuzione del contagio ai miasmi (ovvero le esalazioni prodotte dall’aria malsana e dalla decomposizione).

Era un’interpretazione coerente con la Londra dell’epoca: in quegli anni la città era sovraffollata, senza un sistema fognario adeguato alla crescita della popolazione. Risultato? Una città maleodorante; le acque reflue scorrevano lungo le strade – anche le più frequentate – ed arrivavano a contaminare pozzi e corsi d’acqua, un odore malsano e percepibile facilmente, che faceva pensare subito ad una malattia, di cui non era ancora stato identificato l’agente responsabile. Una spiegazione che coincideva  con ciò che vedevano: metterla in discussione era difficile.

Difficile per tutti ma non John Snow, che lo aveva fatto già nel 1849, quando aveva pubblicato la prima edizione di On the Mode of Communication of Cholera, sostenendo che la malattia veniva trasmessa attraverso l’ingestione di acqua contaminata. Non poteva sapere che la scienza gli avrebbe dato ragione molti anni dopo, quando il Vibrio cholerae, il famoso batterio a forma di virgola responsabile del colera, sarebbe stato isolato e riconosciuto. Eppure, già allora aveva notato che la teoria dei miasmi non riusciva a spiegare il comportamento dell’epidemia. Se il problema fosse stato semplicemente l’aria, persone che vivevano nelle stesse strade e respiravano le stesse esalazioni avrebbero dovuto ammalarsi in modo simile.

Peccato che – nella realtà – i casi seguivano distribuzioni diverse.

Quando il colera colpì Soho nel 1854, Snow non partì da un’intuizione improvvisa, bensì iniziò da un’ipotesi che cercava da anni di verificare e da una domanda circostanziata: quali erano gli elementi che accomunavano le persone che si erano ammalate?

Consultò i registri dei decessi, si recò presso le abitazioni delle vittime, parlò con le famiglie e ricostruì le loro abitudini: si rese così conto, incrociando le informazioni, che quasi tutti i morti vivevano vicino alla pompa pubblica di Broad Street. E che quelli che invece abitavano più lontano, ne bevevano abitualmente l’acqua. Alcuni la preferivano a quella delle pompe più vicine; alcuni bambini la bevevano andando a scuola: quindi anche i casi apparentemente incompatibili con la sua teoria, anziché essere esclusi (come rumore) vennero esaminati uno per uno. Snow non cercava solo conferme, ma una spiegazione legittima capace di sostenere anche le anomalie.

Così fece anche una controprova, lavorando su “ciò che non era accaduto”: Come nel caso del vicino birrificio di Broad Street, dove non risultavano morti tra gli operai.

Questo poteva in qualche modo mettere in discussione la teoria di Snow, salvo scoprire che questi operai disponevano di una fonte propria durante il lavoro e bevevano soprattutto birra (prodotta con acqua bollita);  così come nel caso della workhouse (l’ospizio) di Poland Street: nonostante la presenza di centinaia di persone in uno spazio ristretto, i decessi erano pochi rispetto al resto del quartiere. Quindi se l’aria fosse stata la causa principale, sarebbe stato difficile da spiegare, mentre la spiegazione era nel fatto che l’edificio utilizzava un pozzo indipendente.

È qui che entra in scena la mappa.

Nella rappresentazione pubblicata nel 1855, ogni morte veniva indicata da una piccola linea nera collocata in corrispondenza dell’edificio in cui era avvenuta; quando più persone erano morte presso lo stesso indirizzo, le linee venivano tracciate una accanto all’altra. Il risultato mostrava una concentrazione evidente intorno alla pompa di Broad Street e una progressiva diminuzione dei casi man mano che aumentava la distanza, soprattutto oltre le aree in cui risultava più conveniente servirsi di un’altra pompa.

La mappa non fornì a Snow informazioni nuove, gli permise di vedere, in pochi secondi, una relazione che fino a quel momento richiedeva pagine di registri, indirizzi e testimonianze. 

Ebbe quindi un’indiscutibile intuizione: modificò il modo in cui le informazioni disponibili potevano essere comprese.

È una distinzione importante, perché il racconto più diffuso trasforma John Snow nell’uomo che disegnò alcuni punti su una cartina, individuò la pompa di Broad Street e pose fine all’epidemia. La realtà fu molto più complessa e, proprio per questo, più interessante.

Quando la leva della pompa venne chiusa – l’8 settembre- il numero dei nuovi casi stava già diminuendo, anche a causa della fuga di molti abitanti dal quartiere e Snow stesso riconobbe che non era possibile stabilire quanto quella chiusura avesse inciso sull’andamento immediato dell’epidemia (la scoperta  del vibirio colerae gli avrebbe dato ragione certa solo anni dopo).

Ma dobbiamo ragionare su 2 elementi: la chiusura della pompa resta un gesto fondamentale, ma non perché rappresenti una soluzione semplice e definitiva, piuttosto rappresenta il momento in cui un’interpretazione sufficientemente solida diventa una decisione operativa, nonostante l’incertezza non sia stata eliminata.

Il secondo elemento è la mappa, che fu risolutiva, e non perché conteneva più dati, ma perché mostrava le relazioni tra quei dati. La mappa trasformò una sequenza di decessi registrati separatamente in un fenomeno osservabile nel suo insieme, e rese visibile un pattern che il modello dominante non riusciva a spiegare.

A quasi due secoli di distanza, il problema affrontato da Snow è sorprendentemente vicino a quello che incontriamo nella cybersecurity.

Un’infrastruttura può essere monitorata in ogni sua componente e rimanere poco comprensibile nel suo insieme. Questo accade perché la visibilità dei singoli elementi non coincide con la conoscenza delle relazioni che invece li uniscono: un accesso anomalo, una variazione nel traffico, una modifica a una configurazione o il comportamento inatteso di un dispositivo possono essere letti come eventi di basso impatto o indipendenti, ma quando vengono collocati all’interno dello stesso contesto, possono rendere visibile un movimento laterale, una compromissione in corso o un attacco che sta attraversando ambienti diversi.

Il punto non è (solo) raccogliere le informazioni, ma costruire una rappresentazione che restituisca un significato a ciò che viene raccolto;  

È un metodo che dovrebbe essere familiare a chi si occupa di sicurezza informatica: 

Un alert acquista valore soltanto quando sappiamo quale asset riguarda, quale funzione svolge quell’asset, con quali altri sistemi comunica e quali conseguenze può produrre la sua compromissione; senza queste relazioni, anche una grande quantità di informazioni rimane una raccolta priva di una mappa.

Esiste poi un secondo punto: John Snow non si limitò a leggere i dati, accettò che questi potessero contraddire la spiegazione ritenuta corretta dalla maggioranza.

Nella cybersecurity, questo passaggio è ancora difficile: troppe organizzazioni osservano gli eventi attraverso modelli costruiti sulle minacce già conosciute, sulle architetture documentate e sui comportamenti considerati normali e, quando la realtà si discosta da quel modello, il rischio è che spesso si tratterà la differenza come un’anomalia irrilevante, anziché domandarsi se sia il modello a non rappresentare più correttamente l’infrastruttura.

La storia di John Snow non racconta quindi soltanto il valore della visualizzazione dei dati: racconta il valore di una rappresentazione capace di mettere in discussione ciò che pensiamo di sapere.

Oggi possediamo molti più dati di quelli che Snow aveva a disposizione, strumenti infinitamente più sofisticati per raccoglierli e tecnologie capaci di analizzarli in tempi allora impensabili, ma  questo non garantisce che saremo più preparati a comprenderli.

È un altro modo di definire e perseguire la resilienza. La soluzione di cyber automated resilience di Gyala, Agger, si basa su questi principi e segue questo modus operandi. 

Fonti:
https://www.gutenberg.org/files/72894/72894-h/72894-h.htm
https://www.thelancet.com/journals/lancet/article/PIIS0140-6736(00)02442-9/abstract

L'articolo John Snow: Avere dati non basta proviene da Gyala.

…e la differenza tra funzionare e continuare a funzionare

Conosciamo tutti “Okay Houston, we’ve had a problem here”, ma forse conosciamo meno “Our mission was called ‘a successful failure,’ in that we returned safely but never made it to the moon.” (Jim Lovell il comandante di missione)

La NASA ancora oggi definisce la missioneApollo 13 una successful failure e quel successfull ci suona tuttora singolare, perché siamo abituati a considerare un progetto riuscito quando raggiunge l’obiettivo per cui è stato concepito. Apollo 13 non arrivò mai sulla Luna, ma continuò ad essere studiata come una delle missioni più straordinarie della storia dell’esplorazione spaziale.

Come mai? E cosa ha a che vedere con la cybersecurity?

Partiamo dall’inizio.

Era il 13 aprile 1970, Apollo 13 si trovava a circa trecentomila chilometri dalla Terra – un po’ lontano! Tutto era sotto controllo, fino a quando l’esplosione di un serbatoio di ossigeno in uno dei 5 motori presenti cambiò tutto, innescando una serie molto complessa di problemi e costringendo Huston ad annullare l’allunaggio. 
Quella esplosione non danneggiò solo i motori, ma compromise anche il Modulo di Comando, ovvero il modulo – unico e solo – destinato a riportare l’equipaggio sulla Terra, che iniziò progressivamente a degradare e a perdere la capacità di generare energia e acqua. L’obiettivo per cui l’intera missione era stata progettata cessò improvvisamente di esistere. E ne restò uno, che prima era un di cui: riportare a casa vivi i tre astronauti.

La soluzione individuata dalla NASA è entrata nella storia. Il modulo lunare Aquarius, progettato per trasportare due uomini sulla superficie della Luna e mantenerli in vita per circa quarantacinque ore, venne trasformato in una scialuppa di salvataggio capace di sostenere tre astronauti durante quasi novanta ore di viaggio verso la Terra. Nessuno aveva progettato quel veicolo per svolgere quella funzione.

Tutte le procedure scritte per la missione cessarono di essere utili, tutto quello che avevano normato e previsto, non era accaduto. Erano di fronte ad uno scenario mai ipotizzato. Il controllo a terra dovette quindi elaborare un piano del tutto nuovo. 

La NASA descrive questo lavoro con una frase che restituisce bene la dimensione del problema: «Fu necessario scrivere procedure completamente nuove e provarle nel simulatore prima di trasmetterle all’equipaggio».

Quella di Apollo 13 è una storia che spesso viene narrata come il trionfo dell’improvvisazione; Questo, sebbene – leggendo la documentazione della NASA – emerga una storia parallela: emerge che il termine improvvisazione non è corretto e coerente per quanto accade: i tecnici si concentrarono sui dati raccolti in tempo reale e sul contesto. Le informazioni provenienti dalla navicella venivano interpretate a terra da Houston, riprodotte e trasformate in un modello sufficientemente affidabile della situazione, testate sul simulatore, grazie al quale era possibile sperimentare senza aumentare il rischio nello spazio, e poi condivise con gli astronauti.

Quindi, non la decisione più rapida, ma la più coerente per le condizioni reali della missione; la differenza è sostanziale, perché Apollo 13 non fu salvata soltanto dalla quantità di informazioni disponibili o dalla velocità con cui vennero prese le decisioni – come siamo portati a pensare sia la miglior strada per risolvere in situazioni analoghe – ma dalla capacità di trasformare informazioni frammentate in una comprensione condivisa e continuamente aggiornata e allineata a ciò che stava accadendo.

Eccoci al punto: È un principio che riguarda molto da vicino la cybersecurity.

Le infrastrutture digitali contemporanee producono una quantità enorme di dati: Log, allarmi, telemetrie, flussi di rete e segnalazioni provenienti dagli endpoint, permettono di osservare quasi ogni componente di un’organizzazione, ma la disponibilità di queste informazioni non coincide con la capacità di comprendere lo stato dell’intera infrastruttura.

Un sistema può essere molto visibile e restare, allo stesso tempo, poco comprensibile.

Questo differenziale emerge in modo lampante negli ambienti complessi, nei quali sistemi IT, reti OT, dispositivi IoT, servizi cloud e componenti della supply chain interagiscono continuamente, e un evento raramente rimane confinato nell’asset in cui ha avuto origine. Può propagarsi, modificare il comportamento di altri sistemi, interrompere un processo fisico o compromettere una funzione essenziale, senza che queste conseguenze risultino immediatamente leggibili nel singolo allarme.

Rilevare un’anomalia rappresenta, quindi, soltanto il primo passaggio: occorre comprenderne il contesto, ricostruire le relazioni tra gli asset coinvolti, valutarne gli effetti e stabilire quale reazione permetta di contenere l’incidente senza compromettere ciò che deve continuare a funzionare.

La rapidità, da sola, non risolve il problema: una risposta veloce, costruita su una rappresentazione incompleta della situazione, resta una risposta sbagliata, presa in meno tempo.

Per Houston, ogni nuova informazione modificava ciò che il Mission Control sapeva della missione, ogni simulazione abbassava il grado di incertezza e ogni procedura validata prima di diventare un’azione riduceva il rischio. Il valore del simulatore non consisteva semplicemente nel replicare la navicella, ma nel consentire alla NASA di osservare le conseguenze di una decisione prima che quella decisione producesse effetti irreversibili nello spazio. 

La cyber resilience nasce con lo stesso presupposto. Secondo il NIST, consiste nella capacità di anticipare, resistere, recuperare e adattarsi a condizioni avverse, attacchi o compromissioni che riguardano sistemi basati su risorse digitali. Non coincide quindi con l’assenza di incidenti, ma con la possibilità di continuare a raggiungere gli obiettivi della missione, anche in un ambiente compromesso. E, se l’obiettivo è difendere le infrastrutture aziendali, questo non esclude al 100% la possibilità che vengano attaccate, ma richiede che, anche in quel caso, non vengano danneggiate.

Questo cambia il modo in cui definiamo il successo della cybersecurity.

Per anni lo abbiamo misurato soprattutto attraverso gli eventi che siamo riusciti a impedire: attacchi bloccati, vulnerabilità corrette, accessi negati e malware intercettati. Sono presupposti indispensabili, ma descrivono soltanto ciò che accade quando i sistemi di protezione svolgono la funzione per cui sono stati progettati.

La resilienza si misura in un momento diverso, quando una difesa viene superata, una componente diventa indisponibile o lo scenario reale non corrisponde più a quello previsto. È allora che la capacità di osservare, comprendere e reagire diventa più importante della capacità di applicare una procedura già scritta.

Apollo 13 tornò sulla Terra perché la NASA continuò costantemente a convertire la conoscenza mentre l’incidente era ancora in corso, trasformandola in decisioni verificabili e effettive.

Il Modulo Lunare, che non avrebbe mai raggiunto la superficie della Luna, mantenne in vita l’equipaggio. I simulatori, progettati per preparare una missione già definita, furono utilizzati per sviluppare procedure che non erano mai state contemplate. 

Il Mission Control, privato del piano originario, non smise di governare la missione. Come lo fece? conservando la capacità di comprenderla. È questa la differenza tra funzionare e continuare a funzionare.

La cybersecurity affronta oggi la stessa distinzione. Proteggere un sistema significa fare in modo che svolga la funzione per cui è stato progettato. Renderlo resiliente significa garantire che, quando il piano viene meno, l’organizzazione continui a mantenere l’operatività grazie anche alla comprensione di ciò che accade e nei tempi utili per trovare una strada diversa.

L'articolo Apollo 13 proviene da Gyala.

La difesa non è il muro. È il sistema.

Sapete cosa è l’Agger? È un termine latino che si può tradurre in bastione terrapieno…
Ma non era solo un terrapieno. Era parte di qualcosa di molto più articolato: un fossato scavato davanti, la terra rialzata a formare una barriera, una palizzata di pali appuntiti, torri di osservazione, ingressi controllati, e soprattutto caratterizzato da una disposizione precisa delle truppe.

A differenza di quanto potremmo immaginarci, l’Agger non serviva a impedire l’attacco in senso assoluto. Non era quello l’obiettivo.

Serviva a rallentare chi avanzava, a esporlo, a costringerlo a passare dove i Romani volevano. Serviva a trasformare un attacco in qualcosa di “leggibile” e “controllabile”.

E in questo modus operandi, c’è già un primo punto che, ancora oggi, fatichiamo a capire nel mondo cyber: gli antichi strateghi avevano compreso l’importanza di conquistare tempo e visibilità in una strategia di difesa.

Non esisteva un perimetro impenetrabile neanche per Roma, ma i romani creavano intorno al perimetro un sistema progettato per far emergere l’attacco.

Quando si leggono i racconti delle campagne di Cesare, questo approccio torna continuamente. I campi fortificati venivano costruiti ogni giorno, anche in territori apparentemente sicuri.
Questo è la conseguenza di un’altra importante intuizione dei romani: erano convinti di non poter evitare qualsiasi attacco, ma sapevano che, quando sarebbe arrivato, dovevano essere pronti a gestirlo.

E qui entra il secondo elemento: le truppe.

Le legioni non stavano ferme dietro l’Agger, aspettando che succedesse qualcosa.  Erano, bensì, addestrate a reagire in modo coordinato, organizzate in unità autonome ma interconnesse e capaci di adattarsi rapidamente al contesto. 
Ogni soldato sapeva cosa fare, ma soprattutto ogni unità sapeva come muoversi insieme alle altre e in base alle altre.

C’erano vedette che osservavano costantemente, segnali che permettevano di trasmettere informazioni in tempi rapidi, e una capacità continua di riallocare le forze dove la pressione cresceva.

La struttura serviva a guadagnare tempo. Il controllo stava nella risposta contestualizzata e immediata. La difesa, quindi, non era la barriera, ma era la capacità di usarla.

A questo punto, il parallelo con la cybersecurity è inevitabile.

Oggi continuiamo a costruire sicurezza come se bastasse un muro. Rafforziamo il perimetro, aggiungiamo controlli, segmentiamo le reti. Tutto corretto, tutto necessario. Ma spesso guidato da un’idea implicita: se riusciamo a bloccare l’ingresso, abbiamo risolto il problema.

Ma le eccezioni, le infiltrazioni e quindi gli attacchi, ci dimostrano che non funziona. 

Negli ambienti IT – e ancora di più in quelli OT – il perimetro non è più qualcosa di stabile. È distribuito, dinamico, attraversato continuamente da flussi che non possiamo interrompere. Pensare di “tenere fuori” in modo definitivo non è realistico.

E soprattutto, ci aiuterebbe capire che non è lì che si decide l’esito di un attacco.

I Romani non si chiedevano se qualcuno sarebbe arrivato al fossato né se lo avrebbe superato. Lo davano per scontato. La loro attenzione era su cosa sarebbe successo dopo: quanto tempo avrebbero guadagnato, quanto velocemente avrebbero capito da dove arrivava la minaccia, con quale efficacia avrebbero reagito.

Avevano già fatto il passaggio che moltissime aziende non contemplano.

Non evitare l’ingresso, ma mantenere il controllo.

Questo implica un cambio di prospettiva non banale. Significa accettare che l’attaccante possa entrare, e progettare sistemi che non si limitano a resistere, ma che sanno osservare, interpretare e reagire. Significa spostare il valore dalla struttura al comportamento.

In altre parole, passare da una difesa statica a una difesa orchestrata.

È esattamente il tipo di approccio che negli ambienti IT/OT diventa critico. Perché lì il “muro” è spesso fragile, o semplicemente inesistente; e l’unico modo per mantenere il controllo è sapere cosa sta succedendo, mentre succede.

Forse è questo il punto che vale la pena portarsi dietro dal passato: il problema non è (solo) se l’attaccante supera il perimetro, ma cosa succede nei minuti successivi. Su questo, molto spesso, siamo ancora meno preparati dei Romani.

Se si guarda alla cybersecurity con questa lente, il punto non è più costruire difese sempre più spesse, ma progettare sistemi capaci di osservare, interpretare e reagire mentre l’attacco è in corso.

Non basta rilevare un’anomalia, occorre invece comprenderla nel contesto, correlare gli eventi e reagire in modo coerente con il servizio che si sta proteggendo, in tempo reale.

È esattamente su questo paradigma che si inserisce la piattaforma per la cybersecurity IT/OT/IoT Agger di Gyala.

• un’architettura che supera la logica tradizionale della sicurezza centralizzata e sequenziale, introducendo un modello in cui:
• la detection è comportamentale, costruita sulla conoscenza dinamica dell’infrastruttura e dei suoi stati operativi
• la correlazione degli eventi IT, OT e di rete permette di trasformare segnali isolati in contesto decisionale
• la reaction è automatizzata e distribuita, applicata direttamente sugli endpoint e sui sistemi coinvolti, senza dipendere da tempi umani o escalation
• la visibilità è end-to-end, anche su ambienti ibridi e sistemi legacy, dove il perimetro è per definizione incompleto 
• la possibilità di customizzare le reazioni a livello di singolo end point per essere efficaci con la modalità più adatta al contesto

In questo modello, la difesa non è più un punto di controllo, ma una proprietà dell’intero sistema.

Come nell’Agger romano, il valore non è impedire l’ingresso: è sapere cosa sta succedendo mentre succede, e avere già la capacità di reagire; questo oggi lo chiamiamo Resilienza.

L'articolo Come l’ingegno dietro l’Agger romano può insegnarci la cybersecurity proviene da Gyala.

Ma nel controllo dell’infrastruttura

Guardare solo l’infrastruttura o governarne il funzionamento? Sembra una domanda banale ma non lo è.                                                                        

Ispirata dalla storia del passato, provo a darvi un punto di vista che prende spunto da un evento lontano, perché, le storie spesso, insegnano molto.

Questa storia riguarda un’infrastruttura critica centrale per la popolazione e, anche per questo motivo, diventata negli ultimi anni uno degli obiettivi preferiti degli hacker: gli acquedotti.

Nel 97 d.C. l’imperatore Nerva affidò a Sesto Giulio Frontino uno degli incarichi più importanti dell’Impero Romano: la gestione degli acquedotti di Roma – a valle di questo incarico Frontino scrisse un rapporto ufficiale dedicato in modo specifico ad un’indagine sulle infrastrutture idrauliche urbane ed è l’unico rapporto ufficiale di età romana, giunto fino a noi (“De Aquaeductu Urbis Romae”, Sesto Giulio Frontino sugli acquedotti di Roma, redatto in due libri alla fine del I secolo d.C.)

La gestione dell’acqua era un compito amministrativo molto importante: l’acqua arrivava nelle città da secoli e gli acquedotti erano, a tutti gli effetti, una delle più grandi opere e conquiste dell’ingegneria romana.

Quando Frontino cominciò il suo lavoro, scoprì qualcosa di inatteso “Inveni praeterea quosdam ductus minus quam in commentariis contineretur erogare”. Ovvero: “Ho constatato che alcune condotte distribuivano una quantità d’acqua inferiore a quella riportata nei registri” .

La quantità d’acqua che avrebbe dovuto raggiungere Roma, avrebbe dovuto essere una quantità nettamente superiore rispetto a quella poi effettivamente disponibile. La cosa strana è che non c’era carenza d’acqua dalle fonti, né falle nell’infrastruttura; bensì, lungo il percorso, qualcuno aveva iniziato a prelevare più del dovuto, tramite deviazioni abusive, concessioni e privilegi fittizi.

Il problema non era nell’infrastruttura, ma nel suo controllo: fino ad allora si guardava l’acqua, ovvero una risorsa, ma Frontino spostò lo sguardo verso l’acquedotto. Verso il potere. 

È chiaro che il potere non stava nella risorsa (a quel tempo assolutamente abbondante) ma nella capacità di controllarla, trasportarla e distribuirla, e questo – meglio degli altri – lo sapevano fare i Romani. Il vero vantaggio competitivo non era la materia prima, ma l’infrastruttura e la capacità, e, ancor prima, la possibilità di decidere come utilizzarla e gestirla, o, anche, di chiudere un’erogazione.

Ci ricorda qualcosa?

Pensiamo al caso Antropic: non importa dove si trovino i dati, dove abbia sede il fornitore o quale bandiera sventoli sopra il datacenter, di fatto conta chi può spegnere l’interruttore, chi governa l’infrastruttura, chi può decidere se spegnerla.

L’AI (come tutte le altre tecnologie strategiche) sta diventando un asset geopolitico e, anche se la controversia tra Anthropic e il Pentagono dovesse placarsi, sono ormai attive domande fondamentali riguardo la distribuzione del potere; 

Dovremmo vivere in un’economia di libero mercato dove le imprese private – a netto di accordi specifici e di chiarezza commerciale – godono generalmente di libertà nel determinare le condizioni alle quali forniscono i loro prodotti, ma si fa sempre più chiaro che la sovranità non dipende più (solo) dal possesso dei dati ma (anche) dal controllo di infrastruttura, cyber, rete, energia e capacità computazionale.

Dobbiamo cambiare ragionamento e tattica, l’idea che “utilizzare” qualcosa equivale a dire che possiamo controllarla è chiaramente fallace; possedere i dati non significa controllare l’infrastruttura che li rende accessibili, così come utilizzare una piattaforma non significa governarne il funzionamento. E, ancora, integrare un modello di intelligenza artificiale nei propri processi non significa avere il controllo sulla sua disponibilità futura.

Quando parliamo di resilienza, continuità operativa o sovranità digitale, la domanda – parafrasando Giulio Frontino, non è quanta acqua arriva, ma quali sono gli acquedotti da cui dipendiamo, chi li governa e come.

 La cybersecurity ha sempre avuto un’ossessione: impedire agli attaccanti di entrare, una sfida che rimane fondamentale. Oggi a questa necessità si affianca una geopolitica complessa che ci porta ad un’altra domanda: capire chi può impedirci di continuare a operare.

È sicuramente una domanda che ha a che fare con la resilienza, ma anche con la consapevolezza della scelta. 

E qui torniamo d’obbligo a parlare di sovranità digitale, ma non dobbiamo solo parlarne ai convegni, dobbiamo mettere a terra un piano preciso, che guardi alle eccellenze tecnologiche del nostro paese e che scardini il concetto di “leader di mercato” a tutti i costi. Gyala vuole contribuire a questo cambio di visione: lavoriamo con partner locali, abbiamo una tecnologia 100% italiana e mettiamo la governance dell’infrastruttura al centro delle scelte di sicurezza.

L'articolo Sovranità digitale: il potere non è nella risorsa proviene da Gyala.

Quello che non sappiamo misurare.

Il problema delle PMI italiane non è solo la cybersecurity, ma la difficoltà di trasformare il rischio in una misura leggibile. 

Partiamo dai dati: 

Il terzo Rapporto Cyber Index PMI, promosso da Confindustria e Generali, con il contributo scientifico degli Osservatori Digital Innovation del Politecnico di Milano e la partnership dell’Agenzia per la Cybersicurezza Nazionale, assegna alle PMI italiane un livello medio di maturità cyber di 55 punti su 100. È un valore in crescita rispetto agli anni precedenti, ma ancora inferiore alla soglia di sufficienza fissata a 60. (Fonte Cyber Index PMI 2025, Confindustria, Generali, Osservatori Digital Innovation – Politecnico di Milano e Agenzia per la Cybersicurezza Nazionale https://corporate.generali.it/comunicati-stampa/2026-cyber-index-pmi/) 

C’è però un altro numero che dobbiamo guardare (e incrociare) per avere una visione chiara e completa: solo il 16% delle PMI italiane può essere considerato realmente maturo nella gestione del rischio cyber. La maggior parte delle imprese si trova in una zona intermedia: conosce il problema, ne riconosce l’importanza, ma non ha ancora sviluppato la capacità di tradurre questa consapevolezza in prevenzione.

È una fotografia diversa da quella che siamo abituati a vedere. 

L’idea di fondo che passava nelle precedenti analisi era che le PMI italiane non prendevano in considerazione l’argomento cybersecurity. I dati, oggi, sembrano dirci qualcosa di diverso: la consapevolezza esiste e continua a crescere, ma quello che manca, nella maggior parte dei casi, è la capacità di trasformare questa consapevolezza in una misura oggettiva del rischio. 

Percepire un rischio, non significa conoscerlo e saperlo misurare. 

Una PMI può avere cento vulnerabilità classificate come critiche, senza essere realmente esposta. Oppure può averne soltanto due, ma sui sistemi che governano la produzione, la contabilità o i dati più sensibili, che sono pericolosissime per il danno che potrebbero arrecare. Nel primo caso l’esposizione va dominata, nel secondo il rischio di danno è significativo e altissimo. 

Lo stesso vale per gli asset: sapere di avere cinquecento dispositivi connessi è un dato; sapere quali sono essenziali, quali comunicano con l’esterno, quali usano software non più supportato e quali non dovrebbero neppure essere più presenti, significa trasformare il dato in conoscenza. 

Quella della percezione ma incapacità di gestione del tema, è una situazione che, esclusa la cybersicurezza, non si verifica in nessun’altra funzione aziendale. 

Quale imprenditore prende (o non prende) una decisione senza tener conto dei numeri dell’azienda? Ogni imprenditore conosce il fatturato, i margini, la liquidità, il portafoglio ordini e i costi, e conosce questi numeri perché rappresentano il punto di partenza di qualsiasi decisione: non assumerebbe nuovo personale, né investirebbe in un macchinario o avvierebbe un nuovo mercato, senza avere un quadro preciso della situazione economica. 

Questo – sembra – non valga in ambito cybersecurity, e il report ci suggerisce che nelle PMI questa metodologia è ancora latente. 

Non è un caso che il NIST Cybersecurity Framework 2.0 metta la funzione Identify all’inizio del processo di gestione del rischio. Prima di proteggere, rilevare o rispondere, un’organizzazione deve sapere cosa possiede, come sono collegati i suoi asset, quali dipendenze esistono e quali processi sostengono davvero il business. (https://www.nist.gov/cyberframework).

Nelle PMI, questo principio vale ancora di più per la tipologia di azienda; una grande organizzazione può contare su ridondanze, sistemi alternativi e processi distribuiti. Una piccola o media impresa, invece, spesso dipende da un singolo server, da un PLC, da un NAS o dal computer che gestisce contabilità e produzione.  

Quindi è essenziale conoscere le vulnerabilità – prima di tutto – per, in particola modo, concentrarsi su quelle che possono davvero compromettere la continuità operativa dell’azienda e sugli asset realmente critici per il business, trasformando un tema tecnico in un tema di continuità operativa. 

È quindi la conoscenza, non il dato, che rende possibile prendere decisioni. 

Negli ultimi anni, inoltre, il contesto è cambiato radicalmente: le infrastrutture delle PMI non sono più costituite da qualche server e da una rete locale. Oggi convivono servizi cloud, applicazioni SaaS, dispositivi mobili, accessi remoti dei fornitori, ambienti OT interconnessi, identità distribuite e sistemi che comunicano continuamente tra loro.  La superficie di attacco non è cresciuta soltanto in dimensioni, è aumentata soprattutto in complessità. Pensare di governare questa complessità affidandosi alla memoria delle persone o a una fotografia scattata mesi prima è irrealistico. 

Il rischio cyber non aumenta semplicemente quando viene scoperta una nuova vulnerabilità; aumenta nel momento in cui un’organizzazione smette di sapere dove si trova, quali sistemi coinvolge e quale impatto potrebbe avere sul proprio business. 

Forse il problema delle PMI italiane in tema sicurezza informatica è continuare a prendere decisioni su un rischio che, nella maggior parte dei casi, non sappiamo ancora misurare e interpretare. 

Fonti: Cyber Index PMI 2025, Confindustria, Generali, Osservatori Digital Innovation – Politecnico di Milano e Agenzia per la Cybersicurezza Nazionale: https://corporate.generali.it/comunicati-stampa/2026-cyber-index-pmi/ 

  NIST, Cybersecurity Framework (CSF) 2.0, funzione Identify: https://www.nist.gov/cyberframework 

L'articolo PMI, Il rischio più difficile da governare: proviene da Gyala.

A luglio 2026, nel Report “Hype Cycle for Zero-Trust Technology”. Dopo la menzione di Giugno 2026, nell “Hype Cycle for CPS Security”.

Siamo orgogliosi e entusiasti del dopo riconoscimento da parte di 𝗚𝗮𝗿𝘁𝗻𝗲𝗿® nel 2026.

Infatti, dopo la recentissima menzione a Giugno come Sample Vendor nel Report di 𝗚𝗮𝗿𝘁𝗻𝗲𝗿® “Hype Cycle for CPS Security”, 2026,  Gyala è stata menzionata anche nel Report “Hype Cycle for Zero-Trust Technology”, luglio 2026.

Un ulteriore e importante riconoscimento da parte degli analisti di 𝗚𝗮𝗿𝘁𝗻𝗲𝗿® per la nostra soluzione – Agger – che ci posiziona come riferimento della tecnologia Zero-Trust nel 2026 e ancora una volta nel campo del CPS Security.

I due Report:

Il Report “Hype Cycle for Zero-Trust Technology, 2026″ è visto come uno strumento chiave per supportare il leader della sicurezza informatica che adottano strategie zero-trust e che necessitano di tecnologie che ne accelerino l’implementazione. Questo Report nasce per aiutarli a dare priorità alle innovazioni tecnologiche che migliorano la postura di sicurezza zero-trust dell’azienda.  

Il Report è disponibile per i clienti con accesso al portale Gartner al Link

L’Hype Cycle for Cyber-Physical Systems (CPS) Security è uno dei report annuali più autorevoli di Gartner®.

Analizza il livello di maturità, adozione e aspettative delle tecnologie dedicate alla protezione degli ambienti in cui il mondo digitale interagisce con quello fisico: OT, impianti industriali, infrastrutture critiche, IoT industriale, sistemi di controllo, smart building, reti energetiche e trasporti.

Il Report è disponibile per i clienti con accesso al portale Gartner qui: https://www.gartner.com/interactive/hc/7934809?ref=solrAll&refval=563022047 

Scopri di più su Gyala e sulla nostra tecnologia di automated cyber resilience IT/OT/IoT: Agger

Gartner, Hype Cycle per la sicurezza CPS, 2026, Katell Thielemann, Wam Voster, 29 maggio 2026
GARTNER e HYPE CYCLE sono marchi di Gartner, Inc. e/o delle sue affiliate. Gartner non approva alcuna azienda, fornitore, prodotto o servizio descritto nelle sue pubblicazioni e non consiglia agli utenti di tecnologie di selezionare solo i fornitori con le valutazioni più alte o altre designazioni. Le pubblicazioni di Gartner consistono nelle opinioni dell'organizzazione di Gartner dedicata agli insight di business e tecnologia e non devono essere interpretate come dichiarazioni di fatto. Gartner declina ogni garanzia, espressa o implicita, in relazione a questa pubblicazione, incluse eventuali garanzie di commerciabilità o idoneità per uno scopo particolare.

L'articolo Doppia menzione per Gyala: citata da Gartner® come Sample Vendor proviene da Gyala.

Il vero problema non è il buio, ma dove punti la luce

Michelangelo Merisi, detto Caravaggio, non dipingeva la luce: dipingeva ciò che emergeva dalla luce. Nato alla fine del XVI secolo, rivoluzionò la pittura lasciando le figure idealizzate del Rinascimento a favore del realismo della vita quotidiana. I suoi soggetti sono persone vere, con mani sporche e volti reali e segnati, pieni di emozioni. E sceglie il contrasto tra ombra e luce – il celebre chiaroscuro – per rendere uniche le sue composizioni che acquistano una forza drammatica che- ancora oggi – ci affascina.

Una riflessione su questo stile la dobbiamo fare: la luce di Caravaggio non illumina, indica.

Cosa c’entra con la cybersecurity? 

C’entra eccome. Perché troppo spesso, facciamo l’opposto, confondendo visione totale con controllo. 
Le aziende hanno a disposizione sempre più dashboard, più log, più alert, più telemetria, scambiando la quantità di dati con qualità contestualizzata. Troppi dati, spesso disaggregati su dashboard diverse sono solo “rumore”: migliaia di eventi raccolti, a volte raccontati con splendidi grafici colorati, sono, troppo speso, inutili nel momento in cui serve capire cosa sta davvero succedendo.Ed allora prendiamo esempio dal maestro. Caravaggio aveva capito qualcosa che le aziende spesso dimenticano: illuminare tutto non significa vedere meglio.

….

È esattamente da questa idea che nasce Agger di Gyala: non abbiamo la pretesa di eliminare completamente il buio ma la volontà di darvi una tecnologia in grado di dirigere la luce. Negli ambienti IT/OT, la quantità di eventi, asset, segnali e anomalie cresce molto più rapidamente della capacità  di interpretarli. Troppo rumore, nessun allarme. La nostra soluzione di automated cyber resilience riordina il caos, per permettere di vedere ciò che serve in quel momento: contestualizza, correla, dà priorità e reagisce autonomamente. 

Leggi l’articolo a cura di Simona Piacenti, Head of Marketing & Communication Gyala, su Red Hot Cyber

L'articolo Cybersecurity e Caravaggio: proviene da Gyala.

Estratto dell’articolo di Ict Security Magazine

La sicurezza cyber della supply chain estesa

Il 2026 e la fine del trust by default

Nel 2026 la cybersecurity completa la propria evoluzione da disciplina difensiva a leva strategica per la resilienza di infrastrutture critiche e aziende.

Sul versante tecnologico, l’interconnessione fra ambienti IT, OT e IoT, la persistenza di sistemi legacy non aggiornabili, la crescente dipendenza da cloud provider e servizi SaaS dei grandi hyperscaler e l’introduzione di nuovi servizi di intelligenza artificiale (in primis i modelli di linguaggio utilizzati dagli utenti finali) ampliano in modo significativo il perimetro infrastrutturale. Sul versante politico, dazi, guerre e frizioni geopolitiche accelerano gli attacchi persistenti di matrice statuale, e contemporaneamente emerge una nuova categoria di rischio: i cosiddetti shadow risk, rischi nascosti legati alla supply chain e all’utilizzo non governato di strumenti gratuiti, software di terzi e servizi di AI.

I rischi fantasma e il necessario cambio di paradigma

La nozione di terza parte va oggi estesa ben oltre i fornitori contrattualizzati. Sono terze parti, a tutti gli effetti, i sistemi operativi, le componenti hardware, le piattaforme cloud, qualsiasi software dotato di meccanismi di aggiornamento automatico e, in modo crescente, i sistemi di intelligenza artificiale incorporati nei flussi operativi. Ognuno di questi attori è già dentro l’infrastruttura della singola organizzazione e potrebbe, in scenari avversi, diventarne un vettore di compromissione.

Le normative recenti (NIS2, DORA, GDPR, le determinazioni dell’Agenzia per la Cybersicurezza Nazionale) richiedono giustamente che i contratti con i fornitori diretti includano requisiti di sicurezza verificabili e auditabili. Il punto sollevato da Mugnato è però che tali requisiti, pur strettamente necessari, spesso non sono sufficienti. La quota più rilevante di rischio risiede in fornitori e tecnologie “nascoste” rispetto al perimetro formale dei contratti, come anche in servizi gratuiti che possono introdurre canali di esposizione dei dati al di fuori di ogni governance.

Leggi l’articolo completo su Ict Security Magazine

L'articolo Oltre le terze parti: proviene da Gyala.

Un nuovo modello di industria dei servizi pubblici con il Piano Transizione 5.0

Estratto dall’articolo di FORUMPA

Con il Piano Transizione 5.0, la PA supera il ruolo di semplice ente regolatore per farsi “industria dei servizi”, adottando logiche di smart manufacturing e IA. In settori critici quali sanità, energia e trasporti, la funzione pubblica dipende strettamente dalla resilienza delle infrastrutture IT/OT/IoT. In questo scenario, piattaforme integrate proteggono i sistemi da minacce sofisticate, garantendo reattività immediata e piena conformità normativa.

Come cambia la gestione della cybersecurity

Le nuove tecnologie implicano che una compromissione si traduca non solo in perdita di dati, ma in paralisi operativa, danni fisici e rischi per la sicurezza delle persone. In risposta a tale complessità, l’esperienza di player specializzati come Gyala evidenzia la necessità di un passaggio dalla difesa statica alla cyber resilienza olistica. Questo approccio, integrando IT, OT e IoT, sposta il focus dalla semplice detection alla reaction automatica: un’architettura di sicurezza che permette di intervenire tempestivamente sul singolo endpoint o dispositivo, garantendo l’operatività anche in contesti critici, reti segregate o ambienti air-gapped.

La resilienza integrata e la visibilità sulla supply chain

Le infrastrutture industriali presentano vulnerabilità specifiche: sistemi legacy difficili da aggiornare, accessi remoti non sempre controllati, mancanza di visibilità unificata e tempi di reazione incompatibili con la velocità degli attacchi contemporanei. Per superare questi limiti, la ricerca tecnologica si è spostata verso architetture in grado di integrare XDR, Network Detection e Risk Management. È qui che si inserisce la piattaforma Agger di Gyala, che declina in ambito civile competenze maturate nel settore Difesa, IT e cybersecurity.

Il valore di soluzioni di questo tipo risiede nella capacità di automatizzare le azioni di contenimento, riducendo il tempo di reazione secondo regole coerenti con il contesto operativo industriale. L’innovazione risiede nella personalizzazione delle regole di Detection e Reaction direttamente all’interno degli agent: l’endpoint o l’apparato OT può così reagire autonomamente e la reazione può essere calibrata sulle specificità del punto che deveproteggere, anche in assenza di connettività verso un SOC centrale.

Leggi l’intero articolo su FORUMPA

Foto di Gerd Altmann da Pixabay

L'articolo Smart manufacturing e PA: proviene da Gyala.

Gyala ridisegna le regole del gioco in uno scenario in cui fidarsi non è più un’opzione.

La domanda che questo articolo pone, e che nessuna organizzazione può permettersi di ignorare, non è “siamo al sicuro?”. È molto più scomoda: sappiamo davvero da chi dipende la nostra sicurezza?

IT, OT e IoT interconnessi; PLC non aggiornabili, sensori IoT distribuiti, dipendenze cloud e SaaS, frizioni geopolitiche, attacchi persistenti, shadow risks generati da manutentori e strumenti AI gratuiti. In questo scenario, è evidente come nella cybersecurity non possa più funzionare il paradigma del trust by default.

È proprio da questa consapevolezza che nasce l’approccio di Gyala: nessuna fiducia implicita, ma anomaly detection in real-time, behavioral analytics, automazione nativa e correlazione cross-layer su ambienti IT, OT e IoT. Con Agger, detection e reaction diventano adattive e configurabili fino al singolo endpoint, abilitando una risposta immediata e contestuale.

Supply Chain Cybersecurity 2026: da perimetro da difendere a sistema da governare

Nel 2026 la cybersecurity evolve definitivamente da disciplina difensiva a leva strategica per la resilienza aziendale. Il modello tradizionale, basato sulla fiducia implicita verso fornitori, tecnologie e connessioni, non regge più di fronte a un ecosistema digitale in continua trasformazione. L’instabilità geopolitica, la crescita degli attacchi alla supply chain e la convergenza tra IT, OT e IoT stanno ridefinendo il concetto stesso di perimetro.

Ma il vero punto di rottura è un altro: la supply chain, dal punto di vista cyber, non è più una catena.

È diventata un sistema distribuito, continuo e non deterministico, in cui ogni nodo, che sia un fornitore, un dispositivo o un servizio digitale, è parte integrante dell’infrastruttura. Le relazioni non sono più lineari, ma dinamiche: cambiano nel tempo, si espandono, si intersecano. In questo contesto, il rischio non è più esterno all’organizzazione, ma intrinseco al suo funzionamento quotidiano.

Terze Parti e accessi persistenti: perché il Third Party Risk Management tradizionale non basta più

Il tradizionale approccio al Third Party Risk Management (TPRM), basato su valutazioni periodiche e controlli di compliance, nasce in un mondo statico. Oggi, invece, gli accessi sono persistenti, le integrazioni sono continue e le dipendenze tecnologiche spesso non completamente visibili. Non è più sufficiente sapere chi è un fornitore affidabile: è necessario comprendere come quel fornitore interagisce in tempo reale con sistemi, dati e processi.

La convergenza tra IT, OT e IoT amplifica ulteriormente questa complessità. Sistemi OT progettati per ambienti isolati convivono oggi con infrastrutture IT distribuite e dispositivi IoT difficilmente governabili. Oggi anche un accesso legittimo, una manutenzione remota, un aggiornamento software o l’utilizzo di un servizio esterno, può trasformarsi in un vettore di compromissione.

Shadow Risk e dipendenze invisibili: legacy, AI non governata e supply chain indirette

A rendere il quadro ancora più critico contribuisce l’emergere di rischi meno visibili ma sempre più rilevanti: tecnologie legacy non aggiornabili, supply chain indirette difficili da tracciare, utilizzo non governato di strumenti di intelligenza artificiale e servizi gratuiti che introducono potenziali canali di esposizione dei dati. Questi elementi non rappresentano eccezioni, ma fanno ormai parte della normalità operativa delle organizzazioni.

Se il contesto è così dinamico, l’ approccio alla sicurezza non può essere statico.

Non basta prevenire: è necessario comprendere il comportamento dell’infrastruttura e reagire in modo coerente con il contesto.

È qui che si afferma un nuovo paradigma, in cui la cybersecurity evolve verso la cyber resilience. Non più una difesa centralizzata basata su regole generiche, ma una capacità distribuita di rilevare anomalie, correlare eventi e attivare risposte automatiche direttamente dove il rischio si manifesta.

In questa direzione, piattaforme come Agger rappresentano un’evoluzione concreta. La possibilità di adattare le regole di detection e reaction al singolo endpoint, unita alla correlazione cross-layer e all’automazione nativa, consente di ridurre drasticamente il tempo di risposta e di limitare l’impatto degli incidenti anche in ambienti complessi e interconnessi.

Nella supply chain digitale contemporanea, la sicurezza non è più un perimetro da difendere, ma un sistema da comprendere, governare e rendere resiliente.

Sovranità tecnologica e cloud: quando la dipendenza dagli hyperscaler diventa un vincolo operativo

La sovranità tecnologica è uno di quei concetti che, per anni, abbiamo trattato come una questione di posizionamento strategico, quasi astratta, finché i numeri non hanno iniziato a raccontare una storia molto più concreta – e decisamente meno rassicurante.

Oggi oltre il 70% del mercato cloud europeo è nelle mani dei tre grandi hyperscaler statunitensi, mentre i provider europei si fermano intorno al 15% (TechRadar) e, guardando ancora più in profondità, il 53% della capacità installata nei data center europei è concentrata in soli dieci operatori, sette dei quali americani.

Se ci si ferma qui, il tema sembra già chiaro.

Ma il punto interessante non è la concentrazione, è come viene percepita.

Secondo ZeroUno, il 54% delle grandi imprese europee non considera i provider locali realmente competitivi, e il 37% delle aziende italiane sta valutando – o ha già avviato – strategie di repatriation.

E qui emerge una tensione che vale la pena osservare con attenzione.

Da una parte, la dipendenza da pochi attori globali non è più discutibile, è un dato strutturale; dall’altra, quando si tratta di ridurla, le alternative vengono percepite come insufficienti, creando una situazione in cui la consapevolezza del problema cresce più velocemente della capacità di risolverlo.

È in questo spazio che la sovranità tecnologica smette di essere un obiettivo politico e diventa un vincolo operativo.

Perché non si tratta semplicemente di dove risiedono i dati, ma di chi controlla realmente:

• l’infrastruttura;
• i modelli di accesso;
• le logiche di gestione;
• e, in ultima analisi, le condizioni operative del business.

Non è un caso che, nonostante la crescita degli investimenti nel cloud sovrano, gli stessi hyperscaler continuino a dominare il mercato europeo, anche quando si parla di servizi “sovrani”.

Il che apre una domanda meno comoda, ma inevitabile. Se l’infrastruttura è localizzata, ma il controllo resta altrove, possiamo davvero parlare di sovranità?

O, più realisticamente, stiamo ridefinendo il problema senza risolverlo? Forse il punto non è costruire un’alternativa totale – che oggi, semplicemente, non esiste – ma iniziare a leggere la dipendenza per quello che è: non un rischio eventuale, ma una condizione già integrata nei modelli operativi.

E a quel punto la domanda cambia. Non è più “come diventare sovrani”.

Ma quanto margine di autonomia rimane quando le scelte tecnologiche sono già, in larga parte, vincolate a monte.

Articolo presente su Ict Security Magazine

L'articolo Oltre le Terze Parti, la cybersecurity della supply chain nel 2026 proviene da Gyala.