Spcnet.it

2026-05-21 08:29:05

GitHub Copilot diventa un’app desktop autonoma: sessioni agentiche e Agent Merge in anteprima tecnica

Il 14 maggio 2026, GitHub ha rilasciato in anteprima tecnica la GitHub Copilot App: una client desktop nativo, disponibile per macOS, Windows e Linux, che porta lo sviluppo agentico fuori dagli IDE e lo trasforma in un flusso di lavoro autonomo e strutturato. Non si tratta di un semplice wrapper del plugin per VS Code — è un’applicazione completamente ridisegnata attorno al concetto di sessione, pensata per chi gestisce più task in parallelo su repository diversi.

Perché un’app separata?

Fino ad oggi, GitHub Copilot viveva principalmente all’interno degli editor di testo (VS Code, JetBrains, Visual Studio). Il limite di questo approccio è strutturale: l’editor è centrato sul file, non sul task. Aprire una issue, capire il contesto, avviare un agente e poi seguire la PR fino al merge richiede di saltare continuamente tra browser, terminale e IDE.

La Copilot App rompe questo ciclo. Il suo punto di partenza non è un file, ma il contesto GitHub: issue, pull request, commenti di review e risultati dei check CI sono gli artefatti da cui nasce ogni sessione di lavoro agentico.

Il modello a sessioni isolate

Il concetto centrale dell’app è la sessione. Ogni sessione ha un proprio spazio di lavoro separato:

• Un branch Git dedicato, creato automaticamente all’avvio
• Una copia dei file del repository (worktree isolato)
• Una cronologia di conversazione separata
• Uno stato del task indipendente

Questo significa che è possibile tenere aperte contemporaneamente più sessioni — ognuna su un repository o task diverso — senza che si interferiscano. Una sessione può essere messa in pausa e ripresa in seguito esattamente dal punto in cui era rimasta, perché lo stato viene salvato lato cloud.

Questo approccio è particolarmente utile per i team che lavorano su task ripetitivi o paralleli: aggiornamenti delle dipendenze, generazione di release notes, triage automatico di issue, pulizia del codice morto.

L’inbox: un pannello di controllo unificato

L’interfaccia principale dell’app è una inbox che aggrega, in un’unica vista, issue aperte, pull request in attesa di review, fallimenti dei check CI e task in corso — attraverso tutti i repository connessi all’account GitHub.

Da questa inbox si può selezionare un elemento, assegnarlo a una nuova sessione, e l’agente parte con il contesto completo già disponibile: descrizione della issue, stato del branch, commenti precedenti. Non è necessario copiare e incollare nulla.

Agent Merge: il completamento automatico del ciclo PR

La funzionalità più interessante — e potenzialmente più impattante per i workflow aziendali — è Agent Merge.

Una volta aperta una pull request da una sessione, Agent Merge può:

• Rispondere ai commenti di review: legge i feedback dei reviewer e applica le modifiche richieste
• Correggere i fallimenti CI: se un check fallisce, analizza l’output e tenta di risolvere il problema
• Risolvere conflitti di merge: gestisce in autonomia i conflitti non ambigui
• Fare il merge finale: quando tutte le condizioni sono soddisfatte (approvazioni, check verdi, regole di branch protection rispettate), completa il merge

L’ultimo punto è importante: Agent Merge rispetta le regole di branch protection dell’organizzazione. Non bypassa i requisiti di approvazione manuale — si limita a gestire tutto ciò che è automatizzabile nel rispetto delle policy esistenti.

Terminale integrato e preview browser

L’app include un terminale integrato per eseguire comandi all’interno della sessione e un preview browser per testare l’output dell’applicazione prima di aprire la PR. Questo permette di validare le modifiche senza uscire dall’app.

Modelli AI configurabili per le organizzazioni

La Copilot App utilizza un mix di modelli da Anthropic, OpenAI e GitHub stesso. Le organizzazioni su piano Business o Enterprise possono configurare quale modello usare per le sessioni agentiche. Questa flessibilità è rilevante per chi ha requisiti specifici di compliance o preferenze tecniche sul provider AI.

Requisiti e disponibilità

L’app è disponibile in anteprima tecnica con accesso graduale:

• Pro e Pro+: iscrizione alla waitlist via gh.io/github-copilot-app
• Business e Enterprise: disponibilità progressiva — richiede che l’admin dell’organizzazione abbia abilitato le anteprime e il Copilot CLI nelle policy
• Piano gratuito: escluso per ora

L’app richiede una connessione costante ai backend GitHub perché le sessioni e i modelli AI risiedono interamente lato cloud. Non è possibile usarla offline.

Considerazioni per i team di sviluppo

Per un team che usa già GitHub Actions e branch protection, l’integrazione di Agent Merge può ridurre significativamente il tempo che i developer spendono su task meccanici post-review. La vera domanda non è tecnica ma di processo: fino a che punto si è disposti a delegare all’agente la chiusura del ciclo di una PR?

L’approccio a sessioni isolate su worktree separati è architetturalmente solido: ogni sessione non contamina il branch principale e l’isolamento Git garantisce che gli esperimenti agentici rimangano confinati. Il rischio principale è, come sempre, la qualità del codice generato — che rimane sotto responsabilità del developer che fa la review finale.

Per team che gestiscono molte PR in parallelo (es. monorepo, molti contributor, cicli di release frequenti), questa app può diventare un moltiplicatore di produttività reale.

---

Fonte: GitHub Changelog — GitHub Copilot app is now available in technical preview

GitHub Copilot app is now available in technical preview - GitHub Changelog

The GitHub Copilot app is now in technical preview. It’s a GitHub-native desktop experience to start agentic development from the work in front of you, keep it isolated, steer it…

^{Allison (The GitHub Blog)}

Spcnet.it

2026-05-20 19:00:27

Migrazione certificati Secure Boot in Windows 11: guida agli script PowerShell di KB5089549

Il contesto: perché i certificati Secure Boot stanno scadendo

Giugno 2026 non è solo una data sul calendario: è una scadenza critica per qualsiasi amministratore di sistema che gestisce parchi macchine Windows in ambienti enterprise. I certificati Secure Boot installati nella maggior parte dei dispositivi durante l’era di Windows 8 — quelli che fondano la catena di fiducia UEFI — inizieranno a scadere a partire da questo mese. La conseguenza più immediata: i dispositivi non aggiornati perderanno la capacità di ricevere nuove protezioni per il processo di avvio, inclusi aggiornamenti al Windows Boot Manager, alle revocation list DBX e alle patch per vulnerabilità di boot-level scoperte in futuro.

Microsoft ha risposto a questa urgenza con il Patch Tuesday di maggio 2026, introducendo l’aggiornamento cumulativo KB5089549 per Windows 11 (versioni 24H2 e 25H2). Oltre alle consuete correzioni di sicurezza, questa release porta con sé qualcosa di inedito: una nuova cartella C:\Windows\SecureBoot\ExampleRolloutScripts contenente sette script PowerShell pensati per automatizzare l’intera migrazione dei certificati Secure Boot nelle reti enterprise.

Cosa trovi nella cartella C:\Windows\SecureBoot

La cartella non contiene i certificati stessi, ma una suite di script PowerShell modulari, ben commentati e accompagnati da un file README.md e un CHANGELOG.txt. Microsoft la posiziona deliberatamente sotto C:\Windows — un segnale preciso: la gestione del Secure Boot diventa un’attività di manutenzione ordinaria del sistema operativo, non più un compito relegato a tool OEM o procedure manuali nei menu BIOS.

Gli script sono progettati per operare su flotte di macchine tramite Intune, WSUS o Configuration Manager. Vediamoli uno per uno.

1. Detect-SecureBootCertUpdateStatus.ps1

Questo script viene eseguito su ogni endpoint, tipicamente via Group Policy o come scheduled task distribuito. Raccoglie lo stato di Secure Boot, i valori di registro che tracciano l’avanzamento della migrazione certificati, i dettagli OEM e firmware, e gli entry rilevanti dell’Event Log. L’output è un file JSON scritto su un path di rete condiviso (e su un path locale di fallback), che serve come base dati per gli script successivi.

# Esempio di utilizzo base
.\Detect-SecureBootCertUpdateStatus.ps1 -OutputPath "\\server\SecureBootData"


2. Aggregate-SecureBootData.ps1

Consolida i file JSON prodotti dallo script di rilevamento in un unico report aggregato. Utile per costruire dashboard di stato, identificare dispositivi con certificati non aggiornati e pianificare le wave di deployment. Può essere eseguito dal management server con accesso alla condivisione di rete centralizzata.

3. Deploy-GPO-SecureBootCollection.ps1

Automatizza la creazione di una Group Policy Object che distribuisce lo script di raccolta dati (Detect-SecureBootCertUpdateStatus.ps1) come scheduled task su tutti i target dell’OU specificata. Riduce drasticamente il lavoro manuale nella fase di inventory.

4. Start-SecureBootRolloutOrchestrator.ps1

È il cuore della suite. Legge i dati aggregati, determina quali dispositivi sono pronti per l’aggiornamento, crea security group AD e una GPO dedicata, quindi avvia il deployment progressivo a wave esponenziali: prima 1 dispositivo, poi 2, poi 4 e così via. Se una wave registra errori firmware, il rollout si blocca automaticamente, impedendo la propagazione del problema al resto della flotta.

# Avvio orchestrato con 5% di dispositivi nel primo ring
.\Start-SecureBootRolloutOrchestrator.ps1 `
  -DataPath "\\server\SecureBootData" `
  -RingSize 0.05 `
  -DomainController "dc01.contoso.com"


5. Deploy-OrchestratorTask.ps1

Il processo di orchestrazione può durare settimane in ambienti di grandi dimensioni. Invece di mantenere aperta una sessione PowerShell su un management server, questo script installa l’orchestratore come Windows Scheduled Task, garantendo continuità anche in caso di riavvii o disconnessioni.

6. Get-SecureBootRolloutStatus.ps1

Permette di visualizzare lo stato corrente del rollout: quanti dispositivi sono stati aggiornati, quanti sono in attesa, quanti hanno riscontrato errori. Indispensabile per il monitoraggio durante fasi di deployment attive.

7. Enable-SecureBootUpdateTask.ps1

Script di remediation: se il task automatico di aggiornamento Secure Boot è stato disabilitato, eliminato o modificato (ad esempio da una policy di Configuration Manager), questo script lo ripristina allo stato predefinito, rimettendo in moto i dispositivi che non stanno progredendo.

Considerazioni pratiche prima di eseguire gli script

Microsoft descrive questi script come sample — implementazioni di riferimento, non soluzioni turnkey pronte per il produzione senza revisione. Prima di distribuirli, è necessario tenere a mente alcune criticità.

Esecuzione policy e script non firmati. Gli script sono unsigned. Prima di eseguirli, verificare che la execution policy di PowerShell lo permetta, oppure sbloccarli individualmente:

Unblock-File -Path "C:\Windows\SecureBoot\ExampleRolloutScripts\*.ps1"


BitLocker e Credential Guard. Le modifiche allo stato di Secure Boot possono innescare richieste di recovery BitLocker. Gli script includono un pre-check che sospende BitLocker sul volume di sistema prima della migrazione e lo riattiva al termine — ma è sempre buona norma avere le recovery key a portata di mano prima di avviare qualsiasi operazione.

Firmware OEM aggiornato. Prima di applicare la migrazione certificati, verificare che i dispositivi target abbiano il firmware UEFI più recente fornito dall’OEM. Alcuni modelli più datati potrebbero non supportare le variabili UEFI necessarie o potrebbero richiedere un aggiornamento firmware preventivo.

Ambienti di test obbligatori. Il rollout progressivo dell’orchestratore è già un meccanismo di sicurezza, ma Microsoft raccomanda comunque di testare gli script in un ambiente non produttivo con hardware rappresentativo prima di qualsiasi deployment su larga scala.

Integrazione con Intune e il report Autopatch

Per chi utilizza Windows Autopatch, l’Intune admin center ha ricevuto un aggiornamento del report Secure Boot Status che fornisce visibilità device-by-device sullo stato dei certificati in vista della scadenza di giugno. Il report mostra quali dispositivi hanno Secure Boot abilitato, se i certificati sono aggiornati, e se si applica il deployment automatico o manuale. Nuove colonne per trust configuration, confidence level e alert aiutano a prendere decisioni mirate anziché dover fare deployment generalizzati.

Conclusione

L’aggiornamento KB5089549 non è solo un Patch Tuesday ordinario: segna un passaggio importante nel modo in cui Microsoft concepisce la gestione della sicurezza firmware in ambienti enterprise. Collocare script PowerShell di migrazione Secure Boot direttamente in C:\Windows, con logging integrato sull’Event Log sotto il provider Microsoft-Windows-SecureBoot-Scripts e un changelog per le future versioni, è un chiaro segnale: il lifecycle management del Secure Boot diventa parte del normale ciclo di manutenzione dei sistemi Windows, esattamente come la gestione dei certificati TLS.

Per i sysadmin che devono affrontare la scadenza di giugno 2026, il punto di partenza è il portale ufficiale aka.ms/GetSecureBoot, dove Microsoft raccoglie tutta la documentazione aggiornata sulla migrazione. Il tempo di agire è adesso: inventariare i dispositivi, testare gli script in un ambiente controllato e pianificare le wave di deployment prima che la scadenza diventi un’emergenza.

---

Fonti: Neowin – KB5089549, Microsoft Support – Secure Boot Certificate Expiration, 4sysops – Windows 11 SecureBoot folder

Windows Secure Boot certificate expiration and CA updates - Microsoft Support

^aka.ms

(in)sicurezza digitale

2026-05-20 18:59:45

FamousSparrow spia l’Azerbaigian: il gruppo APT cinese colpisce l’industria petrolifera del corridoio energetico europeo

Bitdefender Labs ha documentato un’operazione di cyberspionaggio cinese di ampio respiro contro l’industria petrolifera e del gas dell’Azerbaigian, attribuita con confidenza medio-alta al gruppo FamousSparrow — noto anche come Earth Estries — un attore APT allineato con Pechino. L’operazione, durata oltre due mesi tra dicembre 2025 e febbraio 2026, assume una rilevanza geopolitica straordinaria: l’Azerbaigian è diventato un corridoio energetico strategico per l’Europa dopo la scadenza del contratto di transito del gas russo attraverso l’Ucraina e le perturbazioni nello Stretto di Hormuz del 2026.

Il contesto geopolitico: perché l’Azerbaigian è nel mirino cinese

Comprendere questa intrusione richiede un passo indietro sul panorama energetico europeo. A fine 2024, è scaduto il contratto di transito del gas naturale russo attraverso l’Ucraina, eliminando uno dei principali canali di approvvigionamento per l’Europa orientale. Nel primo trimestre del 2026, la sospensione delle spedizioni di GNL dal Qatar e le perturbazioni nello Stretto di Hormuz hanno ulteriormente ridotto le alternative disponibili. In questo scenario, l’Azerbaigian ha consolidato il proprio ruolo di partner energetico strategico, espandendo le forniture a 13 paesi europei — incluse nuove consegne a Germania e Austria — con un volume export cresciuto del 56% dal 2021.

Accesso iniziale: lo stesso server Exchange sfruttato tre volte

Il 25 dicembre 2025, il processo w3wp.exe (worker IIS di Microsoft Exchange) ha tentato di scrivere una web shell malevola in una directory pubblica del server. Il vettore era la catena exploit ProxyNotShell (CVE-2022-41040, CVE-2022-41082), documentata già dal 2022. Ulteriori tentativi di deploy di web shell sono stati registrati il 26 e 29 dicembre, con filename quali key.aspx, log.aspx, errorFE_.aspx e signout_.aspx.

Ciò che rende questa intrusione particolarmente significativa è la disciplina operativa: il medesimo server Exchange vulnerabile è stato ri-sfruttato per tre ondate distinte nell’arco di due mesi, nonostante i tentativi di remediation della vittima. Ogni volta che la difesa rimuoveva il malware, il gruppo tornava attraverso lo stesso punto di accesso, cambiando il backdoor ma preservando il canale.

Prima ondata: Deed RAT tramite la triade LogMeIn Hamachi

Dopo aver stabilito un foothold via web shell, gli attaccanti hanno distribuito il backdoor Deed RAT attraverso una catena DLL sideloading a tre componenti che sfrutta il legittimo software LogMeIn Hamachi:

• LMIGuardianSvc.exe — binario legittimo LogMeIn Hamachi (MD5: 0554f3b69d39d175dd110d765c11347a)
• LMIGuardianDll.dll — loader malevolo che patcha una Windows API e prepara il payload
• .hamachi.lng — payload Deed RAT cifrato con AES-128-CBC

Il meccanismo di evasione è raffinato: la DLL distribuisce la logica malevola su due export separati, Init e ComMain. La funzione Init patcha silenziosamente l’API Windows StartServiceCtrlDispatcherW in memoria, poi termina senza rivelare comportamenti sospetti. Il payload si attiva solo quando l’applicazione legittima raggiunge la chiamata patchata nel suo flusso naturale. Il risultato pratico: le sandbox di analisi automatica che eseguono la DLL in isolamento non osservano alcun comportamento malevolo — il malware rimane completamente inerte senza il contesto applicativo completo.

Seconda ondata: tentativo con Terndoor via Mofu Loader

Circa un mese dopo, FamousSparrow è tornato con un secondo backdoor: Terndoor, caricato attraverso il Mofu Loader. La catena sfruttava USOShared.exe (rinominato da deskband_injector64.exe) per sideloadare winmm.dll malevolo. Il tentativo è stato bloccato dalla soluzione di sicurezza, ma le tracce forensi hanno rivelato il tentativo di installare un driver kernel (vmflt.sys) per persistenza a livello rootkit — una tecnica documentata da Cisco Talos nel report UAT-9244.

Terza ondata: Deed RAT con C2 aggiornato

A fine febbraio 2026, gli attaccanti sono tornati per la terza volta con Deed RAT aggiornato. Le modifiche principali: magic DWORD aggiornato da 0xDEED4554 a 0xFF66ABCD, compressione plugin da Snappy a Deflate, nuovi target per l’injection (wininit.exe, dwm.exe), e nuovo C2: sentinelonepro[.]com:443. La scelta di un dominio che imita SentinelOne, un noto vendor di sicurezza, è emblematica della cura con cui FamousSparrow costruisce l’infrastruttura per eludere l’attenzione degli analisti.

Movimento laterale: RDP, Domain Admin e Impacket

Con persistenza stabilita sul primo host, gli attaccanti si sono spostati lateralmente via RDP verso un secondo server, autenticandosi con un account Domain Administrator — a indicare che le credenziali privilegiate erano già state compromesse. Da quel secondo host hanno poi usato utility in stile Impacket (atexec, smbexec) per propagarsi su un terzo sistema. La sequenza — accesso RDP, apertura console PowerShell, download del malware in pochi minuti — è la firma di un attore con un playbook collaudato.

Indicatori di compromissione

# Deed RAT - Prima ondata
MD5 LMIGuardianSvc.exe:  0554f3b69d39d175dd110d765c11347a
Path installazione:       C:\Program Files (x86)\LogMeIn Hamachi\
Magic header:             0xFF66ABCD (vecchio: 0xDEED4554)
C2 Prima variante:        HTTPS://virusblocker[.]it[.]com:443
C2 Terza variante:        HTTPS://sentinelonepro[.]com:443
# Web shell ProxyNotShell (Exchange)
File:  key.aspx, log.aspx, errorFE_.aspx, signout_.aspx
Path:  directory accessibili via web su Exchange server
# Terndoor - Seconda ondata
Loader:        C:\ProgramData\USOShared\USOShared.exe
DLL malevola:  C:\ProgramData\USOShared\winmm.dll
Driver kernel: C:\ProgramData\USOShared\vmflt.sys
Registry:      HKLM\SYSTEM\ControlSet001\Services\vmflt
# IOC completi: github.com/bitdefender/malware-ioc/
# File: 2026_05_13-famoussparrow-iocs.csv

Due righe per i difensori

• Patch immediata dei server Exchange esposti: ProxyShell e ProxyNotShell sono vulnerabilità note dal 2021-2022. Qualsiasi Exchange non patchato esposto a internet deve essere considerato compromesso
• Monitorare w3wp.exe: il processo IIS worker non dovrebbe mai scrivere file .aspx in directory pubblicamente accessibili nel contesto MSExchangePowerShellAppPool
• Rilevamento API hooking: monitorare modifiche ai primi byte di API Windows critiche (StartServiceCtrlDispatcherW, CreateProcessW) da parte di binari non firmati
• Alert RDP con credenziali DA: sessioni RDP da host interni con account Domain Administrator al di fuori delle finestre di manutenzione devono innescare alert immediati
• Rotazione credenziali post-compromissione: qualsiasi dichiarazione di remediation completata che non includa la rotazione delle credenziali Domain Admin è incompleta per definizione

La capacità di FamousSparrow di tornare sullo stesso accesso per tre ondate consecutive, adattando il toolset ma mantenendo il canale di ingresso, è la lezione operativa centrale di questa campagna: la remediation che rimuova il malware senza affrontare la vulnerabilità sottostante e ruotare le credenziali non è remediation — è una pausa.

(in)sicurezza digitale

2026-05-20 14:41:42

Intelligenza artificiale, responsabilità e cybersicurezza: il punto sul convegno di Cagliari

Si parla di:
Toggle

Nel grande auditorium dell’ARNAS G. Brotzu di Cagliari, si parla di intelligenza artificiale, responsabilità e cybersicurezza nel sistema sanitario nazionale. Sul palco si alternano dirigenti pubblici, giuristi, esperti di compliance, rappresentanti istituzionali e figure di primo piano della sicurezza informatica italiana.

Un convegno importante per far diventare la cybersicurezza un tema per tutti

I temi sono quelli inevitabili del momento: AI generativa, governance del dato, regolamentazione europea, rischio cyber, continuità operativa, resilienza.

Il tono è solenne, spesso tecnico, quasi rassicurante. Si parla di protezione delle infrastrutture critiche, di necessità di regolamentare l’uso dell’intelligenza artificiale, di responsabilità giuridica e organizzativa. Ma mentre scorrono le slide e si susseguono gli interventi, emerge una sensazione difficile da ignorare: manca il protagonista principale di tutta questa discussione. Il dato sanitario reale. Quello che ogni giorno viene esposto, rubato, venduto, pubblicato o utilizzato senza controllo.

Il convegno è stato un momento di grande opportunità per innescare discussioni sul tema a me molto a cuore: la cybersicurezza nazionale. E gli interventi sono stati un momento importante per sentire punti di vista e situazione attuale nel campo della sanità. Ciò che mi piacerebbe introdurre con questo articolo, vista la qualità della discussione introdotta dal convegno, è la necessità come paese Italia di fare un passo indietro rispetto a ciò che attualmente occupa il maggior spazio nelle scrivanie decisionali, di vedere cosa davvero sta succedendo ai dati dei cittadini italiani.

Il mio intento con questo intervento è quello di farci porre delle domande affinché si possano innescare processi per migliorare eventuali situazioni quotidiane.

Il dato sanitario purtroppo è già ovunque

C’è un paradosso evidente. Tutti concordano sul fatto che il dato sanitario sia “speciale”, “sensibile”, “delicato”, “meritevole di protezione rafforzata”. Eppure quasi nessuno affronta davvero cosa accade quando questi dati finiscono fuori controllo. Nessuno racconta il destino concreto delle cartelle cliniche sottratte durante gli attacchi ransomware. Gli unici interventi che si sono avvicinati a centrare questo punto sono stati il brillante discorso introduttivo del Gen CdA Luciano Carta e quello del Gen CdA Leandro Cuzzocrea entrambi con una visione estramente strategica del mondo criminale dei dati. Che poi è esattamente ciò che occorre su questo tema al Paese Italia.

Nessuno spiega dove finiscono referti, analisi, documenti oncologici, dati psicologici, informazioni genetiche o amministrative una volta pubblicati sui leak site dei gruppi criminali. Nessuno sembra voler affrontare il fatto che, in Italia, gli attacchi contro strutture sanitarie non siano scenari ipotetici o eventualità remote, ma eventi ormai sistematici.

Basta osservare quanto monitorato negli ultimi anni da piattaforme indipendenti come quella sviluppata e mantenuta da me Ransomfeed, che da tempo traccia le rivendicazioni ransomware pubblicate dai gruppi criminali a livello globale. Nel database compaiono ASL, aziende ospedaliere universitarie, strutture territoriali, centri diagnostici e realtà sanitarie italiane finite nel mirino di operatori ransomware ovunque nel tempo: c’è Lazio Crea del 2020 ma dopo quello ce ne sono nel 2021, 2022, 2023, 2024, 2025. Non episodi isolati, ma una sequenza costante di compromissioni che racconta un fenomeno strutturale. Alcuni casi sono rimasti confinati ai disservizi temporanei; altri hanno comportato la sottrazione e pubblicazione di grandi quantità di documentazione sanitaria e amministrativa.

È assolutamente prioritario e strategico sapere e far sapere a tutti i cittadini che questi Terabyte di dati persi nell’Internet e nelle mani criminali, sono gli stessi dati alla base di altri attacchi personali ai cittadini. Sono spesso la risposta alla domanda che spesso ci poniamo su Come ha fatto questo numero sconosciuto dall’Africa a inviarmi un SMS/messaggio Whatsapp, con una truffa a tema bancario?

Eppure, durante il convegno, il tema dominante sembra essere soprattutto la resilienza operativa. Il backup. Il ripristino rapido. La continuità del servizio. Elementi certamente fondamentali, ma che spesso finiscono per ridurre il problema cyber a una semplice questione di disponibilità dei sistemi. Come se il vero obiettivo fosse soltanto “riaccendere tutto il prima possibile”. Come se la perdita definitiva del controllo sui dati fosse un danno secondario.

Ma nel settore sanitario il problema non è soltanto il downtime. È la persistenza del danno. Un referto medico pubblicato online non può essere “ripristinato” da un backup. Una diagnosi oncologica esfiltrata non può essere annullata. Una banca dati sanitaria sottratta e venduta può continuare a circolare per anni in forum criminali, marketplace underground, archivi privati o circuiti di estorsione. E questo aspetto sembra quasi assente dal dibattito istituzionale.

Dico quasi perché effettivamente mi sono ritrovato molto nel discorso conclusivo del Prof. UNICAL Mario Caligiuri, che in qualche modo ha tracciato una “strada del pericolo” di quello che realmente sta già accadendo da anni.

Anche l’AI non è nemica, il problema è caricarci dentro dati sensibili

Lo stesso discorso vale per l’intelligenza artificiale. Sul palco si discute di AI Act, governance, responsabilità dell’algoritmo, supervisione umana. Ma raramente emerge una domanda molto più concreta: cosa accade quando personale sanitario, amministrativo o tecnico inizia a utilizzare chatbot di AI generativa caricando documenti clinici, referti o informazioni dei pazienti? Dove finiscono quei dati? Come vengono trattati? Vengono conservati? Utilizzati per training? Processati da terze parti? Quali controlli esistono realmente nelle strutture pubbliche?

È una questione enorme, eppure ancora affrontata in modo marginale. In molte realtà sanitarie italiane manca completamente una cultura operativa capace di gestire questi strumenti. Il rischio non è teorico. È quotidiano.

Basta osservare cosa accade negli ospedali: porte USB liberamente utilizzabili, workstation condivise, installazione incontrollata di software terzi, accessi a servizi cloud esterni, credenziali riutilizzate, navigazione senza restrizioni, segmentazione di rete insufficiente. In alcuni casi persino software obsoleti e dispositivi medicali non aggiornabili continuano a convivere con infrastrutture moderne.

Tutto questo è sicuramente governance, ma non che sia ancora da normare. È tutto perfettamente normato, ma l’attuale infrastruttura non ne permette la precisa attuazione, purtroppo, all’interno della pubblica amministrazione, come invece avviene da decenni nelle grandi aziende private (come giustamente indicato dal responsabile della sicurezza informatica di Poste Italiane, Rocco Mammoliti).

Il contrasto tra il linguaggio istituzionale del convegno e la realtà operativa percepibile sul campo è netto. Da una parte la narrazione strategica, fatta di regolamenti, framework e governance. Dall’altra la quotidianità di strutture spesso prive di risorse adeguate, personale insufficiente, processi fragili e superfici di attacco enormi. E soprattutto una mancanza cronica di trasparenza pubblica su ciò che avviene dopo un incidente.

Anche il post incidente è una questione di sicurezza

Perché il vero nodo è anche questo: in Italia si parla pochissimo delle conseguenze concrete degli attacchi cyber sulla sanità. Quando una struttura viene colpita, il dibattito si concentra sul blocco dei servizi, sulle prenotazioni sospese, sui disagi temporanei. Molto meno sulla sorte dei dati sottratti. Raramente i cittadini vengono informati in modo chiaro su cosa sia stato realmente esfiltrato, dove quei dati possano finire o quali rischi futuri possano derivarne.

Ed è forse proprio qui che emerge il limite più evidente di molti eventi istituzionali sul tema cybersecurity: la distanza tra il racconto teorico della sicurezza e la realtà pratica delle compromissioni. La cybersicurezza sanitaria non può essere ridotta a compliance normativa o disaster recovery. Richiede una presa di coscienza molto più dura: i dati sanitari italiani sono già oggi un bersaglio costante del cybercrime internazionale, e in molti casi sono già stati sottratti.

Continuare a trattare questi temi come eccezioni anziché come parte di una crisi strutturale rischia di produrre soltanto altra burocrazia, altra documentazione e altri tavoli tecnici. Mentre nel mondo reale, i leak site ransomware continuano ad aggiornarsi. Ogni settimana. Anche con nomi italiani.

Ransomfeed

^Ransomfeed