Cyber Security 360

Ottobre è il mese europeo della cybersecurity, quello dei webinar sulla consapevolezza e dei poster in sala mensa. L’Italia lo chiude con il numero più imbarazzante dell’anno, certificato dal CSIRT nazionale nell’alert AL01/261025: su 741.523 servizi PHP rilevati nel Paese, 285.149 usano versioni potenzialmente vulnerabili a PHP2Shell. L’81,9%. Indice degli argomenti Prima di correre a ripubblicare la percentuale, fermiamoci sul denominatore, perché è qui che la maggior parte dei resoconti scivola. Quell’81,9% non è calcolato sui 741.523 servizi totali, ma sui 348.130 per i quali è stato possibile identificare la versione in uso: 285.149 diviso 348.130, non diviso il totale. Sul totale, i vulnerabili accertati sono il 38,5%. Qualcuno potrebbe tirare un sospiro di sollievo: “ah, quindi è meno della metà”. Sbagliato, ed è il sospiro di sollievo più pericoloso del mese. I restanti 393.393 servizi non sono sicuri: sono ignoti. Non espongono la versione, il che significa che nessuno — nemmeno chi li gestisce, in molti casi — sa dire se siano patchati. Chi fa questo mestiere sa che un sistema di cui non conosci lo stato è un sistema di cui devi assumere il peggio. La formula onesta, quindi, è questa: più di otto servizi PHP su dieci, tra quelli di cui si conosce la versione, risultavano vulnerabili al 25 ottobre. E la fonte del dato di esposizione è Censys, cioè scansione passiva di ciò che è visibile da Internet: lo stesso identico censimento che un attaccante può fare, gratis, in un pomeriggio. PHP2Shell è il nome collettivo di due vulnerabilità di remote code execution nell’interprete PHP, entrambe con CVSS v4.0 di 9,2 assegnato dal team di sicurezza PHP (il 10,0 circolato prima del rilascio è stato smentito dalla PHP Foundation). CVE-2026-109618 è una corruzione di memoria innescata in condizioni di out-of-memory, legata alla gestione impropria di longjmp(); CVE-2026-109619 è una RCE da “stale global state”, che Rapid7 classifica come use-after-free. Il vettore, descritto anche dal CSIRT Toscana, è brutale nella sua semplicità: richieste HTTP multipart appositamente costruite, da remoto, senza autenticazione. Secondo CISA colpiscono tutte le installazioni PHP che servono richieste web, con il rischio massimo su Apache con mod_php, dove l’attacco può scattare prima ancora che venga eseguita una sola riga del codice applicativo. Tradotto: non importa quanto sia scritto bene il vostro gestionale — la falla sta sotto, nell’interprete. Le patch esistono dal 21 ottobre, e la tabella è corta da leggere e lunga da applicare: Per chi è fermo a PHP 8.1 o prima, il CSIRT è lapidario: il vendor non rilascerà patch né workaround. Tenable segnala backport minimali per i rami 7.4–8.1 e nulla per 5.4–7.3 — e chiunque abbia mai messo mano a un parco server italiano sa quanti CMS dimenticati girano ancora lì sopra. Un esempio che dovrebbe far riflettere sul concetto di “PHP nascosto nei prodotti”: PAN-OS 12.1 e 12.2, cioè firewall Palo Alto, incorporano PHP 8.0.30. Il vostro inventario di PHP non coincide con la lista dei vostri siti web. Le note di rilascio della 8.2.35 chiudono ogni discussione sulle mezze misure: non esistono mitigazioni complete, aggiornare è l’unica scelta sicura. Il 28 ottobre CISA ha aggiunto al catalogo KEV una terza vulnerabilità, con una nota che è il vero titolo di questa storia: può essere concatenata con le due CVE di PHP “per installare webshell PHP ed eseguire comandi come root”. Si chiama Fragnesia, è la CVE-2026-46300, e qui serve subito un chiarimento che metà della stampa ha mancato: non è una falla PHP e non ha CVSS 9,2. È una local privilege escalation nel kernel Linux — sottosistema XFRM, gestione ESP-in-TCP — con CVSS 3.1 di 7,8. Red Hat la classifica “Important” e non “Critical” proprio perché richiede accesso locale. Il punto è che PHP2Shell quell’accesso locale lo regala. La parte tecnicamente elegante, e il motivo del nome: durante la coalescenza dei buffer di rete (skb), il kernel “dimentica” che un frammento è condiviso. La decifratura ESP in-place finisce così per scrivere dove non dovrebbe — sulla page cache di file di sola lettura. La proof of concept pubblica corrompe la copia in cache di /usr/bin/su e ottiene root. Non serve modificare il file su disco: basta avvelenare la sua immagine in memoria, che è quella che il sistema esegue. Un dettaglio che vale una pillola operativa: sui sistemi già compromessi, avverte CloudLinux, la sola patch non basta, perché la page cache avvelenata e gli eventuali impianti sopravvivono alla correzione della falla. E qui l’ironia amara: Fragnesia non è nuova. È stata divulgata il 13 maggio 2026 da William Bowling, con tanto di PoC pubblica, e secondo il ricercatore Hyunwoo Kim è stata attivata accidentalmente proprio dalla patch per Dirty Frag, la falla della stessa famiglia. Cinque mesi di preavviso. A maggio Tenable annotava che non era nel catalogo KEV; oggi c’è, con scadenza di remediation per le agenzie federali USA fissata al 31 ottobre. La falla ha aspettato pazientemente che qualcuno le costruisse intorno la catena giusta. L’attaccante non ha avuto fretta: ha avuto metodo. Fin qui la teoria delle CVE. Come si combinano nella pratica lo ha documentato la società israeliana Dream Security, su una campagna reale contro apparati di rete perimetrali — il tipo di ricostruzione che va presa come allerta qualificata e non come verità giudiziaria, perché l’attribuzione finale non è confermata in modo indipendente. Il percorso, però, è istruttivo e vale più di mille slide sulla “defense in depth”. [embedded content: la catena di exploit · 4 stadi, da RCE web a root] Quattro stadi. Primo, PHP2Shell con un exploit su misura — non pubblico, in quattro fasi — porta all’esecuzione di comandi come utente nobody, quello con cui gira il web server: privilegi minimi, la classica rete di contenimento. Secondo, qui entra Fragnesia: sovrascrive in page cache /etc/pam.d/su con pam_permit.so, e da quel momento il comando su concede root senza chiedere la password. Terzo, l’attaccante piazza una web shell PHP da 103 byte — centotré — e apre un tunnel SSH inverso. Quarto, pivot verso il server interno di gestione del firewall, raccolta di credenziali LDAP e tentativi su Active Directory. I numeri della campagna raccontano il metodo: partendo da circa 19.000 firewall esposti individuati con il motore di ricerca FOFA, l’attaccante ha ristretto il bersaglio a 240 apparati tra Stati Uniti, Giappone, Taiwan e Corea del Sud, compromettendone 24, con i colpi concentrati tra il 23 e il 24 ottobre. Il ricercatore Kfir Fleischer di Dream aggiunge il dettaglio che toglie ogni illusione di complessità: contro un apparato specifico, con gli offset precalcolati dal firmware, solo circa il 10% dei tentativi andava a segno, e la maggior parte dei fallimenti erano timeout. Non un bisturi infallibile, ma un martello che colpisce in fretta: la catena completa, quando funziona, si chiude in meno di quindici minuti. Il contenimento del “gira solo come nobody” è esattamente lo strato che Fragnesia cancella. Se c’è un dato che riassume l’anno, lo ha messo in fila Ross McKerchar, CISO di Sophos, in un post intitolato senza mezzi termini “The breachpocalypse is here”. Citando il report AI Security 2026 della sua azienda: Ivanti Sentry (CVE-2026-10520) sfruttata entro 24 ore dalla pubblicazione di una proof of concept, LiteLLM (CVE-2026-42208) entro 36. La finestra tra divulgazione e sfruttamento non si misura più in settimane o giorni: si misura in ore. Lo stesso post riporta una frase che pesa più di qualsiasi grafico: il 19 ottobre l’ex direttore cybersecurity della NSA, Rob Joyce, ha scritto che le società di incident response sono sature e stanno rifiutando lavoro. Quando chi dovrebbe spegnere gli incendi ha la coda fuori dalla porta, il calcolo del rischio cambia: non potete più contare sul “chiamiamo i pompieri quando succede”, perché i pompieri sono già impegnati altrove. Detto questo, un articolo onesto deve anche raffreddare l’allarme dove i numeri lo raffreddano. Lo stesso McKerchar ammette che PHP2Shell, finora, non è diventato l’evento di sfruttamento di massa per cui in molti si erano preparati. GreyNoise ha rilevato almeno sei sfruttamenti riusciti delle due CVE PHP, non migliaia; Amazon aveva osservato tentativi già dal 17 ottobre, quattro giorni prima della divulgazione ufficiale, segno che qualcuno le conosceva in anticipo, ma la valanga annunciata non si è (ancora) materializzata. Questo non è un motivo per rilassarsi: è il motivo per cui la finestra per agire è aperta adesso. La differenza tra chi patcha questa settimana e chi lo scopre tra un mese è esattamente la differenza tra sei sfruttamenti e il numero che leggeremo nel prossimo Rapporto Clusit. L’81,9% italiano è un invito a cena ancora apparecchiato: dipende solo da quanti decideranno di presentarsi come ospiti o come portata. Le raccomandazioni ufficiali convergono, ed è raro che ACN, CISA e NSA dicano la stessa cosa con questa compattezza. ACN e CSIRT: aggiornare subito, verificando che la patch sia davvero applicata anche quando i pacchetti arrivano dalle distribuzioni — perché “il repository dovrebbe averlo aggiornato” non è una verifica, è una speranza. WAF in modalità blocco solo se esistono regole specifiche per queste CVE, non le regole generiche di sei mesi fa. E, formula che vale la pena rileggere due volte, in assenza di mitigazioni efficaci valutare di porre offline i servizi: lo mette per iscritto anche la NSA. Un servizio spento non viene bucato, e tra l’imbarazzo di un downtime pianificato e quello di un data breach la scelta economica è ovvia a chiunque sappia leggere un conto. CISA aggiunge il punto che in Italia viene sistematicamente ignorato: fare inventario del PHP nascosto dentro altri prodotti, non solo dei siti web — il caso dei firewall Palo Alto con PHP 8.0.30 dovrebbe bastare come promemoria. E monitorare i processi: un worker PHP che lancia una shell o scarica strumenti è un segnale che nessun antivirus da solo intercetta, ma che un occhio sui log coglie subito. Dal 23 ottobre CISA fornisce anche una regola SIGMA pronta all’uso per chi ha un SIEM. Ci sono due trappole operative da conoscere. La prima: alcune mitigazioni temporanee hanno effetti collaterali — disabilitare session.upload_progress, togliere il memory_limit — e vanno trattate come toppe provvisorie, non come soluzioni. La seconda: nel caso specifico di IceWarp esiste una terza CVE, la CVE-2026-115560, che richiede di disabilitare session.upload_progress anche dopo aver applicato la patch. Il messaggio di fondo, scritto dai manutentori PHP stessi nelle note di rilascio, resta quello: non esistono mitigazioni complete, aggiornare è l’unica scelta sicura. Il mese della consapevolezza finisce oggi. La consapevolezza, quella vera, si misura dopodomani: non dal numero di webinar seguiti, ma da quanti di quei 285.149 servizi saranno ancora lì, con la stessa versione, quando ricominceremo a parlare d’altro. La domanda, allora, è una sola: il vostro PHP, quello che non sapevate nemmeno di avere, in quale metà della statistica vive? ACN/CSIRT — PHP2Shell: aggiornare immediatamente i sistemi vulnerabili (AL01/261025) Matrice Digitale — PHP2Shell, il CSIRT sui servizi PHP vulnerabili in Italia CISA — Two Known Exploited Vulnerabilities added to Catalog (26/10/2026) BleepingComputer — CISA warns of Fragnesia Linux flaw chained in PHP2Shell attacks Tenable — Fragnesia (CVE-2026-46300) FAQ Rapid7 — CVE-2026-109618 e CVE-2026-109619: RCE critiche in PHP Sophos — The breachpocalypse is here (Ross McKerchar) The Register — Suspected Chinese attackers rooted 25 servers with custom PHP2Shell exploit PHP — Note di rilascio 8.2.35

Domani, 31 ottobre 2026, l’Agenzia per la Cybersicurezza Nazionale chiude il canale delle dichiarazioni tardive NIS. Non è un’interpretazione allarmistica: lo scrive ACN stessa, nell’avviso pubblicato il 23 ottobre, nero su bianco. Da quella data, chi non si è ancora presentato all’appello non potrà più farlo attraverso la procedura tardiva, perché il portale verrà aggiornato per recepire le nuove regole. scadenza Registrazione NIS2: il 31 ottobre chiude il canale per i ritardatari Dal 31 ottobre ACN chiude il canale delle dichiarazioni tardive NIS. La Determinazione 314287/2026 semplifica gli adempimenti per le imprese già in elenco e introduce le procedure per il 2027. Restano gli obblighi di aggiornamento e le responsabilità dirette degli amministratori

L'attacco, con furto di 6,36 miliardi di dollari a Binance , sarebbe opera di TraderTraitor , gruppo di hacker collegato alla Corea del Nord . Ecco cosa sappiamo, perché riguarda anche l'Italia e come mitigare i rischi L'articolo Attacco a Binance: in 20 minuti la Nord Corea compie il furto cripto del secolo proviene da Cyber Security 360 .

Quante volte ci sorprendiamo nella vita? Domanda interessante. Piacevoli o meno, talvolta alcune sorprese riguardano anche noi stessi. Il modo in cui ci percepiamo e veniamo percepiti. Le persone di cui ci circondiamo, e con le quali costituiamo vere e proprie costellazioni. Questione prettamente umana, ma che diventa disumana nel momento in cui siamo un’organizzazione che non è stata in grado di comprendere quanto un partner tecnologico possa “pesare” sulla propria compliance. O quanto essa stessa si inserisca in qualche filiera per cui va lasciato ben poco spazio alla poesia dell’incertezza. Non sapere di essere parte di una filiera è il precipitato di una mancata analisi di contesto. Se infatti selezionare un fornitore, più o meno critico che sia, è qualcosa su cui, auspicabilmente, oramai si pone attenzione (facciamo che ci crediamo, ok?), avere una chiara consapevolezza di essere invece parte di una qualsivoglia supply chain spesso sfugge se si segue un approccio formalistico, limitandosi a un miope binomio in-scope/out-of-scope dal campo di applicazione diretto di una norma. In questo ambito, il socratismo del “so di non sapere” rappresenta un campanello d’allarme per noi, e una red flag per tutti i nostri stakeholder. Sapere o scoprire? Quando si abbandona il dominio della consapevolezza, che nella dimensione inumana dell’organizzazione è quello dell’analisi di contesto e nell’errore disumano porta a fin troppo facili compitazioni e compilazioni che sviano dalla realtà cercando più una checklist da esaurire una tantum. Cosa che non porterà mai all’essere selezionati come quel partner giusto, soprattutto nel momento in cui questa è una scelta di governance che impatta sui fattori critici di successo di ogni organizzazione. Anche perché, quali garanzie si è in grado di presentare o rappresentare, considerato che, ad esempio, in materia di servizi di sicurezza, l’attenzione a riguardo è massima? Se si sceglie di non sapere, nel momento in cui si scoprirà d’essere parte di una supply chain, di sicuro ci sarà una sorpresa. Poco piacevole, ma pur sempre una sorpresa. Per l’organizzazione, e per i suoi clienti.

Un attacco ransomware, una violazione di dati o il blocco di un sistema critico possono fermare la produzione, comportare sanzioni e danneggiare la reputazione di una organizzazione. Per questo il rischio cyber non è più una questione tecnica da lasciare al reparto informatico, bensì è un rischio d’impresa e, come tale, rientra nella responsabilità degli organi di vertice. All’interno del Consiglio di Amministrazione (il presidio spetta, in genere, al Comitato controllo e rischi (CCR) che assiste il vertice nel valutare il sistema di controllo interno e di gestione dei rischi, compresi quelli legati alla sicurezza delle informazioni. È importante evidenziare che, per esercitare davvero questa funzione, il comitato ha bisogno di dati affidabili, ed è qui che emerge la difficoltà più frequente: i team tecnici dispongono di enormi quantità di informazioni, mentre i membri del comitato devono ricevere indicazioni sintetiche, confrontabili nel tempo e utili a decidere. La reportistica di sicurezza diventa, così, il ponte tra questi due mondi. Se ben costruita, mette in luce dove l’azienda è vulnerabile, quanto sono efficaci le difese e se gli investimenti stanno producendo risultati. All’interno del Consiglio di Amministrazione, il presidio spetta, in genere al Comitato controllo e rischi (CCR), che assiste il vertice nel valutare il sistema di controllo interno e di gestione dei rischi, compresi quelli legati alla sicurezza delle informazioni. Per esercitare davvero questa funzione, però, il comitato ha bisogno di dati affidabili, e qui emerge la difficoltà più frequente. I team tecnici dispongono di enormi quantità di informazioni, ma i membri del comitato devono ricevere indicazioni sintetiche, confrontabili nel tempo e utili a decidere. La reportistica di sicurezza diventa il ponte tra questi due mondi e, se ben costruita, evidenzia le vulnerabilità, quanto sono efficaci le difese e se gli investimenti producono risultati. Indice degli argomenti Una buona reportistica si costruisce a partire dalle decisioni che il comitato deve poter assumere sulla base del documento: da questo obiettivo discendono contenuti, periodicità e livello di dettaglio. Il report non deve ridursi a un elenco di eventi tecnici, ma offrire un quadro ordinato, così strutturato: una sintesi dello stato complessivo del rischio; fatti rilevanti del periodo; gli indicatori principali; azioni in corso; le eventuali richieste di decisione. In termini di frequenza, la cadenza trimestrale è la più comune, affiancata da un meccanismo di segnalazione immediata per gli eventi gravi; mentre gli approfondimenti tecnici costituiscono gli allegati, a disposizione di chi desidera entrare nel dettaglio. Il comitato di controllo non gestisce la sicurezza, bensì la supervisiona. Di fatto, spetta alla direzione e alle funzioni operative definire e attuare i controlli. Il comitato, invece, verifica che: il sistema sia adeguato; i rischi siano identificati e valutati; le scelte siano coerenti con la propensione al rischio fissata dal Consiglio di Amministrazione. Inoltre, nelle società quotate questo ruolo si inserisce nel sistema di controllo interno previsto dal Codice di Corporate Governance, ma un presidio analogo è sempre più diffuso anche nelle imprese non quotate. Ancora, il comitato esamina le valutazioni del rischio e dialoga con il CISO (Chief Information Security Officer, il responsabile della sicurezza delle informazioni), con il responsabile IT (Information Technology), con il DPO (Data Protection Officer) e con le funzioni di internal audit e di risk management, per poi riferire al Consiglio. Il suo compito è anche porre le domande giuste: quali sono i sistemi più critici, quanto tempo servirebbe per ripristinarli, quali minacce sono più probabili, quali lacune restano aperte. È importante evidenziare che, affinché questa funzione sia efficace, i flussi informativi devono essere regolari e strutturati. Ovvero: devono evidenziare i progressi ottenuti nella riduzione della superficie d’attacco, fornendo indicatori chiari sul livello di copertura e mitigazione del rischio. Solo così il comitato può distinguere un miglioramento reale da una semplice attività di facciata. I dati prodotti dagli strumenti di sicurezza, come log, alert o numero di vulnerabilità rilevate, parlano il linguaggio dei tecnici. Pertanto, per renderli utili al Board è opportuno tradurli in termini di impatto sul business, collegando ogni metrica a un rischio concreto, esprimendolo, quando possibile, in termini economici od operativi. Una volta chiarito il significato delle metriche, conviene presentarne l’andamento nel tempo, anziché, il dato isolato, dato che il comitato deve poter cogliere la direzione di marcia e non solo la situazione di un singolo momento. A tale scopo funzionano possono essere di supporto le rappresentazioni sintetiche come le mappe di calore (heat map) dei rischi o i semafori verde-giallo-rosso, a condizione che i criteri di valutazione siano espliciti e stabili, così da rendere i confronti tra periodi realmente affidabili. Infine, le informazioni vanno graduate: poche metriche chiave in evidenza e il dettaglio tecnico a disposizione di chi vuole approfondire. Gli indicatori si dividono in due famiglie complementari, quali: KPI (Key Performance Indicator) misurano le prestazioni dei controlli, per esempio la percentuale di sistemi protetti o la rapidità di risposta. KRI (Key Risk Indicator) segnalano invece l’aumento dell’esposizione al rischio, per esempio il numero di vulnerabilità critiche non risolte o di accessi privilegiati privi di controllo. Presentarli insieme permette al comitato di valutare sia quanto le difese funzionano sia dove il rischio sta crescendo. Infine, si consiglia di selezionare pochi indicatori, stabili nel tempo. e associati a soglie di tolleranza approvate, oltre le quali scatta l’obbligo di segnalazione. Misurare la copertura delle difese significa verificare che i controlli dichiarati siano davvero attivi dove servono. Il primo passo è disporre di un elenco affidabile dei sistemi critici, individuati attraverso la valutazione dell’impatto sul business, perché senza un inventario aggiornato qualsiasi percentuale rischia di essere fuorviante. Su questa base si calcola, per ciascun controllo, la quota di sistemi critici effettivamente protetti. Gli indicatori più utilizzati riguardano la presenza di strumenti EDR (Endpoint Detection and Response), l’adozione dell’MFA (Multi-Factor Authentication), la cifratura dei dati, l’invio dei log al SIEM (Security Information and Event Management) e la quota di sistemi aggiornati con le patch. Inoltre, alla protezione preventiva si affianca la capacità di ripristino che si misura attraverso due parametri fissati per ogni sistema critico: l’RTO (Recovery Time Objective) – i.e. il tempo massimo tollerabile di fermo prima che l’impatto sul business diventi inaccettabile -e l’RPO (Recovery Point Objective) – i.e. la quantità massima di dati che l’azienda può permettersi di perdere, espressa come intervallo di tempo tra l’ultimo salvataggio utile e l’incidente. Ancora, per il comitato, è essenziale conoscere la percentuale di sistemi critici i cui backup e le cui procedure di ripristino, verificati con prove periodiche, rispettano davvero gli obiettivi fissati di RTO e RPO: un backup mai testato offre soltanto una sicurezza apparente. Accanto alla copertura va misurata l’efficacia, cioè la rapidità con cui l’organizzazione reagisce a un evento. In tal senso sono importanti sia il MTTD (Mean Time To Detect) sia il MTTR (Mean Time To Respond) che indicano in quanto tempo ci si accorge di un incidente e in quanto tempo lo si contiene. È importante evidenziare che confrontare questi valori con gli obiettivi di RTO e RPO consente di capire se la capacità di reazione è compatibile con la tolleranza al fermo stabilita per ciascun sistema. Il dato più prezioso, tuttavia, è l’elenco dei sistemi critici non ancora coperti o che non rispettano gli obiettivi di ripristino, accompagnato dalle ragioni dello scostamento e dalla data prevista per la chiusura. Di fatto, un comitato che vede dove le difese mancano può intervenire; uno che riceve solo percentuali rassicuranti rischia di sottovalutare l’esposizione. L’organizzazione, l’azienda quando una valutazione o un test rivelano delle debolezze, predispone un remediation plan, cioè un programma di interventi con responsabili, scadenze e priorità, in modo tale da darne evidenza al comitato. Di fatto, una rendicontazione efficace parte dalla priorità. Le vulnerabilità vanno classificate in base alla gravità – spesso espressa con il punteggio CVSS (Common Vulnerability Scoring System – e alla reale esposizione del sistema coinvolto. Per ciascuna fascia si indicano le vulnerabilità aperte, quelle chiuse nel periodo, l’anzianità media e gli scostamenti rispetto ai tempi massimi di correzione, definiti dagli SLA (Service Level Agreement). Particolare attenzione meritano le vulnerabilità scadute e le eccezioni: quelle non risolte entro i termini vanno evidenziate insieme alla causa del ritardo; mentre le deroghe, cioè i casi in cui si accetta di convivere con un rischio, devono essere motivate, approvate da un responsabile e dotate di una data di riesame. L’efficacia del programma di bonifica si rappresenta al meglio con un grafico che metta a confronto nel tempo le vulnerabilità critiche risolte e quelle ancora aperte: se le prime crescono e le seconde diminuiscono, il piano sta producendo risultati. La reportistica non è solo uno strumento di gestione: è la prova che gli organi di vertice hanno esercitato la propria funzione di vigilanza. Il quadro normativo europeo ha rafforzato questa responsabilità. La direttiva NIS2, recepita in Italia con il D.lgs. 138/2024, attribuisce agli organi di gestione il compito di approvare le misure di gestione del rischio cyber e di supervisionarne l’attuazione, con obblighi di formazione e possibili responsabilità personali. DORA, per il settore finanziario, assegna all’organo di gestione la responsabilità finale sul rischio ICT. A queste norme si aggiungono il GDPR, che richiede di poter dimostrare l’adeguatezza delle misure a tutela dei dati personali, e il D.lgs. 231/2001, in base al quale un modello organizzativo efficace, vigilato con continuità, può contribuire a escludere la responsabilità dell’ente. È doveroso evidenziare che, in tutti i casi, una reportistica ordinata e conservata nel tempo, è il modo più concreto per dimostrare di aver adempiuto ai requisiti normativi. Le autorità di vigilanza, come l’ACN (Agenzia per la Cybersicurezza Nazionale) o le autorità del settore finanziario, non pretendono che i controlli esistano: l’organizzazione deve dimostrare di monitorarli con continuità. Pertanto, la documentazione va costruita come una catena ordinata di prove che accompagni l’intero ciclo di gestione del rischio, i.e. dalla valutazione alla decisione, fino alla verifica dei risultati. Si tratta di strutturare la documentazione del comitato: i verbali attestano quali informazioni sono state ricevute, quali domande sono state poste e quali decisioni sono state assunte, mentre i report periodici, archiviati con data e versione, permettono di ricostruire come si è evoluta la situazione nel tempo. È altresì importante disporre del registro dei rischi, che raccoglie i piani di trattamento e il rischio residuo approvato dalla direzione, unitamente alle evidenze operative: test, esercitazioni e incidenti gestiti, ciascuno con le relative azioni correttive. La continuità del controllo si dimostra anche nel modo in cui vengono seguiti gli indicatori. Il monitoraggio rispetto alle soglie di tolleranza, con la segnalazione tempestiva dei superamenti senza attendere la riunione successiva, prova che il presidio è attivo anche tra una seduta e l’altra. Inoltre, è altrettanto importante la tracciabilità delle decisioni: quando il comitato chiede approfondimenti, rinvia un intervento o accetta un rischio, il verbale deve renderlo esplicito, indicandone motivazioni e responsabili. In sede ispettiva, l’insieme di questi documenti permette di passare dalla semplice dichiarazione di principio alla prova concreta, trasformando la governance in una pratica dimostrabile. Il valore più concreto di una buona reportistica è la capacità di orientare il budget. Di fatto, quando i dati mostrano dove le difese sono carenti, quali vulnerabilità pesano di più e quanto potrebbe costare un incidente, le richieste di investimento smettono di essere percepite come una voce di costo generica e diventano scelte motivate. Si tratta di mettere in relazione ogni proposta di spesa con un rischio misurato. Di fatto, se il report evidenzia, per esempio, che una parte dei sistemi critici non dispone di autenticazione a più fattori, l’investimento per estenderla è giustificato dalla riduzione attesa dell’esposizione. Inoltre, strumenti come la stima della perdita attesa o l’analisi costi-benefici aiutano a confrontare alternative diverse e a stabilire priorità; mentre il rischio residuo dopo ciascun intervento permette al comitato di capire quanto margine di miglioramento rimane. Ancora, il confronto con le soglie di tolleranza al rischio indica inoltre quando è opportuno investire ancora e quando, invece, ulteriori spese produrrebbero solo benefici marginali. La supervisione delle minacce cyber da parte del Comitato controllo e rischi è efficace quando si basa su informazioni chiare, regolari e orientate alle decisioni. Di fatto, la reportistica deve tradurre i dati tecnici in metriche comprensibili per il Board; gli indicatori di prestazione e di rischio forniscono una misurazione della copertura delle difese e l’avanzamento dei recovery plan; la documentazione conservata nel tempo dimostra il controllo continuo davanti alle autorità; e gli stessi dati diventano il criterio per orientare gli investimenti in sicurezza. Non si tratta di aggiungere burocrazia, ma di mettere i vertici nelle condizioni di esercitare la propria responsabilità con cognizione di causa. In questa prospettiva anche il CISO, aprendosi al dialogo con le funzioni di business, contribuisce a rendere il rischio cyber una questione condivisa e non più una competenza confinata all’area tecnica. Pertanto, investire nella qualità dei flussi informativi significa dunque rafforzare la governance, ridurre l’esposizione al rischio e fare della sicurezza una componente stabile della gestione d’impresa.

Microsoft Teams è diventato un nuovo punto di ingresso per gli attacchi informatici basati sull’ingegneria sociale. A evidenziarlo è un’analisi pubblicata da Arctic Wolf Labs che descrive oltre 400 incidenti nei quali i criminali hanno sfruttato le chat esterne della piattaforma per impersonare il personale di supporto IT e ottenere un primo accesso agli ambienti aziendali. L’attività non richiederebbe lo sfruttamento di vulnerabilità di Microsoft Teams, ma farebbe leva sulla fiducia degli utenti e sulla possibilità di avviare conversazioni tra organizzazioni diverse. Come noto, Microsoft Teams consente per impostazione predefinita la comunicazione con utenti di altre organizzazioni Microsoft365, se entrambi i tenant autorizzano l’accesso esterno. Gli aggressori starebbero sfruttando proprio questa funzionalità legittima per contattare i dipendenti e avviare attacchi di ingegneria sociale, senza dover sfruttare vulnerabilità del software. Indice degli argomenti La campagna utilizzava identità create appositamente per sembrare riconducibili al reparto informatico dell’azienda. In pratica i criminali adottavano nomi come “IT Support”, “Help Desk Manager” o “IT Service Desk”, aggiungendo talvolta un nome proprio e la dicitura “Internal” per suggerire un’origine interna. In diversi incidenti, il contatto fraudolento sarebbe stato preceduto da una tecnica nota come mail bombing, che consiste nell’inviare alla vittima centinaia di e-mail automatiche, spesso sotto forma di iscrizioni a newsletter o conferme di registrazione con l’obiettivo di creare confusione e generare urgenza. Poco dopo interveniva il falso tecnico proponendo di risolvere il problema e inducendo il dipendente a fidarsi. Fonte: Arctic Wolf Labs. Secondo l’analisi, per costruire queste identità, gli attaccanti utilizzavano spesso tenant Microsoft365 appena creati o acquisiti. Inoltre, nel 30-40% dei casi analizzati comparivano domini predefiniti “.onmicrosoft[.]com”, che possono essere utilizzati per configurare rapidamente un ambiente Teams, mentre tra i domini a pagamento osservati, circa il 50% utilizzava l’estensione [.]top, mentre il 40% ricorreva a [.]com. In tutti i casi gli aggressori sceglievano spesso nomi che richiamavano aggiornamenti di sicurezza e assistenza tecnica e spesso configuravano i domini in modo da reindirizzare le richieste verso siti legittimi, aumentando l’apparente credibilità dell’identità utilizzata. Una volta stabilito il contatto, l’obiettivo era convincere la vittima ad avviare una sessione di assistenza remota. Tra gli strumenti individuati figuravano Quick Assist, AnyDesk, ScreenConnect, TeamViewer, Atera, Zoho Assist, NetSupport e LogMeIn. Mentre Quick Assist è particolarmente utile agli aggressori perché è integrato in Windows e consente di avviare una sessione senza installare un programma aggiuntivo, in altri casi, i criminali introducevono successivamente strumenti commerciali di Remote Monitoring and Management (RMM) per mantenere un canale di accesso indipendente. Arctic Wolf ha descritto anche una catena di infezione nella quale il falso addetto IT convinceva l’utente a eseguire un comando PowerShell. In tal caso il comando scaricava un pacchetto MSI ospitato su Azure Blob Storage, contenente uno script PowerShell e un archivio ZIP. La catena che si avvia portava all’estrazione di un interprete Python e di un impianto malevolo eseguito tramite pythonw/.exe e deputato all’invio di query LDAP ad Active Directory per raccogliere informazioni sugli utenti e sui computer dell’organizzazione da trasmettere ai server di comando e controllo. La prima misura consiste nel limitare l’accesso esterno di Teams alle sole organizzazioni con cui esistono rapporti di collaborazione effettivi, utilizzando una lista di domini autorizzati. È inoltre opportuno bloccare le comunicazioni provenienti da account non gestiti quando non necessarie e impedire l’accesso ai tenant utilizzati dagli aggressori. Le aziende dovrebbero anche restringere l’uso di Quick Assist al personale autorizzato, controllare l’esecuzione di strumenti RMM non approvati e correlare gli eventi di Teams con i log degli endpoint e delle identità. Sul piano organizzativo, qualsiasi richiesta di assistenza remota non sollecitata dovrebbe essere verificata attraverso un canale indipendente. Il dato più importante dell’analisi è che la difesa non può concentrarsi esclusivamente sul rilevamento dei malware. In questa tipologia di attacco, il primo segnale può essere la creazione di una chat esterna sospetta. Individuarla tempestivamente, prima che il dipendente interagisca con il falso tecnico, può interrompere la catena di compromissione.

I piani di Hosting web di Hostinger arrivano al Black Friday con sconti fino all’85%, tariffe promozionali a partire da 1,99 euro al mese e strumenti per creare e gestire siti, negozi online e applicazioni. L’offerta di Hostinger comprende soluzioni per diverse esigenze operative, dai blog ai progetti professionali, fino agli ambienti VPS dedicati. Tra le novità figurano anche crediti AI raddoppiati, domini gratuiti per un anno e funzionalità di automazione. Hostinger propone inoltre formule con pagamento anticipato e rinnovo automatico, un elemento da considerare nel calcolo del costo effettivo del servizio. Indice degli argomenti Le promozioni di Hostinger riguardano tre principali piani di hosting condiviso, con differenti capacità di archiviazione e strumenti per la gestione dei progetti online. Il piano Premium parte da 1,99 euro mensili e permette di gestire tre siti web. Include 20 GB di archiviazione SSD, dominio gratuito per un anno, backup settimanali e CDN. Sono disponibili WordPress, AI Builder e Node.js. Il pacchetto comprende anche due caselle email per sito, gratuite per il primo anno, e assistenza prioritaria 24/7. La soluzione Unlimited, invece, elimina i limiti sul numero di siti web e caselle email. Offre 50 GB di spazio NVMe, backup giornalieri, CDN e dominio gratuito per un anno. Integra inoltre un servizio e-commerce gratuito per tre mesi, con prodotti illimitati, oltre 100 metodi di pagamento e commissioni di transazione dello 0%. Per i negozi online strutturati c’è Ecommerce Startup, con 100 GB di archiviazione NVMe, backup giornalieri e su richiesta, siti illimitati e caselle email senza limiti. Anche questo piano comprende l’e-commerce integrato senza commissioni di transazione. Le tariffe mensili di Hostinger derivano dalla suddivisione del costo complessivo anticipato per la durata contrattuale. Ecco il confronto tra prezzi promozionali, importi iniziali e canoni successivi. Il costo iniziale non coincide quindi con una spesa mensile effettiva: occorre versare anticipatamente l’intero importo del periodo selezionato. Il rinnovo automatico applica inoltre un canone superiore a quello promozionale. La disdetta resta possibile in qualsiasi momento. Per applicazioni web, server e progetti con esigenze tecniche più specifiche sono disponibili quattro configurazioni VPS KVM. La versione base offre 1 vCPU, 4 GB di RAM, 50 GB NVMe e 4 TB di larghezza di banda. Il modello KVM 8 arriva invece a 8 vCPU, 32 GB di RAM, 400 GB NVMe e 32 TB di larghezza di banda. Tutti i piani includono processori AMD EPYC, rete da 1 Gbps, gestione del firewall, API pubblica, terminale web AI e backup settimanali gratuiti. La presenza di risorse crescenti consente di scegliere la configurazione in base alle necessità applicative e ai carichi di lavoro. L’offerta integra AI Builder per creare siti, applicazioni e negozi online attraverso istruzioni testuali, con possibilità di intervenire successivamente tramite chat AI o modifiche drag and drop. Tra gli strumenti disponibili figura anche Hostinger Agent, un assistente che supporta attività di migrazione, manutenzione, modifica e gestione dei siti. La piattaforma integra inoltre strumenti di email marketing AI e automazioni, con ulteriori funzionalità disponibili attraverso integrazioni e abilità aggiuntive. Sul fronte della protezione dei dati, il provider dichiara la certificazione ISO/IEC 27001:2022 e la conformità al GDPR. Specifica inoltre che le conversazioni con il proprio assistente AI non vengono utilizzate per addestrare modelli né condivise con terze parti per finalità pubblicitarie. La promozione comprende infine una garanzia di rimborso entro 30 giorni e la migrazione gratuita dei siti esistenti.

Un provider di servizi gestiti del settore telecomunicazioni ha subito una violazione attraverso la console centrale che amministrava centinaia di firewall di terzi. Gli attaccanti hanno prelevato configurazioni, credenziali e chiavi di oltre 500 FortiGate e su alcuni di essi hanno installato PEERSTITCH, un impianto che vive solo in memoria e non apre nemmeno una connessione. È il caso di scuola di quello che la NIS2 chiama sicurezza della catena di approvvigionamento, e che nelle PMI italiane viene di solito gestito con una firma in calce a un contratto di manutenzione. Indice degli argomenti C’è un momento, in ogni progetto di esternalizzazione, in cui qualcuno dice la frase magica: “tanto il firewall lo gestisce il fornitore”. Da quel momento la sicurezza del perimetro smette di essere un problema dell’azienda e diventa un atto di fede. Funziona benissimo, finché qualcuno non va a controllare in che stato è la console da cui il fornitore governa tutti i firewall di tutti i suoi clienti. Il 14 ottobre 2026 l’unità di ricerca Unit 42 di Palo Alto Networks ha pubblicato la ricostruzione di un’intrusione che a quella console è arrivata davvero. Il report descrive un provider di servizi gestiti (MSP) nel settore telecomunicazioni, compromesso a partire da settembre 2024 tramite la vulnerabilità CVE-2024-47575 di FortiManager, la piattaforma Fortinet usata per amministrare in modo centralizzato i firewall FortiGate. Dalla console gli attaccanti hanno portato via i dati di oltre 500 dispositivi gestiti e, in una fase successiva, hanno concatenato una seconda vulnerabilità, CVE-2025-61624, per diventare root su alcuni firewall e installare un malware inedito per architettura ARM64 battezzato PEERSTITCH. Prima di entrare nel dettaglio tecnico, due precisazioni di onestà intellettuale, perché in questo settore i titoli corrono più veloci dei fatti. Unit 42 attribuisce l’attività al cluster CL-STA-0954, che si sovrappone a quello che Mandiant traccia come UNC5820, e dice soltanto che alcuni aspetti dell’attività post-sfruttamento ricordano intrusioni attribuite a sospetti attori statali. Non indica nazione, non indica movente. Inoltre il numero “500 firewall” misura i dispositivi di cui sono stati esposti dati, non le reti dei clienti effettivamente violate: i ricercatori dichiarano espressamente di non aver esaminato le reti dei clienti dell’MSP. Chi scrive “500 firewall compromessi” sta aggiungendo un’enfasi che la fonte non autorizza. La sequenza, come la ricostruisce Unit 42, è lineare e per questo istruttiva. A settembre 2024 gli attaccanti sfruttano CVE-2024-47575 contro il FortiManager del provider. Fortinet pubblicherà il bollettino FG-IR-24-423 il 23 ottobre 2024, con punteggio CVSS 9.8, ma Mandiant aveva già osservato lo sfruttamento di questa falla a partire dal 27 giugno 2024 su altre vittime, stimando oltre 50 FortiManager potenzialmente compromessi in vari settori. Quindi la finestra di esposizione non è stata “poche ore prima della patch”: è stata mesi. Dopo l’accesso iniziale gli attaccanti registrano nella console un FortiGate virtuale falso, chiamato localhost, ed esfiltrano subito un archivio con i dati di gestione. Poi aspettano. Unit 42 parla di un lungo periodo di permanenza, e la pazienza è la parte più preoccupante: non c’è fretta di monetizzare, perché ciò che hanno in mano non scade da solo. Nelle fasi successive la console compromessa viene usata per spingere configurazioni di sniffing sui firewall gestiti, le credenziali recuperate dall’archivio vengono craccate, gli attaccanti entrano via VPN SSL, sfruttano la seconda vulnerabilità e installano l’impianto su una selezione di firewall. Un dettaglio che dovrebbe far riflettere ogni MSP: il numero di serie del dispositivo falso (FMG-VMTM23017412) e due degli indirizzi IP usati per registrarlo compaiono già nell’elenco degli indicatori di compromissione pubblicato da Fortinet nel 2024. Chi avesse controllato quei log nell’autunno di due anni fa avrebbe trovato la porta d’ingresso. Il punto non è il rimprovero, è la lezione: gli indicatori pubblici invecchiano bene solo se qualcuno li usa. CVE-2024-47575, soprannominata FortiJump, è una mancanza di autenticazione per una funzione critica (CWE-306) nel demone fgfmd di FortiManager, il servizio che parla il protocollo FGFM con i firewall gestiti, in ascolto sulla porta TCP 541. Un attaccante remoto non autenticato, con richieste costruite ad arte, può eseguire codice o comandi. Le versioni corrette sono la 7.6.1, 7.4.5, 7.2.8, 7.0.13, 6.4.15 e 6.2.13, con date e dettagli nel bollettino Fortinet. Pillola: perché registrare un dispositivo falso è così potente. In un’architettura FortiManager la fiducia è bidirezionale e basata su certificati: la console si fida dei firewall che ha enrolled e i firewall si fidano della console. Se un estraneo riesce a farsi accettare come “dispositivo gestito”, la console lo tratta come un cliente legittimo e, con il comportamento di default, gli consegna informazioni che a un estraneo non dovrebbe mai dare. Fortinet suggerisce di abilitare set fgfm-deny-unknown enable (dalle versioni 7.0.12, 7.2.5 e 7.4.3), di disattivare la registrazione automatica dei dispositivi non noti e, dalla 7.2.0, di limitare con una policy local-in la porta TCP 541 ai soli indirizzi IP dei FortiGate conosciuti. Sono tre righe di configurazione che separano una console amministrata da una console esposta. L’archivio sottratto dalla console, secondo Unit 42, contiene le configurazioni complete in esecuzione di oltre 500 FortiGate, i database globali di policy e oggetti, l’inventario con numeri di serie e indirizzi pubblici, le mappe di topologia, le tabelle di routing, le credenziali di amministratori, utenti locali e VPN SSL, e materiale crittografico codificato che comprende certificati pubblici e chiavi private. Per un attaccante questo non è un furto di dati, è il furto di un’identità tecnica. Chi possiede configurazione, chiavi e credenziali di un firewall non ha bisogno di sfondarlo: può presentarsi alla porta con le chiavi giuste. È infatti quello che è successo. Le credenziali erano conservate in una forma reversibile, cioè cifrate e non sottoposte a hashing a senso unico, e Unit 42 ha confermato che le password di amministratori e VPN SSL possono essere recuperate con attacchi di forza bruta partendo da quei dati. Gli attaccanti sono rientrati dalla porta principale, con un accesso VPN SSL perfettamente valido. Ecco il messaggio che il report ripete con una chiarezza che andrebbe appesa nelle sale riunioni: il materiale di fiducia resta valido finché non viene ruotato, e una compromissione non finisce quando la piattaforma viene aggiornata. Applicare la patch a FortiManager chiude la porta da cui sono entrati. Non annulla le copie delle chiavi che sono già uscite. Fortinet, nel suo bollettino del 2024, elenca che cosa andrebbe ruotato dopo una compromissione, e la lista è lunga e scomoda: account di amministrazione, chiavi private dei certificati (offload SSL, ispezione profonda, autenticazione IPsec), chiavi precondivise delle VPN, utenti locali, chiavi TACACS, password LDAP e Active Directory, segreti RADIUS e SNMP, password dei vicini OSPF e BGP, chiavi wireless, credenziali salvate negli stitch di automazione, chiavi HA. Domanda onesta: quante PMI italiane, a valle di un fornitore che ha “aggiornato la console”, hanno mai ricevuto la richiesta di ruotare tutto questo? La seconda vulnerabilità è il pezzo che fa capire perché i punteggi CVSS vanno letti nel contesto. CVE-2025-61624 è una path traversal (CWE-22) nell’interprete a riga di comando di FortiOS, ma anche di FortiPAM, FortiProxy e FortiSwitchManager, che consente a un utente già privilegiato di scrivere o cancellare file con argomenti costruiti ad arte. Fortinet la classifica come escalation di privilegi, la valuta CVSS 6.0 e richiede credenziali di amministratore. NVD la porta a 6.5. Numeri da “patcha quando hai tempo”. Il problema è che le credenziali di amministratore gli attaccanti le avevano già, grazie al furto precedente. Il meccanismo, descritto da Unit 42, riguarda l’oggetto system.auto- script: il nome dello script non viene sanificato, quindi un nome contenente sequenze ../ permette di scrivere il corpo dello script in un punto qualsiasi del filesystem, e lo script viene eseguito con i privilegi del motore di auto-script. In questo modo si esce dalla CLI ristretta di FortiOS, che non offre una shell nemmeno al super_admin, e si ottiene root. Nell’attacco osservato l’oggetto si chiamava ../../../../setup. Una falla che richiede privilegi alti sembra poco pericolosa finché qualcuno non ha già quei privilegi. Nella valutazione del rischio, il punteggio di un singolo anello va sempre riletto alla luce di ciò che l’attaccante possiede nel momento in cui lo usa. CISA ha aggiunto CVE-2025-61624 al catalogo delle vulnerabilità sfruttate (KEV) il 16 ottobre 2026, con scadenza al 19 ottobre e l’indicazione che serve un’analisi forense, non solo la patch. Le versioni FortiOS corrette sono la 7.6.5 e la 7.4.10, mentre per i rami 7.2, 7.0 e 6.4 non c’è correzione e serve migrare. Fortinet segnala anche una patch virtuale. Non è noto se la falla fosse sfruttata prima della divulgazione di aprile 2026: Unit 42 non fornisce la data di installazione dell’impianto, quindi chi scrive “zero-day” sta ipotizzando. Veniamo al protagonista. PEERSTITCH è un eseguibile Linux ARM64 scritto in C e collegato staticamente a glibc. Unit 42 lo descrive come un iniettore monouso che modifica la memoria di processi già in esecuzione: non è un demone residente, non si installa, non si mette in ascolto. Il componente principale, chiamato lldprx, si scarica nella directory /data2/template/ insieme ad altri quattro file (script di preparazione, runtime Emscripten, modulo WebAssembly e uno script orchestratore) e, dopo aver fatto il suo lavoro, cancella se stesso dal disco. Il lavoro consiste nel cercare nei processi /bin/miglogd, che gestisce il logging, e /bin/iked, che gestisce IKE e IPsec, leggere le loro mappe di memoria, agganciarli con ptrace (nella variante PTRACE_SEIZE), allocare un’area anonima di 16 KB in lettura, scrittura ed esecuzione e scrivere al suo interno un payload di 1.344 byte attraverso /proc/ /mem. Poi applica alcune patch: istruzioni NOP in tre punti del codice, che Unit 42 interpreta come la soppressione dei controlli anti-manomissione, e un breve trampolino che reindirizza l’esecuzione nel codice iniettato. Qui sta la parte brillante, e richiede una ricostruzione precisione perché in giro circola una versione imprecisa. PEERSTITCH non dirotta sessioni FGFM e non apre socket. I due ganci iniettati nei demoni cercano passivamente, dentro i dati che i demoni già gestiscono, due marcatori testuali: la stringa 8550 e l’indirizzo 169.254.0.1. Quando ne trovano uno estraggono un token fino a 31 byte e lo salvano in un buffer circolare, poi lo scrivono nell’altro demone attraverso /proc/ /mem. Quando iked gestisce una successiva sessione VPN che porta un tag corrispondente, prende un ramo di uscita alternativo che aggira i controlli di sicurezza predefiniti di FortiOS. In pratica il canale dell’attaccante è del contenuto costruito ad arte dentro traffico che il firewall registra o negozia già per mestiere. Nessuna porta nuova, nessuna connessione in uscita generata dall’impianto, niente che un firewall perimetrale o un IDS possano segnalare come anomalo. Il malware usa il firewall come mezzo di comunicazione. La costruzione di un secondo canale, distinto dal precedente e questo sì con traffico in uscita, è avvenuta abusando di Apache mod_md, il modulo che gestisce i certificati ACME: scrivendo un file di configurazione fuori posizione tramite la stessa falla di path traversal e iniettando argomenti shell nel campo del dominio, gli attaccanti hanno ottenuto una shell SSH inversa, rinnovata ripetutamente grazie all’opzione MDRenewMode always. È un altro esempio di come funzionalità legittime, in questo caso la gestione dei certificati, diventino il veicolo per l’accesso remoto. Quindi l’affermazione “nessuna connessione in uscita” vale per PEERSTITCH, non per l’intera intrusione. La parte di anti-forensics merita attenzione perché spiega perché questo tipo di incidente si scopre tardi. Gli attaccanti terminavano miglogd e syslogd prima di eseguire gli script, cancellavano i crash log con diagnose debug crashlog clear per eliminare le tracce dei tentativi di iniezione falliti, rimuovevano amministratori, gruppi VPN e oggetti auto-script creati per l’occasione e sovrascrivevano il file di configurazione di mod_md con un contenuto di copertura. Unit 42 ritiene con confidenza media che abbiano anche provocato perdite di telemetria sull’interfaccia di gestione dei tunnel. Un corollario tecnico di cui tenere conto: lo strumento di verifica dell’integrità dei file di Fortinet, che confronta ciò che è sul disco, non può vedere un impianto che sul disco non c’è. È un’inferenza coerente con il report, non una verifica diretta, ma ha una conseguenza pratica evidente: il fatto che il controllo di integrità risulti pulito non dimostra nulla. Unit 42 fornisce indicazioni di ricerca concrete. In memoria volatile, si devono ispezionare le mappe di miglogd e iked alla ricerca di regioni anonime di esattamente 16.384 byte con permessi rwxp. Si verifica l’integrità del codice dei demoni, cercando l’istruzione 0xAA0003E0 ai tre offset indicati nel report. Si cercano scritture su /proc/ /mem da parte di un demone verso l’altro. Il comando diagnose debug crashlog read può mostrare segnali 11 (segmentation fault) in miglogd, iked o syslogd, residui di iniezioni andate male. Infine, un controllo di configurazione sulle revisioni: qualunque oggetto system.auto-script con ../../ nel nome è una bandiera rossa. Gli indicatori completi (hash, nomi di file, indirizzi) sono nelle tabelle del report originale e includono i file lldprx, pM.js, index.js, index.wasm e ipssem.js, oltre a una regola YARA pubblicata da Unit 42. Un consiglio operativo da chi queste cose le fa di mestiere: se sospetti l’impianto, non riavviare per primo. Quello che risiede solo in memoria è, per sua natura, la prova che il riavvio distrugge. Questo è un articolo che vuole essere utile, quindi conviene dire dove finisce la solidità delle fonti. Tutti i dettagli tecnici su PEERSTITCH vengono da un unico report di un unico vendor su una singola vittima. Palo Alto Networks è, per inciso, un concorrente di Fortinet: ciò non rende il lavoro meno valido, ma è un motivo in più per attendere analisi indipendenti. Il report non dice quando l’impianto è stato installato, su quanti dispositivi sia stato trovato, quali versioni di FortiOS e FortiManager fossero in uso, né se l’impianto sopravviva a un riavvio. Sul punto della persistenza si può ragionare: il codice che esiste solo in memoria normalmente si perde al riavvio del demone che lo ospita, ma è un ragionamento, non una prova, e le credenziali rubate e la shell inversa restano comunque. Chi afferma con sicurezza che serva un “reset di fabbrica”, o che il malware sia persistente, sta andando oltre ciò che è stato pubblicato. Per chi in azienda firma i contratti, esiste un equivoco ricorrente da correggere: l’articolo 24 della NIS2, nell’attuazione italiana, non riguarda i controlli sull’esportazione né la tracciabilità di beni a duplice uso. Nel D.Lgs. 138/2024, l’articolo 24, comma 2, lettera d) impone ai soggetti di adottare misure per la sicurezza della catena di approvvigionamento, compresi gli aspetti relativi ai rapporti con i diretti fornitori e fornitori di servizi, e il comma 3 chiede di tenere conto delle vulnerabilità specifiche di ciascun fornitore e della qualità complessiva dei suoi prodotti e delle sue pratiche di sicurezza. Nella direttiva europea il contenuto corrisponde all’articolo 21, paragrafo 2, lettera d) e paragrafo 3; l’articolo 24 della direttiva tratta tutt’altro, gli schemi europei di certificazione. Citare il numero giusto non è pignoleria: in un’ispezione, conta. Sul piano pratico, l’Agenzia per la cybersicurezza nazionale ha introdotto l’obbligo di dichiarare i “fornitori rilevanti NIS” con la determinazione 127437/2026, e secondo le FAQ ACN commentate dagli operatori i servizi gestiti e i servizi gestiti di sicurezza rientrano tra le categorie ICT da considerare. Chi gestisce firewall per conto di terzi è dunque, in modo molto concreto, un fornitore rilevante. Le date e i dettagli applicativi vanno verificati sui testi originali delle determinazioni, perché le scadenze variano a seconda del momento in cui il soggetto è stato registrato. La console FortiManager di un MSP è un punto unico di fiducia per tutti i firewall che amministra. Quando il comma 3 dell’articolo 24 chiede di valutare le pratiche di sicurezza del fornitore, quella console è la prima cosa da valutare, perché è il fornitore concentrato in un solo oggetto. Il precedente storico più citato per gli attacchi alla catena degli MSP è Kaseya del 2021, in cui il gruppo REvil sfruttò una vulnerabilità del software di gestione per colpire centinaia di aziende a cascata: cambia il vettore, non il principio. Se sei un’azienda cliente con firewall gestiti da terzi, scrivi al fornitore, per iscritto, e fai queste quattro domande. La console di gestione è mai stata raggiungibile da Internet prima del 23 ottobre 2024? Quale versione era in esecuzione? I log sono stati confrontati con gli indicatori del bollettino FG-IR-24-423? Che cosa è stato ruotato dopo, e quando? Un fornitore serio risponde in giornata, con date. Uno che risponde “stiamo verificando” per tre settimane ti ha appena dato una seconda risposta. Se sei tu l’MSP, la lista tecnica è più lunga ma chiara. Aggiornare FortiOS per CVE-2025-61624 o migrare dai rami senza correzione. Controllare nelle revisioni di configurazione la presenza di oggetti auto-script con ../ nel nome. Cercare le regioni RWX da 16 KB in miglogd e iked prima di riavviare qualsiasi cosa. Abilitare fgfm-deny-unknown, restringere con policy local-in la porta TCP 541 e, sulle versioni che lo supportano, usare una CA FGFM esclusiva. Isolare le interfacce di gestione con il massimo livello di segmentazione, come raccomanda lo stesso Unit 42, che le definisce il bersaglio di maggior valore per chi gestisce infrastrutture altrui. Aggiungere un allarme sul silenzio dei log: un firewall che smette di loggare è un firewall che sta forse nascondendo qualcosa. E considerare ogni credenziale e certificato custodito dalla console come compromesso nel momento stesso in cui la console lo è. Il perimetro della tua azienda non finisce dove finisce la tua rete: finisce dove finisce la console di chi la amministra per te. La vera questione non è se il tuo fornitore sia stato bravo ad applicare la patch, ma se qualcuno, nel tuo contratto, gli ha mai chiesto di dimostrare che nessuno aveva già copiato le chiavi prima che la patch arrivasse. Unit 42, Palo Alto Networks, “Unit 42 Uncovers PEERSTITCH, a Stealthy FortiGate Implant”, 14 ottobre 2026: https://unit42.paloaltonetworks.com/fortimanager-cve-2024-47575-peerstitch-malware/ Fortinet PSIRT, FG-IR-24-423 (CVE-2024-47575): https://fortiguard.fortinet.com/psirt/FG-IR-24-423 Fortinet PSIRT, FG-IR-26-122 (CVE-2025-61624): https://fortiguard.fortinet.com/psirt/FG-IR-26-122 CISA, catalogo KEV, aggiunta del 16 ottobre 2026. Mandiant, attività UNC5820 (via The Hacker News): https://thehackernews.com/2024/10/fortinet-warns-of-critical.html SecurityWeek: https://www.securityweek.com/exploited-fortinet-bug-linked-to-stealthy-fortigate-implant-in-telecom-hack/ D.Lgs. 4 settembre 2024, n. 138, art. 24: https://www.reteambiente.it/normativa/55231/dlgs-4-settembre-2024-n-138/ Cyberness, determinazione ACN 127437/2026 sui fornitori rilevanti NIS: https://www.cyberness.it/nis2-fornitori-rilevanti-determinazione-acn-127437-2026/

A dieci anni dalla sua adozione, il GDPR è stato profondamente trasformato dall'azione delle autorità di controllo e della magistratura. Tra nuove competenze, interventi dei giudici e proposte di riforma europee, otto anni di enforcement mostrano perché la tutela dei dati personali richieda oggi regole più chiare e controlli più efficaci L'articolo GDPR, otto anni di enforcement hanno cambiato le regole della protezione dei dati proviene da Cyber Security 360 .

La crittografia dei dati è una componente essenziale della sicurezza informatica, ma la sua efficacia dipende da come viene applicata lungo l’intero ciclo di vita delle informazioni. Cifrare un database o un sistema di storage, per esempio, non garantisce che gli stessi dati siano adeguatamente protetti quando vengono trasferiti verso un’altra infrastruttura o utilizzati da un’applicazione. Per le aziende che adottano servizi cloud e architetture distribuite, è quindi necessario considerare tre condizioni: dati archiviati (at rest), in transito (in transit) e in elaborazione (in use). Ciascuna richiede misure specifiche, da integrare in una strategia di sicurezza coerente. L’attenzione a questi aspetti è anche una questione di conformità normativa. Il GDPR, all’articolo 32, individua la cifratura tra le possibili misure tecniche per proteggere i dati personali. La direttiva NIS2, recepita in Italia con il D.lgs. 138/2024, richiama espressamente le politiche e le procedure relative all’utilizzo della crittografia. Nel settore finanziario, inoltre, DORA rafforza i requisiti di gestione del rischio ICT. Indice degli argomenti Le informazioni aziendali attraversano sistemi e infrastrutture differenti. Possono essere conservate in un database, trasferite tra due data center oppure elaborate da un’applicazione ospitata nel cloud. Queste operazioni espongono i dati a rischi diversi. I dati “at rest” comprendono le informazioni memorizzate su dischi, database, sistemi di storage, backup e archivi. Le principali minacce riguardano gli accessi non autorizzati, il furto dei supporti e le configurazioni errate che possono rendere accessibili informazioni riservate. I dati “in transit” sono quelli trasferiti attraverso una rete. In questo caso occorre prevenire intercettazioni, alterazioni del traffico e accessi non autorizzati alle comunicazioni tra sistemi. I dati “in use”, infine, sono quelli utilizzati durante l’esecuzione di un’applicazione. Nelle architetture tradizionali, le informazioni devono essere disponibili in chiaro all’interno dell’ambiente di elaborazione, introducendo rischi che la cifratura dello storage e delle comunicazioni non è sufficiente a mitigare. Prima di individuare le tecnologie da adottare, è opportuno ricostruire il percorso delle informazioni più sensibili. Per ogni insieme di dati, l’organizzazione dovrebbe conoscere dove viene conservato, quali applicazioni lo utilizzano, attraverso quali connessioni viene trasferito e chi dispone delle autorizzazioni necessarie per accedervi. Questa analisi permette di scegliere controlli proporzionati al rischio, evitando sia ‘lacune’ nella protezione sia investimenti in tecnologie non necessarie. La protezione dei dati archiviati è generalmente garantita attraverso algoritmi di cifratura simmetrica, come l’Advanced Encryption Standard (AES), che rendono le informazioni illeggibili a chi non dispone della chiave necessaria per decifrarle. Questi sistemi di protezione possono essere applicati a diversi livelli, dai dischi e sistemi di archiviazione fino ai database e alle singole applicazioni La scelta del livello di cifratura dipende dalle caratteristiche dei sistemi e dalle minacce che si intendono contrastare. La cifratura del disco o del volume protegge soprattutto i dati quando il supporto non è in uso, ma non impedisce a un utente autorizzato, o a un eventuale attaccante che ne abbia compromesso le credenziali, di accedere alle informazioni attraverso il sistema operativo. La cifratura a livello di database o storage consente una gestione più integrata con l’infrastruttura. Quella applicativa, invece, permette di cifrare specifiche informazioni prima che raggiungano il sistema di archiviazione, limitandone l’esposizione anche rispetto ad alcuni componenti della piattaforma. La protezione non riguarda soltanto l’ambiente di produzione. Anche snapshot, repliche, backup e ambienti di test possono contenere informazioni riservate e devono essere inclusi nelle politiche di sicurezza. In questo ambito si inseriscono soluzioni come TIM Cloud Open e TIM Cloud Flex. La prima mette a disposizione risorse computazionali, storage e servizi opzionali su infrastrutture cloud ospitate nei Data Center italiani di TIM Enterprise. La seconda offre un catalogo modulare di servizi cloud, integrabile con funzionalità di storage e Data Protection, per rispondere alle diverse esigenze infrastrutturali delle aziende. La localizzazione nazionale dei dati può facilitare il rispetto di determinati requisiti di residenza e la governance delle infrastrutture. Deve però essere accompagnata da verifiche sulle modalità di amministrazione, sulle copie dei dati e sui soggetti che possono accedervi. Dal punto di vista operativo, una strategia di data protection dovrebbe prevedere backup cifrati, copie isolate o immutabili quando appropriate e verifiche periodiche delle procedure di ripristino. È importante anche evitare che le chiavi utilizzate per proteggere i backup siano accessibili attraverso le stesse credenziali compromettibili nell’ambiente di produzione. L’efficacia della cifratura dipende anche dalla protezione delle chiavi crittografiche. Una chiave compromessa può consentire la decifratura delle informazioni, indipendentemente dalla robustezza dell’algoritmo utilizzato. Per questo motivo, la gestione delle chiavi deve essere considerata parte integrante dell’architettura di sicurezza. Nei sistemi cloud vengono comunemente utilizzati servizi di Key Management System (KMS) e moduli Hardware Security Module (HSM), che consentono di proteggere le chiavi e governarne l’utilizzo. Un approccio diffuso è quello dell’envelope encryption: i dati vengono cifrati mediante apposite Data Encryption Key (DEK), a loro volta protette da Key Encryption Key (KEK). Questa separazione facilita la gestione delle chiavi e, in determinate condizioni, permette di ruotare le chiavi principali senza dover ricifrare tutti i dati. La gestione esterna delle chiavi, o External Key Management (EKM), consente di separare il sistema che conserva i dati da quello che governa le chiavi crittografiche. È un modello particolarmente interessante per le organizzazioni che utilizzano servizi cloud di terze parti e intendono mantenere un maggiore controllo sulle operazioni crittografiche. In questo ambito si inserisce TIM Digital Sovereignty – EKM, la soluzione di TIM Enterprise che consente di utilizzare chiavi di cifratura generate in un ambiente privato esterno al cloud provider. Questo approccio permette alle organizzazioni di mantenere un maggiore controllo sulla gestione delle chiavi crittografiche, contribuendo alla protezione dei dati e al rafforzamento della sovranità digitale anche negli ambienti cloud di terze parti. Il controllo effettivo dipende comunque dall’architettura adottata: occorre verificare dove risiedono le chiavi, quali operazioni possono essere eseguite dal provider, chi può autorizzarle e quali effetti produce un’eventuale revoca. La distinzione è importante anche rispetto alla sovranità digitale. Conservare i dati in un data center europeo non significa necessariamente che tutti i soggetti in grado di decifrarli siano sottoposti alla stessa giurisdizione. Nella valutazione di una soluzione EKM, le aziende dovrebbero prestare attenzione ad alcuni aspetti: Ciclo di vita delle chiavi: generazione, conservazione, rotazione, revoca e distruzione devono seguire procedure documentate. Separazione dei privilegi: gli amministratori dell’infrastruttura non dovrebbero disporre automaticamente dei permessi per utilizzare o gestire le chiavi. Tracciabilità: le operazioni crittografiche e gli accessi devono essere registrati e sottoposti a monitoraggio. Disponibilità: l’indisponibilità del sistema di gestione delle chiavi può impedire l’accesso ai dati e compromettere la continuità dei servizi. Capacità di evoluzione: l’architettura dovrebbe permettere l’aggiornamento degli algoritmi e delle politiche crittografiche senza interventi eccessivamente complessi. In particolare, la revoca delle chiavi deve essere verificata attraverso test specifici. Non è infatti sufficiente impedire nuove operazioni di decifratura se copie delle informazioni o delle chiavi sono già disponibili altrove. La diffusione di architetture ibride e multicloud ha aumentato il numero di connessioni attraverso cui transitano le informazioni aziendali. I dati vengono trasferiti tra sedi, applicazioni, data center e piattaforme cloud differenti. La sicurezza di questi collegamenti deve quindi essere valutata insieme a quella degli ambienti di origine e destinazione. Una possibilità consiste nell’utilizzare connessioni private e dedicate, riducendo l’esposizione del traffico a Internet pubblica. Soluzioni come TIM Cloud Interconnect rispondono a questa esigenza, consentendo di collegare direttamente la rete privata aziendale ai principali provider cloud attraverso connessioni dedicate che non transitano su Internet pubblico. Questo modello permette di ridurre l’esposizione del traffico e di migliorare la prevedibilità delle prestazioni, fermo restando che la protezione crittografica delle comunicazioni richiede l’adozione di specifici protocolli di sicurezza. Per applicazioni critiche, questa impostazione può offrire vantaggi anche in termini di latenza, affidabilità e gestione dei flussi. È necessario distinguere la riservatezza del percorso dalla cifratura delle comunicazioni. Una connessione privata limita l’esposizione del traffico, ma non garantisce automaticamente che le informazioni siano cifrate. Per questo motivo possono essere adottati protocolli differenti, a seconda dell’architettura: MACsec, per la protezione dei collegamenti a livello Ethernet; IPsec, per cifrare le comunicazioni tra reti o sistemi; TLS, per proteggere le sessioni applicative. La scelta dipende dalle caratteristiche del collegamento, dai requisiti delle applicazioni e dal modello di minaccia. Occorre, inoltre, verificare i punti in cui la cifratura termina, la gestione dei certificati e delle chiavi, le configurazioni dei protocolli e la presenza di eventuali tratte non protette. La sicurezza delle comunicazioni assume anche una prospettiva di lungo periodo. Il rischio che informazioni cifrate vengano intercettate oggi e conservate per essere decifrate in futuro, noto come harvest now, decrypt later, rende importante pianificare l’evoluzione verso algoritmi resistenti alle minacce quantistiche. La protezione dei dati durante l’elaborazione presenta difficoltà differenti. Nelle architetture tradizionali, un’applicazione deve poter accedere alle informazioni in chiaro per eseguire calcoli, analisi e altre operazioni. Di conseguenza, i dati possono essere esposti all’interno della memoria del sistema. La cifratura del disco non protegge da questo rischio, perché interviene principalmente quando i dati sono memorizzati. Analogamente, TLS e IPsec proteggono le comunicazioni, ma non il contenuto una volta ricevuto e decifrato dall’applicazione. L’isolamento dei workload, la segmentazione, il controllo degli accessi e il principio del minimo privilegio rimangono indispensabili. Tuttavia, in determinati scenari, un attaccante che comprometta componenti privilegiati dell’infrastruttura potrebbe accedere alla memoria dei sistemi e alle informazioni elaborate. Il rischio assume particolare rilevanza negli ambienti virtualizzati e cloud, dove il livello infrastrutturale è amministrato da un soggetto diverso dall’organizzazione che utilizza il servizio. La questione non riguarda necessariamente la fiducia nel fornitore, ma la necessità di ridurre le conseguenze di un’eventuale compromissione dei componenti sottostanti. Il confidential computing affronta questo problema attraverso meccanismi di isolamento basati sull’hardware. L’obiettivo è creare ambienti di esecuzione protetti nei quali codice e dati possano essere elaborati limitando l’accesso da parte di componenti esterni all’ambiente stesso. Questi ambienti vengono generalmente indicati come Trusted Execution Environments (TEE). Un TEE utilizza funzionalità di sicurezza del processore per isolare le operazioni sensibili e proteggere la memoria secondo uno specifico modello di minaccia. Tra le tecnologie disponibili figurano AMD SEV-SNP e Intel TDX, che permettono di realizzare macchine virtuali confidenziali (confidential VM). In queste architetture, la memoria delle macchine virtuali viene protetta mediante meccanismi crittografici gestiti dall’hardware, riducendo le possibilità di accesso da parte dell’hypervisor e di altri componenti infrastrutturali. Uno dei vantaggi è la possibilità di utilizzare, in molti casi, applicazioni esistenti senza doverle modificare in modo sostanziale. Un approccio differente è quello di Intel SGX, che consente di creare enclave per proteggere specifiche porzioni di codice e dati. Questa soluzione richiede generalmente un maggiore intervento sull’applicazione, ma permette di delimitare con precisione le operazioni da isolare. Un elemento importante del confidential computing è la remote attestation, cioè il processo attraverso cui un sistema fornisce evidenze crittografiche sul proprio ambiente di esecuzione. Queste evidenze possono essere verificate da un soggetto esterno prima di autorizzare l’accesso a informazioni sensibili o il rilascio di una chiave crittografica. Per esempio, un’organizzazione può subordinare la disponibilità delle chiavi alla verifica che un determinato workload sia eseguito in un ambiente conforme alle configurazioni previste. Si tratta di un controllo utile soprattutto quando i dati vengono elaborati su infrastrutture gestite da terzi. Il confidential computing, tuttavia, non elimina tutti i rischi. La sicurezza continua a dipendere dalla corretta configurazione dei sistemi, dall’aggiornamento di firmware e microcode, dalla protezione delle applicazioni e dalla resistenza a eventuali attacchi attraverso canali laterali. Per questo motivo, la sua adozione dovrebbe partire da un’analisi dei workload e delle informazioni per le quali l’isolamento hardware offre un beneficio concreto. La protezione dei dati richiede il coordinamento delle misure adottate nei diversi ambienti. Un’organizzazione può disporre di uno storage cifrato e di connessioni sicure, ma continuare a esporsi a rischi se le chiavi sono accessibili attraverso account privilegiati non adeguatamente protetti oppure se le informazioni vengono elaborate in ambienti non sufficientemente isolati. In questa prospettiva, le componenti dell’offerta TIM Cloud, Digital Sovereignty – EKM e Cloud Interconnect possono essere considerate nell’ambito di un’architettura integrata: infrastruttura per l’archiviazione, gestione delle chiavi e connettività protetta. Il confidential computing rappresenta un ulteriore livello di protezione per i carichi di lavoro che richiedono specifiche garanzie durante l’elaborazione, da valutare in funzione delle tecnologie effettivamente disponibili e dei requisiti applicativi. Nella scelta delle soluzioni e dei fornitori, il responsabile della sicurezza dovrebbe verificare almeno cinque aspetti: Dove sono conservati i dati, comprese le copie di backup e le repliche? Chi genera, custodisce e può utilizzare le chiavi crittografiche? Come vengono protette le comunicazioni tra sistemi e infrastrutture? Quali controlli limitano l’accesso ai dati durante l’elaborazione? Quali registrazioni, attestazioni e documentazioni consentono di verificare l’efficacia delle misure adottate? Le risposte dovrebbero tradursi in requisiti contrattuali, configurazioni verificabili e procedure di controllo periodico. È altrettanto importante definire le responsabilità tra cliente e fornitore, soprattutto negli ambienti cloud in cui le attività di gestione e sicurezza sono distribuite tra più soggetti. La protezione delle informazioni aziendali non si esaurisce nella scelta di un algoritmo crittografico. La localizzazione dei dati, la gestione delle chiavi, la sicurezza delle comunicazioni e il controllo degli ambienti di elaborazione incidono sulla capacità dell’organizzazione di governare le proprie informazioni. Sono aspetti rilevanti anche per la sovranità digitale, intesa come possibilità di mantenere un controllo effettivo sulle infrastrutture, sugli accessi e sulle operazioni che riguardano i dati. Per le aziende, il passaggio fondamentale consiste nel trasformare questi principi in requisiti tecnici e organizzativi misurabili. Occorre individuare i dati più sensibili, definire chi può accedervi, scegliere le tecnologie appropriate per proteggerli nei diversi stati e verificare periodicamente che le misure adottate continuino a rispondere ai rischi. La crittografia resta uno degli strumenti principali di questa strategia. La sua efficacia, però, dipende dall’architettura di sicurezza nella quale viene utilizzata e dalla capacità dell’organizzazione di mantenerne il controllo nel tempo. Contributo redazionale realizzato in collaborazione con TIM Enterprise.

Come prevenire esfiltrazione, Insider Threat e violazioni con controlli tecnici, cifratura e compliance L'articolo Protezione della proprietà intellettuale: bloccare i dati proviene da Cyber Security 360 .

Il NIST ha pubblicato il 27 ottobre 2026 la guida definitiva alla migrazione verso la crittografia post-quantistica. RSA ed ECDSA saranno deprecati dopo il 2030 e non più ammessi dagli standard NIST dopo il 2035. Le scadenze USA e la roadmap europea impongono alle aziende di pianificare la sostituzione dei sistemi vulnerabili L'articolo Crittografia post-quantistica, il NIST fissa le scadenze per la migrazione proviene da Cyber Security 360 .

Il CERT-AGID individua nuove false multe pagoPA spedite da caselle PEC compromesse. Le email chiedono 198 euro e portano a un sito fraudolento che riceve istruzioni dai criminali ogni mezzo secondo. Dal 2025 censite 1.874 campagne a tema multe: come riconoscerle e proteggere dati e pagamenti L'articolo False multe via PEC, CERT-AGID scopre il sistema dei truffatori proviene da Cyber Security 360 .

CISA inserisce Fragnesia, una falla del kernel Linux, tra le vulnerabilità sfruttate attivamente e segnala la possibile concatenazione con PHP2Shell. La combinazione può trasformare un accesso al server web in privilegi root: patch, verifiche forensi e controlli per aziende e PA italiane L'articolo PHP2Shell e Fragnesia, CISA avverte: server Linux a rischio root proviene da Cyber Security 360 .

Il Rapporto Clusit di ottobre 2026 censisce 4.911 incidenti gravi nel mondo e 245 in Italia. Nel Paese cala l’hacktivism, il cybercrime torna prevalente e il manifatturiero è il primo bersaglio: continuità operativa e sicurezza dei fornitori diventano priorità aziendali L'articolo Rapporto Clusit 2026: il cybercrime mette sotto pressione le imprese proviene da Cyber Security 360 .

Dall’AI che trova vulnerabilità e genera patch a quella che analizza gli incidenti, i nuovi modelli per la cybersecurity coprono compiti differenti. Il confronto tra Google, OpenAI, Anthropic, Cisco e i fornitori di piattaforme chiarisce prestazioni, accesso, costi e vincoli per le aziende L'articolo Modelli AI per la cybersecurity: quali sono, quali scegliere proviene da Cyber Security 360 .

IONOS propone il piano Plus di MyWebsite a canone zero per 12 mesi. L'offerta comprende 50 GB di spazio web, strumenti di intelligenza artificiale generativa, ottimizzazione SEO, prenotazioni online e statistiche web. Il rinnovo va verificato nelle condizioni contrattuali L'articolo Piattaforma IONOS Plus per siti web: suite d’intelligenza artificiale generativa, 50 GB di cloud storage e primo anno a canone azzerato proviene da Cyber Security 360 .

Google ha presentato Gemini 4 Carbon, un modello AI che nei test dell'azienda individua vulnerabilità, ne verifica la sfruttabilità e propone patch. L'accesso iniziale è riservato a difensori selezionati, mentre cresce l'urgenza di governare capacità utili anche agli attaccanti L'articolo Gemini 4 Carbon, Google porta gli agenti AI nella caccia alle falle proviene da Cyber Security 360 .

L'aumento degli attacchi cyber in Italia e i nuovi obblighi della NIS2 impongono alle aziende di ripensare la gestione del rischio informatico. La scelta di partner tecnologici qualificati diventa così una decisione strategica di governance, fondamentale per integrare sicurezza, competenze e compliance L'articolo Cyber risk, Italia nel mirino: perché la scelta del partner è una decisione di governance proviene da Cyber Security 360 .

Un dispositivo grande quanto una moneta ha dimostrato che i sistemi di volo di un 737 possono essere manomessi con un attacco fisico da meno di 100 dollari. Il caso riguarda direttamente le infrastrutture critiche italiane soggette a NIS2. Vediamo perché L'articolo Un Boeing 737 violato con 100 dollari: la sicurezza fisica che l’OT ha dimenticato proviene da Cyber Security 360 .

L'evoluzione del SOC analizzata attraverso l'esperienza di Adobe: dal superamento dei limiti rigidi del SOAR all'adozione di agenti AI specializzati in grado di esaminare oltre 140 rilevamenti in meno di quattro ore L'articolo L’evoluzione del SOC: dal limite del SOAR agli agenti AI proviene da Cyber Security 360 .

Il D.lgs. 191/2026 adegua il quadro italiano alla certificazione europea dei servizi di sicurezza gestiti. Nessun obbligo generalizzato dal 6 novembre, ma una novità destinata a incidere sulla scelta dei fornitori e sulla qualità delle prestazioni cyber L'articolo Servizi di sicurezza gestiti: la certificazione europea non riguarda soltanto i SOC proviene da Cyber Security 360 .

NordVPN anticipa il Black Friday con sconti fino al 78% e tre mesi extra sui piani biennali. Il piano Base costa 94,23 euro per 27 mesi, mentre il Completo parte da 107,73 euro. Attenzione ai costi di rinnovo e all'eventuale IVA L'articolo NordVPN anticipa il Black Friday 2026: sconto del 78% e 3 mesi extra sulla VPN da 3,49 € al mese proviene da Cyber Security 360 .

Il 29 ottobre scade il termine di sei mesi concesso dal Garante privacy per adeguare i trattamenti basati sui tracking pixel nelle comunicazioni e-mail. Informative, consensi, revoche e configurazioni delle piattaforme sono tra gli aspetti da verificare. Ecco gli adempimenti da completare, le verifiche da documentare e gli errori da evitare L'articolo Tracking pixel nelle e-mail: promemoria operativo per titolari e piattaforme proviene da Cyber Security 360 .

Il regolamento europeo sull’intelligenza artificiale, noto come AI Act, definisce un quadro di obblighi per lo sviluppo e l’utilizzo dei sistemi di IA. La sua applicazione richiede competenze che non possono essere confinate al solo ambito legale. Ecco i 12 profili professioniali individuati e le 4 priorità per l’Italia L'articolo AI, il ritardo è nelle competenze: servono professionisti per superare i silos proviene da Cyber Security 360 .

Ogni minuto di fermo ha un prezzo: come misurarlo, contrattualizzarlo e ridurlo prima che presenti il conto L'articolo SLA e Downtime: calcolare i costi dell’inattività IT proviene da Cyber Security 360 .

Le simulazioni di phishing riducono gli errori, ma non garantiscono comportamenti sicuri davanti ad attacchi reali. Per rafforzare la resilienza aziendale occorre andare oltre i corsi di awareness, sviluppando capacità di autodifesa, consapevolezza e responsabilità condivisa. Ecco come ripensare formazione e metriche di sicurezza L'articolo Phishing, superare i test non significa essere pronti agli attacchi reali proviene da Cyber Security 360 .

Dal 2027 i soggetti NIS già registrati non dovranno presentare una nuova dichiarazione se le informazioni comunicate non sono cambiate. La semplificazione introdotta dall'ACN riduce gli adempimenti amministrativi, ma non elimina l'obbligo di aggiornare i dati né gli altri obblighi previsti dalla NIS2 L'articolo NIS2, dal 2027 registrazione semplificata sul Portale ACN: cosa cambia per le aziende proviene da Cyber Security 360 .

Un attacco alle caselle parlamentari della Camera, inclusa quella assegnata a Giorgia Meloni, riporta al centro la sicurezza delle comunicazioni istituzionali. Informazioni incomplete, crescente pressione cyber e rischio di guerra ibrida rendono insufficiente ogni tentativo di minimizzare l'episodio L'articolo Attacco alla Camera, perché minimizzare è un errore: i rischi per la sicurezza nazionale proviene da Cyber Security 360 .

Le vulnerabilità PHP2Shell non colpiscono direttamente Android e iOS, ma possono esporre dati e servizi delle app mobili attraverso backend PHP vulnerabili. L'analisi di NowSecure evidenzia i rischi per API e componenti di terze parti e la necessità di aggiornare i server per proteggere anche gli utenti mobile L'articolo PHP2Shell minaccia anche le app Android e iOS: il rischio nascosto nei server proviene da Cyber Security 360 .

A settembre 2026 ACN registra 485 eventi cyber e 235 incidenti confermati. DDoS e defacement alimentano la crescita degli eventi, mentre il ransomware resta la minaccia con il maggiore impatto operativo, con attacchi anche a due strutture sanitarie L'articolo ACN, eventi cyber a +57%: il ransomware pesa sulla continuità dei servizi proviene da Cyber Security 360 .

Aruba SuperSite integra strumenti di intelligenza artificiale generativa per creare siti web, produrre contenuti e gestire progetti online senza competenze di programmazione. Due i piani disponibili, Easy e Professional, con prezzi promozionali da 17,90 euro più IVA per il primo anno L'articolo Piattaforma Aruba SuperSite: creazione di siti ed e-commerce con intelligenza artificiale generativa proviene da Cyber Security 360 .

Traducendo l’obbligo in organizzazione, si definisce il modello integrato di sicurezza, delineando i compiti e le interazioni di DPO, CISO e Safety Manager. Ecco un caso d’uso dell’AI per la sicurezza in cantiere: prevenzione degli infortuni, protezione dei dati e disciplina dei controlli a distanza devono essere governate in un’unica decisione L'articolo Governare la sicurezza integrata: DPO, CISO e Safety Manager alla prova dell’AI in cantiere proviene da Cyber Security 360 .

Come trasformare i dati sulle minacce in decisioni operative per aggiornare le difese, ridurre i rischi e colpire gli attaccanti prima che agiscano L'articolo Threat Intelligence: anticipare i vettori d’attacco proviene da Cyber Security 360 .

Mentre continuano gli scontri che interessano capitali europee, Milano e altre città italiane, si affaccia l’ipotesi che dietro vi si nasconda un’orchestrazione russa che abbia incitato alla guerra ibrida attraverso le piattaforme social. Ecco cosa sappiamo e perché resta fondamentale raccogliere informazioni dirette sul terreno L'articolo Ombre russe sugli scontri in Europa: fra ipotesi di guerra ibrida e fattore umano sul campo proviene da Cyber Security 360 .

Secondo una ricerca di Zscaler, il ransomware è sempre più un problema di accesso alle risorse aziendali. Ecco perché i gruppi ransomware riescono a ottenere un accesso ai sistemi, sfruttando gerarchie aziendali, trasformando le informazioni critiche sottratte in uno strumento di pressione sulle imprese L'articolo Il ransomware cambia bersaglio: sempre più in alto nella gerarchia aziendale proviene da Cyber Security 360 .

I test condotti da OpenAI e Anthropic mostrano che anche i modelli AI più avanzati possono oltrepassare i limiti operativi previsti. La sicurezza non dipende soltanto dall'allineamento, ma anche dal controllo di privilegi, accessi e ambienti di esecuzione. Ecco perché serve ripensare la protezione degli agenti AI L'articolo Sicurezza dei modelli AI, perché l’allineamento non basta a fermare i comportamenti pericolosi proviene da Cyber Security 360 .

Si succedono gli interventi governativi nelle varie nazioni. Con i legislatori che non sfuggono alla retorica sul riconoscimento facciale concentrandosi sugli effetti positivi e non sui limiti di questa tecnologia. Per capirci di più è bene sfogliare qualche ricerca L'articolo Il senso relativo del riconoscimento facciale con l’incubo dei falsi positivi proviene da Cyber Security 360 .

Gli attacchi informatici con AI cambiano velocità e scala. Microsoft documenta campagne con ARTEX capaci di ottenere privilegi cloud in meno di tre ore, mentre Sophos osserva agenti AI usati per sviluppare attacchi. PHP2Shell mostra come l'AI acceleri anche la ricerca delle falle: quali prove abbiamo, cosa resta incerto e come cambiano le difese L'articolo Come l’AI sta cambiando gli attacchi cyber e come difendersi proviene da Cyber Security 360 .

Come contenere ransomware e spostamento laterale isolando i dispositivi compromessi e riducendo la superficie d'attacco L'articolo Endpoint isolation e microsegmentazione per la rete B2B proviene da Cyber Security 360 .