Rete di memoria bidirezionale a breve termine integrata in blockchain per il rilevamento in tempo reale delle intrusioni nell'Internet delle Cose Mediche nel settore sanitario

Sommario

Questo protocollo descrive l'implementazione di un sistema di rilevamento di intrusioni di memoria a breve termine bidirezionale integrato nella blockchain per reti Internet delle Cose Mediche sanitarie, che consente il rilevamento di attacchi in tempo reale, la registrazione forense a prova di manomissione e la mitigazione automatica.

Abstract

Gli ambienti di Internet delle Cose Mediche (IoMT) nel settore sanitario richiedono sistemi di rilevamento delle intrusioni che non solo identifichino con precisione gli attacchi informatici, ma offrano anche responsabilità forense, revisione e capacità di risposta rapida. Gli approcci convenzionali di rilevamento delle intrusioni enfatizzano principalmente le prestazioni di classificazione, offrendo al contempo un supporto limitato per la registrazione degli eventi a prova di manomissione e per l'indagine post-incidente. Questo studio presenta un framework di rilevamento delle intrusioni consapevole della forense che integra una rete Bidirezionale Estesa a Long Short-Term Memory (BiLSTM) con uno strato blockchain autorizzato per supportare la rilevazione in tempo reale, la registrazione sicura e la mitigazione automatica nei sistemi IoMT sanitari. Il protocollo combina preprocessing dei dati, selezione delle funzionalità AQU-IMF-RFE, modellazione temporale delle sequenze, apprendimento basato sull'attenzione, connessioni residue e registrazione di eventi basata su blockchain. Il modello BiLSTM esteso è stato addestrato e valutato indipendentemente sui dataset benchmark UNSW-NB15, CICIDS2017 e Bot-IoT utilizzando preprocessing riproducibile, partizionamento stratificato dei dati e seed casuali fissi. Gli eventi di intrusione rilevati dal modello sono stati registrati su una blockchain Proof-of-Authority tramite smart contract che hanno permesso logging immutabile e azioni di risposta automatica. I risultati sperimentali hanno dimostrato elevate prestazioni di rilevamento dell'intrusione con bassi tassi di falsi positivi su tutti i dataset valutati, mantenendo al contempo la tracciabilità forense e la capacità di risposta in tempo reale. Il livello blockchain forniva registri di audit a prova di manomissione e mitigazione automatica senza introdurre un overhead computazionale proibitivo. Questi risultati dimostrano che integrare il rilevamento delle intrusioni basato sul deep learning con il logging forense abilitato dalla blockchain migliora l'affidabilità, la responsabilità e la possibilità di implementazione pratica dei sistemi di cybersecurity sanitaria.

Introduzione

Nel sistema sanitario, la digitalizzazione ha portato a una nuova era di servizi sanitari intelligenti, connessi e centrati sul paziente. L'infrastruttura medica moderna si basa fortemente sulla comunicazione di rete e sullo scambio di dati tra sensori indossabili, sistemi di monitoraggio remoto dei pazienti, cartelle cliniche elettroniche (EHR^)1,2 e piattaforme diagnostiche intelligenti. Tuttavia, questa crescente interconnessione amplia anche la superficie di attacco delle reti sanitarie, esponendole a minacce informatiche come violazioni di dati, ransomware, attacchi DDoS distribuiti e attacchi^{man-in-the-middle 3}. Queste intrusioni comportano perdite finanziarie sostanziali e, cosa più importante, possono compromettere la sicurezza del paziente quando dati medici sensibili o funzionalità critiche del dispositivo vengono compromesse.

La scala e la complessità dei sistemi Internet of Medical Things (IoMT) aggravano ulteriormente queste sfide di sicurezza. Le reti sanitarie moderne devono fornire contemporaneamente comunicazioni a bassa latenza, alta affidabilità e garanzie di sicurezza robuste, requisiti che i meccanismi di sicurezza tradizionali spesso faticano a soddisfare⁴. La rapida crescita del traffico IoMT, caratterizzata da fonti di dati eterogenee, schemi di comunicazione dinamici e rigorosi requisiti normativi come il Health Insurance Portability and Accountability Act (HIPAA) e il General Data Protection Regulation (GDPR), richiede sistemi intelligenti di rilevamento intrusioni (IDS) in grado di raggiungere alti tassi di rilevamento minimizzando i falsi^{allarmi 5}.

Negli ambienti sanitari regolamentati, il rilevamento delle intrusioni non è solo un requisito operativo, ma anche una funzione di responsabilità. Gli avvisi di sicurezza possono attivare l'isolamento del dispositivo, compromettere la continuità dell'assistenza e successivamente diventare soggetti a audit, revisioni normative o indagini legali. Di conseguenza, un IDS IoMT efficace deve fornire una rilevazione accurata in tempo reale, decisioni spiegabili che supportino il triage degli incidenti e registrazioni a prova di manomissione che garantiscano la non ripudiazione e la tracciabilità^{forense 6}. Questo requisito sposta l'obiettivo del rilevamento delle intrusioni dalla classificazione incentrata sulle prestazioni a una governance della sicurezza incentrata sulla fiducia e sulla responsabilità.

Le tecniche di deep learning, in particolare le reti di Long Short-Term Memory (LSTM) e Bidirectional Long Short-Term Memory (BiLSTM), hanno dimostrato una forte capacità nel modellare le dipendenze temporali all'interno del traffico di rete e nel rilevare comportamenti anomali⁷. Tuttavia, gli IDS basati su BiLSTM esistenti spesso soffrono di sovrafitting, insufficiente attenzione agli eventi temporali critici e limitata generalizzazione tra dispositivi IoMT eterogenei e ambienti sanitari. Inoltre, le reti IoMT sono esposte a una vasta gamma di minacce informatiche che influenzano la Riservatezza, l'Integrità e la Disponibilità (CIA) dei dati e dei servizi medici, come riassunto nella Tabella 1.

Tipo di attacco	Contesto IoMT	Dimensione CIA colpita	Impatto sui sistemi sanitari
Accesso nonautorizzato 19	Sfruttamento di meccanismi di autenticazione deboli per accedere ai dispositivi dei pazienti o alle cartelle cliniche	Riservatezza, Integrità	Perdita di dati e controllo non autorizzato di dispositivi medici
Parodia /Impersonificazione 19	Un dispositivo malevolo imita un nodo IoMT legittimo	Integrità	Letture errate che possono portare a diagnosi errate o trattamenti insicuri
Origliare 21	Intercettazione di dati medici non criptati durante la trasmissione	Riservatezza	Violazioni della privacy ed esposizione di informazioni sensibili sui pazienti
Manipolazione dei dati / Exploit firmware19	Modifica del firmware del dispositivo o dei dati sanitari trasmessi	Integrità	Diagnosi errata o decisioni terapeutiche inappropriate
Ransomware20	Crittografia dei dati del paziente o firmware dei dispositivi medici	Disponibilità, Integrità	Blocco dei sistemi critici e ritardi nei trattamenti
Denial-of-Service (DoS) / Denial-of-Service distribuito (DDoS)6	Sovraccarico di dispositivi medici o reti sanitarie	Disponibilità	Interruzioni del servizio che influenzano i sistemi di monitoraggio e le operazioni delle unità di terapia intensiva (ICU)
Attacchi nel canalelaterale 22	Estrazione di chiavi crittografiche tramite tecniche di temporizzazione o analisi di potenza	Riservatezza	Compromessa del dispositivo e furto di chiavi crittografiche

Tabella 1: Attacchi informatici comuni che colpiscono gli ambienti sanitari dell'Internet delle Cose Mediche. Questa tabella riassume gli attacchi informatici rappresentativi che prendono di mira i sistemi Internet of Medical Things (IoMT), il loro contesto operativo, le dimensioni di sicurezza di Riservatezza, Integrità e Disponibilità (CIA) interessate e il loro potenziale impatto sull'erogazione delle cure sanitarie, la sicurezza dei pazienti e il funzionamento dei dispositivi medici.

La tecnologia blockchain offre diversi vantaggi che possono integrare il rilevamento delle intrusioni negli ambienti IoMT. Come riassunto nella Tabella 2, la blockchain consente la registrazione immutabile degli eventi per la validazione forense, facilita la mitigazione automatica tramite smart contract, elimina i singoli punti di guasto tramite operazioni decentralizzate e supporta la conformità alle normative sulla protezione dei dati sanitari mantenendo tracce di audit tracciabili. Nonostante questi benefici, i meccanismi di sicurezza basati su blockchain rimangono sottoutilizzati negli IDS sanitari.

Caratteristiche	Descrizione	Benefici nel contesto sanitario
Integrità dei Dati	Ogni transazione è crittograficamente hashata e collegata al blocco precedente	Garantisce l'immutabilità delle cartelle cliniche e dei dispositivi
Rilevamento di manomissioni	Qualsiasi modifica ai dati memorizzati modifica l'hash del blocco e invalida la catena	Consente il rilevamento rapido di modifiche non autorizzate dei record
Controllo degli accessi	Gli smart contract fanno rispettare permessi predefiniti e politiche di autorizzazione	Restringe l'accesso alle informazioni sanitarie sensibili agli utenti autorizzati e ai dispositivi
Provenienza dei dati	Ogni evento è firmato digitalmente e con timestamp	Supporta la tracciabilità forense, la revisione e la conformità normativa
Consenso a bassa latenza	Il meccanismo di consenso Proof-of-Authority (PoA) consente una validazione rapida delle transazioni con un overhead computazionale inferiore rispetto alla Proof-of-Work	Supporta la registrazione degli eventi quasi in tempo reale in ambienti sanitari critici

Tabella 2: Benefici della tecnologia blockchain per la sanità Internet delle Cose Mediche sistemi di rilevamento intrusioni. Questa tabella riassume le principali funzionalità blockchain e i loro benefici associati negli ambienti sanitari dell'Internet delle Cose Mediche (IoMT). Le capacità elencate supportano la registrazione immutabile, il rilevamento di manomissioni, il controllo degli accessi, la provenienza dei dati e meccanismi di consenso a bassa latenza necessari per un rilevamento sicuro e auditabile dell'intrusione.

Oltre alla valutazione delle prestazioni, l'integrazione blockchain offre protezione contro molteplici minacce alla sicurezza negli ambienti IoMT. La Tabella 3 riassume i punti di forza e i limiti della blockchain in questo contesto, evidenziando minacce che sono efficacemente mitigate, come la manomissione e la ripudiazione dei dati, e le minacce che richiedono ulteriori salvaguardie. Il livello blockchain supporta logging a bassa latenza adatto agli ambienti sanitari in tempo reale, resilienza bizantina contro nodi difettosi o dannosi, e scalabilità su reti ospedaliere distribuite e dispositivi IoMT.

Minaccia alla sicurezza	Risolto dalla blockchain?	Meccanismo	Note
Manomissione dei dati27	Sì	Collegamento crittografico degli hash	Qualsiasi modifica invalida l'integrità della catena
Ripudio 26	Sì	Firme digitali associate a ogni blocco	Previene la negazione degli eventi di intrusione registrati
Guastocentralizzato 25	Sì	Registro distribuito mantenuto tra gateway autorizzati	Elimina un singolo punto di guasto
Attacco Sybil24	Parziale	Consenso procuratoriale autorizzato che richiede validatori affidabili	Può essere mitigato tramite l'autorizzazione del validatore basata sull'identità
51%Attacco 23	Parziale	Richiede la compromessa della maggioranza dei validatori autorizzati	Meno probabile nelle implementazioni private di blockchain PoA
Data Provenance26	Sì	Record degli eventi con timestamp e firmati digitalmente	Supporta la tracciabilità forense e la conformità normativa

Tabella 3: Minacce alla sicurezza affrontate dall'integrazione blockchain negli ambienti sanitari Internet of Medical Things. Questa tabella riassume le principali minacce alla sicurezza rilevanti per i sistemi dell'Internet delle Cose Mediche (IoMT) e indica fino a che punto la tecnologia blockchain mitighi ciascuna minaccia. I meccanismi di protezione sottostanti e le considerazioni di implementazione sono forniti per ciascuna categoria di minaccia.

La maggior parte degli IDS esistenti si basa su regole predefinite o su modelli di apprendimento automatico^{leggeri 8,9}. Sebbene tali approcci possano identificare schemi di attacco noti, spesso faticano a far fronte alla natura dinamica e in evoluzione delle minacce informatiche moderne. Sono particolarmente inadeguati per garantire infrastrutture sanitarie basate sull'IoMT in rapida crescita, dove falsi allarmi, limitata adattabilità e scarsa revisionibilità possono influire significativamente sull'efficienza operativa. I sistemi basati su regole generano frequentemente alti tassi di falsi positivi perché non riescono a distinguere in modo affidabile anomalie benigne da attacchi reali⁹. I modelli convenzionali di apprendimento automatico addestrati su dataset statici o obsoleti, così come gli approcci esistenti di rilevamento di intrusioni basati sul deep learning, spesso non generalizzano i comportamenti di attacco emergenti, inclusi gli intrusioni^{zero-day 10,11}. Inoltre, gli approcci tradizionali di logging centralizzato rimangono vulnerabili alle manomissioni, limitando così l'affidabilità delle indagini forensi^{post-incidenti 12}. Molte soluzioni IDS esistenti impongono anche un notevole overhead computazionale, rendendole difficili da implementare su dispositivi IoMT e gateway¹³ con risorse limitate. Di conseguenza, gli ambienti IoMT sanitari rimangono vulnerabili a attacchi informatici sofisticati e multistadio. Affrontare queste sfide richiede un framework intelligente, sicuro ed efficiente dal punto di vista delle risorse, capace di apprendere i modelli temporali del traffico in tempo reale, garantendo al contempo l'affidabilità forense e la mitigazione automatica delle minacce rilevate.

Nonostante i significativi progressi nel machine learning e nel rilevamento delle intrusioni basato su deep learning, rimangono diverse lacune critiche. Innanzitutto, molti modelli IDS esistenti vengono sviluppati e valutati utilizzando dataset statici e quindi mancano di adattabilità ai comportamenti di attacco in continua evoluzione. In secondo luogo, sebbene le architetture avanzate di deep learning possano migliorare la precisione del rilevamento, spesso offrono un'interpretabilità limitata e non danno priorità ai modelli di traffico clinicamente importanti. In terzo luogo, e più importante, i quadri IDS attuali generalmente non forniscono un supporto intrinseco per l'affidabilità forense, l'auditabilità o la tenuta immutabile dei registri, capacità essenziali per la conformità normativa, l'indagine sugli incidenti e la responsabilità legale nei sistemi sanitari.

Sebbene i meccanismi di logging basati su blockchain forniscano integrità e trasparenza dei dati, raramente sono integrati in modo coerente con modelli avanzati di rilevamento di intrusioni basati su deep learning in ambienti IoMT sensibili alla latenza. Gli studi esistenti si concentrano tipicamente sul miglioramento delle prestazioni di rilevamento senza affrontare l'integrità forense, oppure su meccanismi di sicurezza basati su blockchain senza incorporare una rilevazione avanzata delle anomalie temporali. Di conseguenza, rimane una lacuna significativa nello sviluppo di un framework unificato in grado di offrire simultaneamente rilevamento di intrusioni spazio-temporali in tempo reale, registrazione forense a prova di manomissione, mitigazione automatica e implementazione pratica in ambienti sanitari IoMT eterogenei e limitati in risorse.

Motivato da queste sfide, questo studio mira a sviluppare un framework di rilevamento delle intrusioni che migliori le reti BiLSTM attraverso meccanismi di attenzione e strati personalizzati per una migliore priorità temporale delle caratteristiche, integri la tecnologia blockchain per un logging di intrusioni sicuro e verificabile e una risposta automatizzata, e operi in modo efficiente in contesti sanitari IoMT in tempo reale. Ipotizziamo che integrare un'architettura BiLSTM estesa migliorata con attenzione con la registrazione forense basata su blockchain e meccanismi automatizzati di mitigazione migliorerà l'efficacia del rilevamento delle intrusioni, fornendo allo stesso tempo l'auditabilità, l'affidabilità e la responsabilità richieste negli ambienti sanitari regolamentati.

Questo lavoro affronta una lacuna fondamentale nella ricerca sulla sicurezza dell'IoMT, trattando il rilevamento delle intrusioni come un problema di responsabilità forense piuttosto che solo come un problema di classificazione. Il framework proposto integra il rilevamento guidato dall'intelligenza artificiale (IA), la registrazione immutabile degli eventi e i meccanismi di risposta automatica in un'architettura unificata che supporta la sicurezza clinica, la conformità normativa e la fiducia operativa. La crescente adozione di dispositivi IoMT e infrastrutture sanitarie connesse al cloud ha reso le reti sanitarie bersagli attraenti per attacchi informatici, inclusi ransomware, manipolazione dei dati, accessi non autorizzati e attacchi di denial-of-service che minacciano la riservatezza, l'integrità e la disponibilità delle informazioni dei pazienti. Il framework proposto Extended BiLSTM–Blockchain stabilisce un processo di sicurezza a ciclo chiuso che collega direttamente il rilevamento degli attacchi alla validazione forense e alla mitigazione automatica.

I principali contributi di questo studio sono cinque. Innanzitutto, viene sviluppato un modello di rilevamento dell'intrusione temporale allineato clinicamente estendendo un'architettura BiLSTM convenzionale con apprendimento temporale bidirezionale, connessioni residue, meccanismi di attenzione e strati personalizzati per migliorare la rilevazione di pattern di attacco complessi nel traffico delle reti sanitarie. In secondo luogo, uno strato di sicurezza leggero basato su blockchain è integrato con il modello BiLSTM Esteso per fornire una registrazione immutabile, sicura e a prova di manomissione degli eventi di intrusione e delle azioni di sistema. In terzo luogo, è stata sviluppata una pipeline IDS end-to-end in tempo reale per ambienti sanitari, che consente analisi del traffico in tempo reale e previsione delle intrusioni con bassa latenza e alta precisione. In quarto luogo, il framework proposto viene valutato in modo completo utilizzando tre dataset benchmark pubblicamente disponibili, ovvero UNSW-NB15, CICIDS2017 e Bot-IoT. Infine, l'architettura è progettata come un framework edge-cloud scalabile ed estesibile adatto per una distribuzione pratica in reti sanitarie, infrastrutture mediche e applicazioni e-health.

Combinando le capacità di apprendimento temporale delle reti BiLSTM estese con la fiducia e l'immutabilità offerte dalla tecnologia blockchain, il framework proposto offre un IDS sicuro e affidabile, adattato alle esigenze di cybersecurity in evoluzione degli ambienti sanitari. Il quadro colma le lacune critiche nella sicurezza delle reti sanitarie e stabilisce le basi per un'adozione più ampia dell'integrazione di IA e blockchain nella protezione delle infrastrutture sanitarie critiche.

Protocollo

Tutti gli esperimenti sono stati condotti esclusivamente utilizzando dataset di benchmark di intrusione di rete pubblicamente disponibili (UNSW-NB15, CIC-IDS-2017 e Bot-IoT), che contengono registri del traffico di rete senza informazioni personali o mediche identificabili. I dataset sono stati utilizzati in conformità con le rispettive licenze e i termini di utilizzo. Poiché non erano coinvolti partecipanti umani, campioni di pazienti o dati personali identificabili, non erano necessarie l'approvazione etica istituzionale e il consenso informato.

Panoramica del Quadro Proposto
Questa sezione presenta il framework proposto per il rilevamento e la prevenzione dell'intrusione a doppio livello per la sicurezza degli ambienti IoMT. Il framework integra una rete BiLSTM estesa per il rilevamento di intrusioni spazio-temporali con uno strato blockchain leggero per la registrazione a prova di manomissioni e mitigazione automatica. A differenza degli approcci IDS convenzionali che si concentrano esclusivamente sulla precisione del rilevamento, l'architettura proposta è progettata per supportare contemporaneamente la rilevazione in tempo reale, la responsabilità forense e la conformità normativa, requisiti essenziali nei sistemi sanitari. Il flusso di lavoro complessivo e l'architettura del framework proposto per il rilevamento delle intrusioni BiLSTM–Blockchain Extended per le reti IoMT sono illustrati nella Figura 1.

Figura 1. Architettura del framework proposto per il rilevamento di intrusioni Extended BiLSTM–Blockchain per reti Internet of Medical Things. Rappresentazione schematica del framework proposto che mostra i flussi di lavoro di formazione e implementazione. Nel flusso di lavoro di addestramento, i dispositivi Internet of Medical Things (IoMT) generano traffico di rete che subisce preprocessing dati e ingegneria delle funzionalità prima di essere analizzato con attenzione temporale dal modello Extended Bidirectional Long Short-Term Memory (BiLSTM). I parametri del modello sono ottimizzati tramite calcolo della funzione di perdita e addestramento iterativo. Nel flusso di lavoro di implementazione, il modello addestrato esegue il rilevamento delle intrusioni secondo la funzione decisionale definita nell'Equazione 13. Gli eventi di intrusione rilevati vengono inoltrati al modulo blockchain, dove vengono effettuati logging immutabili, isolamento dei nodi e generazione di avvisi da parte degli amministratori. BiLSTM, Memoria Bidirezionale a Breve Termine; IoMT, Internet delle cose mediche. Clicca qui per visualizzare una versione più grande di questa figura.

I dispositivi IoMT generano flussi di dati eterogenei costituiti da traffico di rete, metadati dei dispositivi e segnali relativi al paziente. Tali input grezzi sono spesso rumorosi, ridondanti e incoerenti, rendendoli inadatti all'addestramento diretto del modello. Pertanto, viene applicata una pipeline di preprocessing per garantire la qualità e la struttura dei dati prima di inserirli nel modello Extended BiLSTM. Il pseudocodice dettagliato della preprocessing è fornito nell'Algoritmo 1 (File Supplementare 1), che delinea la pipeline di preprocessing applicata ai flussi dati IoMT prima dell'addestramento BiLSTM Esteso (pseudocodice nel File Supplementare 1; implementazione nel File Supplementare 2). L'architettura completa di BiLSTM estesa è riassunta nell'Algoritmo 2 (Supplementary File 1).

Flusso di lavoro di riproduzione end-to-end
Lo studio completo può essere riprodotto utilizzando i passaggi seguenti. Software e hardware sono elencati nell'Ambientazione Sperimentale, e il codice supplementare copre ogni passaggio.

Scarica i dataset → scarica UNSW-NB15. Usa i file UNSW_NB15_training-set.csv e UNSW_NB15_testing-set.csv. Scarica CICIDS2017. Usa i cinque file giornalieri MachineLearningCSV (dal lunedì al venerdì). Scarica Bot-IoT. Usa i file del sottoinsieme al 5% UNSW_2018_IoT_Botnet_Full5pc_1_to_4. I precedenti studi di rilevamento delle intrusioni si basavano comunemente su dataset benchmark come KDD Cup 99,¹⁴; tuttavia, questo studio utilizza i più recenti dataset UNSW-NB15, CICIDS2017 e Bot-IoT per rappresentare meglio il traffico di rete contemporaneo. Elabora ogni dataset separatamente. Il dataset UNSW-NB15 è disponibile presso l'Università del New South Wales a https://research.unsw.edu.au/projects/unsw-nb15-dataset (ultima modifica: 8 febbraio 2024). Il dataset CICIDS2017 è disponibile presso il Canadian Institute for Cybersecurity al https://www.unb.ca/cic/datasets/ids-2017.html (rilasciato: luglio 2017). Il dataset Bot-IoT è disponibile presso l'Università del New South Wales a https://research.unsw.edu.au/projects/bot-iot-dataset (ultima modifica: 5 febbraio 2024). Tutti i dataset sono stati consultati a maggio 2025 per questo studio.

Pre-elaborare i dati → rimuovere i record corrotti. Riempire i valori mancanti usando mezzi dell'allenamento. Applicare la riduzione del rumore EMA (α = 0,3). Normalizzare le caratteristiche a [0,1] utilizzando statistiche degli insiemi di addestramento. Campi categoriali con etichetta e codifica. Costruisci finestre scorrevoli (T = 20, passo = 1). Questi passaggi di preprocessing supportano una rilevazione robusta delle intrusioni riducendo il rumore e migliorando la qualità delle rappresentazioni del traffico di rete per gli IDS basati su apprendimento^{automatico 15,16}.

Seleziona le caratteristiche (AQU-IMF-RFE) → Classifica le caratteristiche tramite informazioni comuni. Affina con l'Aquila Optimizer. Applicare la RFE Random Forest con validazione incrociata a 10 volte. Conserva le caratteristiche finali. Questa strategia ibrida di selezione delle caratteristiche segue il concetto più ampio di combinare tecniche complementari di rilevamento^{intrusioni 17} ed è implementata utilizzando il framework AQU-IMF-RFE sviluppato nel nostro lavoro^{precedente 18}.

Addestrare il modello → Per ogni dataset, i dati sono stati suddivisi casualmente in set di addestramento (80%) e test (20%) utilizzando un seed casuale fisso di 42. Il venti percento della partizione di addestramento era ulteriormente riservato come set di validazione. Costruisci il BiLSTM esteso. Allenarsi usando perdita binaria di entropia incrociata ponderata e l'ottimizzatore Adam (tasso di apprendimento = 0,001, dimensione del lotto = 64, massimo di 50 epoche, con fermata anticipata). Salva il modello addestrato. L'uso di modelli di deep learning temporale è ben adatto al traffico eterogeneo^{IoMT 19}. Il flusso di lavoro completo dell'addestramento del modello è riassunto nell'Algoritmo 3 (File Supplementare 1). I pesi finali delle classi venivano calcolati automaticamente dalle distribuzioni delle classi del set di addestramento secondo le Equazioni 19 e 20. I pesi di classe risultanti furono i seguenti: UNSW-NB15: , ; CICIDS2017: , ; e Bot-IoT (sottoinsieme del 5%): , . Il grande valore di w_n per il dataset Bot-IoT riflette la grave sottorappresentazione di campioni benigni nella partizione di addestramento del sottoinsieme del 5%.

Implementare la blockchain → avviare la catena di Proof-of-Authority (PoA). Installa lo smart contract e annota il suo indirizzo. Autorizza gli account gateway. Esegui il client in modo che ogni intrusione rilevata venga registrata e attivi isolamenti e allarmi. Il flusso di lavoro completo di rilevamento, registrazione della blockchain e mitigazione è riassunto nell'Algoritmo 4 (File Supplementare 1). Il livello blockchain è stato implementato utilizzando il client go-ethereum (Geth) versione 1.13.15 per gestire la rete PoA autorizzata, il compilatore Solidity (solc) versione 0.8.19 per la compilazione e distribuzione di smart contract e la libreria web3.py versione 6.15.1 per la comunicazione tra IDS e la rete blockchain.

Valuta → Testa il modello sul set di test esposto. Calcolare accuratezza, precisione, richiamo, punteggio F1 e tasso di falsi positivi. Registrare latenza e throughput. Verifica l'integrità del registro blockchain. Il flusso di lavoro completo della valutazione è riassunto nell'Algoritmo 5 (File Supplementare 1). La latenza di rilevamento (T_d) è stata misurata immediatamente prima della chiamata di inferenza del modello fino al momento in cui sono state restituite le probabilità previste. La latenza di mitigazione end-to-end (T_d +_{T b}) è stata misurata dallo stesso punto di partenza fino al completamento della corrispondente transazione di creazione di blocchi blockchain. La velocità di lavoro veniva calcolata come il numero totale di finestre di test preprocessate elaborate dalla pipeline completa di rilevamento e registrazione, diviso per il tempo di orologio a muro trascorso per un singolo passaggio completo attraverso il set di test di ciascun dataset. Il carico di lavoro consisteva nelle partizioni di test a finestre mantenendo la distribuzione originale di classi benigna all'intrusione. Le finestre dannose comportavano inoltre il sovraccarico di logging blockchain, mentre le finestre innocue sostenevano solo il costo di rilevamento intrusione.

Generare figure e tabelle → tracciare le curve di accuratezza e perdita, la matrice di confusione e i grafici di valutazione comparativa. Costruisci le tabelle di confronto. Il flusso di lavoro completo di generazione di figure e tabelle è riassunto nell'Algoritmo 6 (File Supplementare 1). Il codice sorgente completo sviluppato su misura utilizzato per generare tutte le figure e le tabelle è fornito nel Supplementary File 2. In particolare, lo script figures.py riproduce direttamente le figure del manoscritto dai risultati sperimentali salvati (ad esempio, cronologia dell'addestramento e file di matrice di confusione), mentre gli script rimanenti generano i dati elaborati e le metriche di performance utilizzate per costruire le tabelle riportate.

La Figura 2 è il flusso di dati a livello di implementazione tra i moduli IDS e blockchain. La BiLSTM estesa produce una decisione per finestra (Equazione 13); su una classificazione malevola, il client gateway costruisce e firma una transazione e la invia tramite web3/JSON-RPC allo smart contract PoA, che aggiunge un blocco hash-linked (Equazione 14) al registro immutabile ed emette eventi (BlockCreated, NodeIsolated e AdminAlert) che attivano l'isolamento dei nodi e gli avvisi degli amministratori.

Figura 2. Interazione a livello di implementazione tra il rilevamento intrusioni e i moduli blockchain. Diagramma del flusso di lavoro che illustra la comunicazione tra il sistema di rilevamento intrusioni e i componenti blockchain. Il modello BiLSTM esteso classifica ogni finestra di input e applica la regola decisionale definita nell'Equazione 13. Quando viene rilevata un'intrusione, il client gateway genera e firma una transazione che viene trasmessa tramite Web3.py/JSON-RPC allo smart contract Proof-of-Authority (PoA). Il contratto aggiunge un blocco collegato a hash al registro immutabile secondo l'Equazione 14 ed emette eventi BlockCreated, NodeIsolated e AdminAlert che attivano azioni di contenimento e notifica. IDS, Sistema di Rilevamento Intrusioni; BiLSTM, Memoria Bidirezionale a Breve Termine; Procura, Prova di autorità; JSON-RPC, JavaScript Object Notation–Chiamata procedura remota. Clicca qui per visualizzare una versione più grande di questa figura.

Rappresentazione dei dati
Consideriamo R come il flusso grezzo di traffico IoMT. Dopo la preelaborazione, ogni record grezzo viene mappato in un vettore di caratteristiche normalizzato a d dimensioni (Equazione 1):

(1)

Qui, f (⋅) è la funzione di trasformazione delle caratteristiche che mappa i record grezzi in un vettore di caratteristiche normalizzato a d dimensioni. Sia la rete IoMT composta da un insieme di nodi (Equazione 2):

N = {_{n 1} , n₂, ... , n_k} (2)

Ogni nodo _{n j} ∈ R produce un flusso di dati a serie temporale (Equazione 3):

(3)

Qui, x_t è il vettore di caratteristiche al tempo t, con d caratteristiche (ad esempio, dimensione del pacchetto, tipo di protocollo, indirizzo di origine/destinazione) comunemente osservate nel traffico di rete sanitaria^{dell'Internet delle Cose 19}. L'insieme corrispondente di etichette è (Equazione 4):

  (4)

Qui, y_t=0 rappresenta il traffico normale e y_t =1 indica un'intrusione.

Preprocessing dei dati
La pipeline di preprocessing include i seguenti passaggi, che affrontano le sfide comuni di qualità dei dati e di sicurezza associate al traffico^{IoMT 20}:

Pulizia dei dati e gestione dei valori mancanti:
Un record veniva identificato come corrotto e rimosso prima dell'imputazione se soddisfava una delle seguenti condizioni esplicite: (i) tutti i campi di caratteristica nel record erano mancanti (cioè, l'intero record era nullo), oppure (ii) il record conteneva un valore non finito (infinito positivo o negativo) in qualsiasi campo numerico dopo il tipo coercizione. La seconda regola rimuove voci non valide come quelle prodotte dalla divisione per zero durante il calcolo delle caratteristiche di flusso (ad esempio, valori infiniti di portata derivanti da flussi a durata zero). Dopo la rimozione dei record corrotti, i valori mancanti rimanenti venivano imputati tramite la sostituzione media calcolata per caratteristica, per dataset e solo dalla partizione di addestramento; I mezzi risultanti venivano applicati ai set di addestramento, validazione e test per prevenire la fuga di informazioni. L'imputazione non era condizionata alla classe e le medie non venivano aggregate tra i dataset.

Deruoting temporale:
La denoising temporale è stata eseguita utilizzando un filtro a media mobile esponenziale per caratteristica (EMA) applicato lungo l'asse temporale. È stata utilizzata la forma ricorsiva (causale ) y_t = α·x_t + (1 − α)·y_t−1 , con fattore di levigatura α = 0,3, implementata tramite la funzione ewm di pandas con adjust=False. Ogni caratteristica è stata smussata in modo indipendente. Come filtro esponenziale (risposta infinita all'impulso), l'EMA non ha una finestra o una dimensione del kernel fissa; Il fattore di levigatura α è il singolo parametro che regola il grado di levigatura e la memoria effettiva del filtro.

Normalizzazione Min–Max:
La normalizzazione min–max è stata applicata per scalare ogni caratteristica nell'intervallo [0,1] usando la trasformazione x′=(x−min)/(max−min+ε), dove ε = 1 × 10⁻⁸. Le statistiche minime e massime venivano calcolate per caratteristica, per dataset e solo dalla partizione di addestramento; Queste statistiche di addestramento memorizzate venivano poi applicate per normalizzare i set di addestramento, validazione e test, prevenendo la fuga di informazioni nascoste. Durante l'inferenza, i valori delle caratteristiche che uscivano dal campo di addestramento venivano ritagliati all'intervallo [0,1].

Codifica delle caratteristiche categoriche:
Le caratteristiche categoriche venivano convertite in forma numerica tramite codifica di etichette. Questo era applicato a tutte le variabili categoriche: in UNSW-NB¹⁵, i campi proto, servizio e stato; in Bot-IoT, il proto campo; CICIDS2017 non contiene campi categorici tra le caratteristiche selezionate. La codifica era implementata con LabelEncoder per variabile.

Finestra temporale per l'apprendimento sequenziale:
Il flusso di caratteristiche preelaborato è stato segmentato in sequenze di lunghezza fissa usando una finestra scorrevole di lunghezza T = 20 passi temporali con un passo di s = 1. Ogni finestra generata è stata validata prima dell'inclusione. Una finestra veniva accettata solo se conteneva esattamente T = 20 passi temporali consecutivi e tutti i valori delle caratteristiche erano finiti. I flussi più brevi di T = 20 record non producevano finestre. Questa configurazione (T = 20, s = 1, sovrapposizione al 95%) è stata applicata in modo coerente in tutti gli esperimenti e dataset. L'intero flusso di lavoro di preprocessing è riassunto nell'Algoritmo 1 (File Supplementare 1).

L'obiettivo della pre-elaborazione è consentire una mappatura predittiva dalle sequenze di input alle etichette di intrusione (Equazione 5).

(5)

parametrizzato da θ, che prevede se un evento sia benigno o malevolo.

Selezione delle caratteristiche tramite AQU-IMF-RFE
La selezione delle caratteristiche è stata effettuata utilizzando AQU-IMF-RFE, un metodo ibrido che integra Mutual Information (MI), l'Aquila Optimizer (AO) e la Recursive Feature Elimination (RFE), introdotti nel nostro lavoro^{precedente 18}. Il metodo funziona in tre fasi. Nella prima fase, l'informazione reciproca tra ogni caratteristica e l'etichetta della classe viene calcolata per ottenere una classifica iniziale di rilevanza. Nella seconda fase, l'Aquila Optimizer esegue una ricerca globale sui sottoinsiemi di caratteristiche candidate utilizzando le sue quattro strategie di ottimizzazione. Nella terza fase, il sottoinsieme raffinato viene passato attraverso l'eliminazione delle caratteristiche ricorsive con una validazione incrociata a 10 volte utilizzando uno stimatore Random Forest (RF).

L'Aquila Optimizer era configurato con una popolazione di 100 persone, un massimo di 10 iterazioni, un fattore di sfruttamento di 0,1, un tasso di apprendimento di 0,1 e un fattore di attrazione di 0,005. Applicato indipendentemente a ciascun dataset, AQU-IMF-RFE ha mantenuto 14 funzionalità per UNSW-NB15, 24 per CICIDS2017 e 12 per Bot-IoT. Il pseudocodice completo è fornito nel File Supplementare 1, e i sottoinsiemi di caratteristiche selezionati sono elencati nella Tabella 4.

Tabella 4A. Caratteristiche selezionate mantenute per UNSW-NB15
S. No.	Caratteristiche	Tipo	Categoria
1	dur	Numerico (float)	Base
2	sbytes	Numerico (intero)	Base
3	Tasso	Numerico (float)	Base
4	dload	Numerico (float)	Base
5	sinpkt	Numerico (float)	Tempo
6	Dinpkt	Numerico (float)	Tempo
7	sjit	Numerico (float)	Tempo
8	TCPrtt	Numerico (float)	Tempo
9	Sinack	Numerico (float)	Tempo
10	ackdat	Numerico (float)	Tempo
11	Smean	Numerico (intero)	Contenuto
12	ct_srv_src	Numerico (intero)	Collegamento
13	ct_dst_src_ltm	Numerico (intero)	Collegamento
14	ct_srv_dst	Numerico (intero)	Collegamento
Tabella 4B. Caratteristiche selezionate mantenute per CICIDS2017
S. No.	Caratteristiche
1	Porto di destinazione
2	Durata del flusso
3	Lunghezza totale dei pacchetti forwardi
4	Lunghezza totale dei pacchetti al contrario
5	Lunghezza massima del pacchetto in volontà
6	Lunghezza massima del pacchetto all'indietro
7	Lunghezza dei pacchetti media a ritroso
8	Pacchetti di flusso
9	Tempo massimo di interarrivo del flusso
10	Tempo Avanti Totale Inter-Arrivo
11	Lunghezza del colpo di testa in avanti
12	Lunghezza dell'intestazione all'indietro
13	Pacchetti in avanti al secondo
14	Lunghezza massima del pacchetto
15	Media della lunghezza del pacchetto
16	Deviazione standard della lunghezza del pacchetto
17	Varianza della lunghezza dei pacchetti
18	Dimensione media del pacchetto
19	Dimensione media dei segmenti al contrario
20	Byte in avanti del sottoflusso
21	Byte all'indietro del sottoflusso
22	Byte iniziali della finestra in avanti
23	Bytes iniziali della finestra al contrario
24	Lunghezza media del pacchetto in avanti
Tabella 4C. Funzionalità selezionate mantenute per Bot-IoT
S. No.	Caratteristiche	Tipo
1	seq	Numerico
2	Mean	Numerico
3	StdDev	Numerico
4	min	Numerico
5	Max	Numerico
6	Srate	Numerico (float)
7	drate	Numerico (float)
8	N_IN_Conn_P_SrcIP	Numerico (intero)
9	N_IN_Conn_P_DstIP	Numerico (intero)
10	proto	Categorico (codificato)
11	state_number	Numerico (intero)
12	Tasso	Numerico (float)

Tabella 4: Caratteristiche selezionate dal metodo di selezione delle caratteristiche AQU-IMF-RFE. Questa tabella elenca i sottoinsiemi finali di caratteristiche selezionati dal framework di selezione delle caratteristiche AQU-IMF-RFE per i dataset UNSW-NB15, CICIDS2017 e Bot-IoT. Sono forniti nomi di funzionalità, tipi di dati e categorie funzionali dove applicabile.

Configurazione sperimentale
Tutti gli esperimenti sono stati condotti su un server Dell PowerEdge R740 dotato di processore Intel Xeon Silver 4214 che operava a una frequenza base di 2,20 GHz, con 12 core fisici, 24 thread logici, 16,5 MB di cache e una velocità Intel Ultra Path Interconnect (UPI) di 9,6 GT/s. Il server era configurato con 128 GB di RAM, un disco SSD (SSD) da 512 GB e funzionava su Microsoft Windows 11. Lo stack software comprendeva Python 3.12.7, TensorFlow 2.16.1, scikit-learn 1.8.0, pandas 3.0.2 e NumPy 2.4.4. Il livello blockchain è stato implementato sulla stessa workstation utilizzando una rete Ethereum PoA. La comunicazione tra IDS e blockchain veniva effettuata tramite JSON-RPC utilizzando il client go-ethereum (Geth) versione 1.13.15, il compilatore Solidity (solc) versione 0.8.19 per la compilazione e distribuzione degli smart contract e la libreria Web3.py versione 6.15.1. Su questa configurazione hardware e software venivano misurati i tempi di addestramento, la latenza di inferenza e la velocità di addestramento.

Architettura dei modelli e formazione
Il modello BiLSTM esteso costituisce la componente principale di rilevamento del framework, basandosi su approcci precedenti di rilevamento di intrusione basati sull'apprendimento sviluppati per gli ambienti^{IoMT 21}. Studi precedenti di rilevamento delle intrusioni hanno evidenziato sia l'importanza di bilanciare le prestazioni di rilevamento con la riduzione dei falsi^{allarmi 15} sia le sfide uniche nell'applicare metodi di apprendimento automatico al traffico di rete^{in evoluzione 16}. Le architetture collaborative di rilevamento intrusione su reti neurali hanno ulteriormente dimostrato il valore dell'apprendimento sequenziale profondo delle caratteristiche per il traffico di rete^{complesso 22}. Mentre i modelli standard BiLSTM catturano dipendenze temporali bidirezionali, il traffico IoMT mostra sia schemi di burst a breve termine sia dipendenze a lungo raggio causate da attacchi multistadio. Per affrontare questo problema, il modello proposto estende BiLSTM con estrazione di caratteristiche temporali, apprendimento temporale bidirezionale migliorato, connessioni residue e priorità temporale basata sull'attenzione. Le LSTM bidirezionali (BiLSTM) superano questa limitazione combinando stati nascosti avanti e indietro, consentendo una rappresentazione temporale più ricca dei modelli di traffico IoMT, come indicato nell'Algoritmo 2 (File Supplementare 1).

Sia la sequenza di input X^{(_{n j})} = {_{x 1} , x₂ , ... , x_T }, dove ogni x_t ∈ R^d è un vettore di caratteristiche preelaborato.

Estrazione di caratteristiche temporali:
Una convoluzione leggera monodimensionale viene applicata attraverso la dimensione temporale per enfatizzare anomalie temporali a corto raggio (Equazione 6):

U = φ (Conv1D(X^{(_{n j})}), U = {u₁, u₂, ..., u_T } (6)

Qui, φ(⋅) è una funzione di attivazione non lineare e le caratteristiche convolute u_t vengono inviate al BiLSTM.

Il livello Conv1D estrae schemi temporali a corto raggio prima della modellazione bidirezionale delle sequenze. I parametri completi di implementazione sono forniti nel File Supplementare 3B.

Apprendimento LSTM bidirezionale impilato:
Gli stati nascosti avanti e indietro sono calcolati come (Equazione 7):

(7)

La rappresentazione finale della BiLSTM è la concatenazione degli stati nascosti passati (avanti) e futuri (indietro) (Equazione 8).

(8)

Due strati BiLSTM impilati modellano dipendenze temporali bidirezionali. I parametri architettonici dettagliati sono forniti nel File Supplementare 3B. I dettagli sull'inizializzazione dei pesi sono forniti nel Supplementare File 3B.

Connessione residua e normalizzazione
Dopo la proiezione lineare a dimensioni corrispondenti, si applicano connessioni residue e normalizzazione degli strati (Equazione 9):

La proiezione residua e la normalizzazione degli strati allineano le rappresentazioni convoluzionali e BiLSTM prima dell'attenzione. I parametri dettagliati di implementazione sono forniti nel Supplementary File 3B.

Meccanismo di attenzione
Sebbene BiLSTM fornisca una solida modellazione temporale, non tutti i passi temporali contribuiscono in modo uguale alla previsione. Per enfatizzare timestamp critici (ad esempio, picchi anomali improvvisi), viene introdotto un meccanismo di attenzione. A ogni stato nascosto viene assegnato un punteggio di rilevanza α_t per aumentare la precisione del rilevamento (Equazione 10).

Qui, W_a è un parametro allenabile e i pesi di attenzione soddisfano

Il vettore di contesto c aggrega gli stati nascosti in base alla loro importanza appresa (Equazione 11):

Il meccanismo dell'attenzione aggrega le rappresentazioni temporali in un vettore contestuale. I parametri dettagliati di implementazione sono forniti nel Supplementary File 3B.

Livello di Output e Classificazione
Il vettore contesto aggregato viene passato attraverso uno strato completamente connesso seguito da un'attivazione sigmoidea per ottenere la previsione finale (Equazione 12):

Qui, W_c e b_c sono parametri addestrabili, e σ(·) è la funzione di attivazione sigmoide che mappa l'uscita all'intervallo [0,1]. Si applica una soglia per classificare il traffico come benigno () o intrusivo ().

La regolarizzazione del dropout e la soglia di classificazione fissa utilizzata durante l'inferenza sono descritte nel File Supplementare 3B.

L'architettura Extended BiLSTM è identica nei tre dataset; solo la dimensione delle caratteristiche di input differisce, assumendo valori di 14, 24 e 12 rispettivamente per UNSW-NB15, CICIDS2017 e Bot-IoT. Poiché il livello Conv1D mappa qualsiasi input -dimensionale a una rappresentazione fissa a 64 canali, tutti i livelli successivi sono indipendenti dal dataset, e solo la forma in input e il conteggio dei parametri Conv1D variano con . L'architettura completa livello per livello è riassunta nella Tabella 5, con i conteggi dei parametri espressi in termini di d; I totali risultanti sono rispettivamente 184.641, 186.561 e 184.257 parametri addestrabili per D = 14, D = 24 e D = 12.

S. No.	Livello (Tipo)	Forma di uscita	Parametri addestrabili	Funzione di attivazione
1	Input	(20, d)	0	—
2	Conv1D (64 filtri, dimensione del nucleo = 3, stesso imbottitura)	(20, 64)	192d + 64	ReLU
3	LSTM bidirezionale Layer 1 (64 unità per direzione)	(20, 128)	66,048	tanh / sigmoid
4	LSTM Bidirezionale Layer 2 (64 unità per direzione)	(20, 128)	98,816	tanh / sigmoid
5	Proiezione residua densa	(20, 128)	8,320	Lineare
6	Aggiunta residua	(20, 128)	0	—
7	Normalizzazione dello strato (asse = −1, ε = 1 × 10⁻³)	(20, 128)	256	—
8	Attenzione temporale (Wa ∈ R¹²⁸×¹)	128	128	Softmax
9	Strato Nascosto Denso	64	8,256	ReLU
10	Abbandono (p = 0,3)	64	0	—
11	Strato di uscita denso	1	65	Sigmoid

Tabella 5: Architettura strato per strato del modello di memoria estesa bidirezionale a breve termine a lungo termine. Questa tabella riassume l'architettura del modello proposto di Extended Bidirectional Long Short-Term Memory (BiLSTM), inclusi tipi di livelli, dimensioni di output, conteggi di parametri addestrabili e funzioni di attivazione.

Il software e l'ambiente computazionale utilizzati per tutti gli esperimenti sono riassunti nella Tabella 6.

Componente	Versione / Specifiche
Sistema operativo	Finestre
Piattaforma server	Dell PowerEdge
CPU	Processore a 64 core
RAM	128 GB
Stoccaggio	SSD da 512 GB
Python	3.12.7
NumPy	2.4.4
Panda	3.0.2
scikit-learn	1.8.0
TensorFlow / Keras	2.16.1
Web3 (client blockchain)	6.15.1
eth-account	0.1
Compilatore Solidity (solc)	0.8.19
go-ethereum (Geth)	1.13.15

Tabella 6: Software e ambiente computazionale utilizzati per l'implementazione e la valutazione del framework proposto. Questa tabella riassume le specifiche hardware, i componenti software, gli strumenti blockchain e i numeri di versione utilizzati per la pre-elaborazione dei dati, la selezione delle funzionalità, l'addestramento dei modelli, il deployment della blockchain e la valutazione delle prestazioni.

Decisione di intrusione e risposta automatica
Il rilevamento delle intrusioni negli ambienti sanitari è efficace solo se seguito da una risposta rapida e da una mitigazione. Il Livello di Rilevamento delle Intrusioni converte la probabilità prevista in una decisione. Formalmente, la decisione di intrusione al passo temporale t è rappresentata come segue (Equazione 13):

Qui, è la probabilità di intrusione prevista al tempo t e è la soglia di classificazione.

Una volta rilevata un'intrusione, il Livello di Rilevamento dell'Intrusione interagisce direttamente con il modulo blockchain, che esegue logging immutabile, mitigazione automatica e applicazione della sicurezza in loop chiuso. I dettagli degli eventi, inclusi informazioni sulla fonte, le destinazioni e le caratteristiche selezionate del traffico, vengono registrati in un nuovo blocco blockchain. Gli smart contract eseguono azioni di mitigazione in tempo reale come l'isolamento dei nodi e gli avvisi degli amministratori. Questa architettura a circuito chiuso permette ai risultati del rilevamento delle intrusioni di inserire direttamente nei meccanismi di prevenzione, minimizzando così la latenza di mitigazione. Pertanto, il Livello di Rilevamento di Intrusione funge da ponte tra il rilevamento temporale utilizzando il modello BiLSTM esteso e la risposta sicura tramite la tecnologia blockchain, completando la funzionalità end-to-end del framework proposto.

Logging Forense Basato su Blockchain
Sebbene il modello BiLSTM esteso consenta il rilevamento in tempo reale delle intrusioni, lo storage sicuro e l'audit verificabile degli eventi di intrusione sono altrettanto critici negli ambienti sanitari IoMT. I tradizionali meccanismi di registrazione centralizzato sono vulnerabili a manomissioni e compromettono la tracciabilità forense. Per affrontare questa limitazione, il framework proposto incorpora un modulo blockchain leggero che garantisce immutabilità, decentralizzazione e risposta automatizzata basata su smart contract.

Ogni evento di intrusione rilevato genera un blocco che viene aggiunto alla blockchain. Un blocco B_i è definito come segue (Equazione 14):

Qui, H_i è l'hash crittografico dei dati dell'evento, del timestamp e del risultato della previsione, T_i è il timestamp, D_i contiene caratteristiche selezionate dell'evento di intrusione, Si_gi è la firma digitale e PrevHash collega il blocco al blocco precedente, garantendo immutabilità.

Questo design garantisce la resistenza alla manomissione perché qualsiasi modifica di D_i o T_i modifica l'hash del blocco e rompe l'integrità della catena. Fornisce anche l'auditabilità perché tutte le anomalie rilevate sono memorizzate e verificabili in modo permanente. La mitigazione automatica è supportata da smart contract che eseguono azioni predefinite come l'isolamento dei nodi e gli avvisi degli amministratori. La decentralizzazione si ottiene attraverso più gateway IoMT che mantengono il registro distribuito, eliminando così un singolo punto di guasto.

La generazione di blocchi utilizza la funzione hash crittografica Keccak-256, la primitiva di hashing nativa dell'ambiente Ethereum/Solidity (invocata tramite keccak256 di Solidity). Per ogni blocco intrusione, l'hash del blocco viene calcolato come segue:

Qui, D_i è il digest della caratteristica dell'evento, T_i è il timestamp e PrevHash è l'hash del blocco precedente. I campi vengono concatenati utilizzando la codifica compatta di Solidity (abi.encodePacked) prima dell'hashing, producendo un digest a 256 bit.

Lo stesso calcolo Keccak-256 è utilizzato dalla routine di verifica della catena, che ricalcola ogni hash di blocco dai campi memorizzati e conferma che corrisponde al valore registrato, convalidando così l'integrità della catena. Keccak-256 è stato scelto perché è l'algoritmo standard di hashing resistente alle collisioni utilizzato nativamente negli smart contract Ethereum. Lo smart contract è stato sviluppato in Solidity e compilato utilizzando il compilatore Solidity (solc) versione 0.8.19. È stato distribuito su una rete privata Ethereum Proof-of-Authority (PoA) gestita con Geth versione 1.13.15. La rete blockchain era configurata con quattro nodi validatori utilizzando il protocollo di consenso Clique Proof-of-Authority, un ID di catena di 9848, un periodo di blocco di 5 s e un limite di gas di blocco di 30.000.000. La comunicazione tra il motore di rilevamento intrusioni BiLSTM Esteso e il livello blockchain è stata implementata utilizzando la libreria Web3.py versione 6.15.1 tramite l'interfaccia HTTP JSON-RPC.

Meccanismo di consenso del PoA
Poiché i sistemi IoMT sanitari sono altamente sensibili alla latenza, il framework proposto impiega un meccanismo di consenso PoA invece del costoso Proof-of-Work (PoW)²³, dal punto di vista computazionale. In PoA, un insieme fisso di nodi validatori affidabili, come gateway ospedalieri, autorizza le transazioni, fornendo sia efficienza che resilienza.

La complessità temporale della validazione dei blocchi sotto PoW può essere espressa come segue (Equazione 15):

Qui, la d rappresenta la difficoltà di estrazione.

Al contrario, la complessità temporale del consenso PoA è espressa come segue (Equazione 16):

perché la validazione richiede solo la verifica con firma digitale da parte di nodi validatori autorizzati.

Di conseguenza, PoA offre operazioni a bassa latenza adatte agli allerti medici in tempo reale, efficienza energetica evitando mining ad alto livello computazionale e resilienza contro un numero limitato di validatori dannosi. La rete PoA era configurata con quattro nodi validatori, e questa configurazione è rimasta fissa in tutti gli esperimenti per garantire misurazioni coerenti della latenza, valutazione delle prestazioni riproducibili e confronti equi tra tutti i dataset di benchmark.

Implementazione della blockchain e gestione degli smart contract
La componente blockchain è stata implementata su una rete Ethereum autorizzata che opera secondo il modello di consenso^{PoA 24}. La rete veniva gestita utilizzando il client go-ethereum (Geth) con il protocollo di consenso Clique^{PoA 25}, in cui un insieme di nodi validatori autorizzati (sealer) è responsabile della produzione e convalidazione dei blocchi. Lo smart contract di intrusione logging (IoMTIntrusionLedger) è stato scritto in Solidity e distribuito su questa rete, seguendo architetture di sicurezza IoT basate su blockchain per la gestione sicura e decentralizzata degli eventi²⁶. Solo gli account gateway autorizzati on-chain (tramite la funzione di controllo accessi del contratto) potevano inviare record di intrusione, in linea con le architetture smart-contract blockchain autorizzate per le applicazioni Internet delle^{Cose 27}. Il livello blockchain è stato implementato utilizzando il client go-ethereum (Geth) versione 1.13.15 per il funzionamento della rete PoA autorizzata, il compilatore Solidity (solc) versione 0.8.19 per la compilazione e distribuzione di smart contract e la libreria Web3.py versione 6.15.1 per la comunicazione tra IDS e la rete blockchain.

I parametri dettagliati di implementazione e configurazione della blockchain sono forniti nel File Supplementare 3C.

Ogni record di intrusione viene firmato digitalmente prima di essere messo nel registro, supportando l'auditabilità sanitaria basata su blockchain e la tenuta sicura dei registri^{forensi 28}. Le procedure di generazione e verifica della firma digitale, inclusa ECDSA sulla curva secp256k1^29,30, sono descritte nel Supplementary File 3D. Ogni gateway contiene una coppia di chiavi Ethereum costituita da una chiave privata a 256 bit (32 byte) e dalla corrispondente chiave pubblica, da cui deriva l'indirizzo del conto; la generazione delle chiavi segue la procedura standard di Ethereum, utilizzando una chiave privata casuale a 256 bit crittograficamente sicura, con la chiave pubblica ottenuta tramite moltiplicazione scalare SECP256K1. Per creare una firma, il client gateway calcola il digest della caratteristica evento D_i e lo firma con la sua chiave privata utilizzando il formato di firma dei messaggi EIP-191, generando una firma da 65 byte composta dai componenti r, s e v. La firma viene inviata insieme al registro dell'intrusione. La verifica viene effettuata on-chain tramite lo smart contract: utilizzando il precompilato EVM ecreep, il contratto recupera l'indirizzo del firmatario dal digest firmato e dalla firma e richiede che sia uguale all'indirizzo del gateway autorizzato che invia la transazione. Se l'indirizzo recuperato non corrisponde a un gateway autorizzato, la transazione viene rifiutata. Questo lega ogni voce del registro a un gateway autorizzato specifico e impedisce registri di intrusione non autorizzati o falsificati.

Gli smart contract vengono attivati automaticamente al rilevamento di intrusioni, garantendo una risposta in tempo reale senza necessità di interventi manuali (Equazione 17):

(17)

Il modulo blockchain opera in parallelo con il classificatore BiLSTM Esteso. Una volta rilevata un'anomalia: (i) l'evento viene etichettato e classificato dal BiLSTM, (ii) un blocco viene generato, firmato e aggiunto al registro blockchain, e (iii) i contratti intelligenti applicano politiche di risposta automatica.

Lo smart contract di logging delle intrusioni (IoMTIntrusionLedger) mantiene un registro solo appendibile dei blocchi di intrusione e un registro degli account gateway autorizzati, esponendo le funzioni riassunte nella Tabella 7. Il contratto impone due ruoli di accesso tramite modificatori: onlyAdmin (l'amministratore che distribuisce il deployment) e onlyGateway (account autorizzati a inviare record di intrusione). Lo stato consiste nella mappatura di autorizzazione del gateway, nell'array del registro dei blocchi e nella testa della catena corrente (l'hash del blocco più recente).

S. No.	Funzione / Componente	Tipo	Accesso	Logica
1	costruttore	Costruttore	—	Imposta il deployer come amministratore e lo autorizza come gateway iniziale.
2	setGateway(indirizzo, bool)	Funzione	onlyAdmin	Aggiunge o rimuove un account gateway autorizzato; emette GatewayUpdated.
3	recordIntrusion(nodeId, patientId, attackClass, probabilityBp, dataDigest, signature, isolate)	Funzione	onlyGateway	Calcola Hi = Keccak-256(Di ∥ Ti ∥ probabilità ∥ PrevHash); verifica la firma ECDSA del gateway su Di tramite ecrecover; aggiunge il blocco al registro; avanza la testa della catena; emette BlockCreated, opzionalmente NodeIsolated e AdminAlert. Restituisce Hi.
4	verifyChain()	Funzione di visualizzazione	Pubblico	Ricalcola l'hash di ogni blocco dai campi memorizzati e verifica il collegamento PrevHash; restituisce la verità solo se l'intera catena è coerente (rilevamento delle manomissioni).
5	ledgerLength()	Funzione di visualizzazione	Pubblico	Restituisce il numero di blocchi nel registro.
6	_recoverSigner(hash, sig)	Funzione interna	—	Divide la firma da 65 byte in (r, s, v) e recupera l'indirizzo di firma tramite la precompilazione ecreper.
7	BlockCreated / NodeIsolated / AdminAlert / GatewayUpdated	Eventi	—	Emessa per ascoltatori off-chain per guidare logging (logging di nodi), isolamento dei nodi, avvisi amministratori e aggiornamenti del registro gateway.
8	onlyAdmin / onlyGateway	Modificatori	—	Limitare le funzioni rispettivamente all'amministratore e ai gateway autorizzati.

Tabella 7: Funzioni, eventi e componenti di controllo accessi dello smart contract IoMTIntrusionLedger. Questa tabella riassume le principali funzioni, eventi e modificatori di controllo accessi implementati all'interno dello smart contract blockchain autorizzato. Questi componenti supportano l'autorizzazione dei gateway, la registrazione delle intrusioni, la verifica blockchain, la generazione di eventi e la mitigazione automatica.

La proprietà di immutabilità della blockchain deriva direttamente dall'Equazione 14, dove qualsiasi modifica ai dati degli eventi o ai timestamp invalida la catena hash. La blockchain garantisce quindi integrità, tracciabilità e revisione dei dati per i sistemi sanitari attraverso registri forensi immutabili. I registri di intrusione di pazienti e dispositivi rimangono invariati una volta memorizzati, ogni blocco si collega in modo sicuro al blocco precedente consentendo la ricostruzione cronologica degli eventi, e gli amministratori o i regolatori sanitari possono verificare gli incidenti di intrusione senza rischio di falsificazione.

Funzione di perdita e ottimizzazione dei modelli
Il modello BiLSTM Esteso proposto affronta il problema della classificazione binaria ovvero distinguere tra traffico normale e eventi di intrusione nelle reti IoMT. Per guidare il processo di addestramento, viene adottata una perdita binaria di entropia incrociata (BCE), molto adatta agli output probabilistici dallo strato di attivazione sigmoide. Per un dataset con N campioni, la perdita è definita come segue (Equazione 18):

(18)

Qui, è l'etichetta di verità fondamentale della i^esima sequenza di input (0 = benigno, 1 = intrusione), ed è la probabilità prevista di intrusione.

Il framework funziona come una pipeline di classificazione a due fasi. Il primo stadio esegue il rilevamento di intrusione binaria: il BiLSTM esteso produce un'uscita sigmoide e applica la soglia τ = 0,5 per classificare ogni finestra come benigna o intrusiva (Equazioni 12,13), addestrata con perdita binaria ponderata di entropia incrociata. Un secondo stadio può eseguire la categorizzazione degli attacchi, in cui finestre identificate come intrusioni vengono passate a un classificatore multiclasse che assegna la specifica categoria di attacco utilizzando uno strato di output softmax addestrato con entropia incrociata categorica. Il presente studio si concentra e valuta la fase di rilevamento binario. I due stadi condividono la stessa spina dorsale di estrazione delle caratteristiche Extended BiLSTM (Conv1D, BiLSTM, residuo, normalizzazione e livelli di attenzione); differiscono solo per il loro livello di output (sigmoid per la rilevazione e softmax per la categorizzazione) e per la corrispondente funzione di perdita. La fase di rilevamento binario e la fase di categorizzazione multiclasse sono state addestrate e valutate secondo le stesse partizioni dati, seed casuale e condizioni di addestramento descritte sopra.

Sebbene il traffico IoMT sia spesso squilibrato, una perdita binaria ponderata di entropia incrociata viene utilizzata per penalizzare la classificazione errata della classe minoritaria. I pesi di classe vengono calcolati usando il numero di campioni di intrusione N_p, il numero di campioni benigni N_n e il numero totale di campioni N (Equazioni 19,20):

La ponderazione garantisce che il modello non sia orientato verso la classe dominante di traffico benigno e rimanga sensibile a eventi di intrusione rari ma critici.

La perdita binaria ponderata per entropia incrociata è data come segue (Equazione 21):

(21)

L'addestramento veniva svolto utilizzando mini-lotti di dimensione 64. All'inizio di ogni epoca, i campioni di addestramento venivano mescolati casualmente prima di essere suddivisi in lotti, in modo che la composizione dei lotti variasse tra le epoche e il modello non vedesse esempi in un ordine fisso. I lotti non erano esplicitamente bilanciati o stratificati per classe; invece, ogni lotto rifletteva la distribuzione naturale delle classi dell'insieme di addestramento, e lo squilibrio di classe veniva affrontato attraverso la perdita binaria di entropia incrociata ponderata per classe (Equazioni 19–21). Il sottoinsieme di validazione riservato dalla partizione di addestramento rimaneva fisso tra epoche e non veniva inserito nei lotti di addestramento.

I pesi delle classi nella perdita di entropia binaria binaria ponderata non sono stati impostati manualmente, ma sono stati calcolati automaticamente per ciascun dataset a partire dai conteggi delle classi del set di addestramento secondo le Equazioni 19 e 20. Per il dataset UNSW-NB15, i pesi di classe risultanti erano per la classe normale e per la classe intrusione. Per il dataset CICIDS2017, i pesi di classe risultanti erano per la classe normale e per la classe intrusione. Per il dataset Bot-IoT (sottoinsieme del 5%), i pesi di classe risultanti erano per la classe normale e per la classe intrusione.

Strategia di addestramento e ottimizzazione
Il modello Extended BiLSTM è stato addestrato utilizzando mini-batch di dimensione B = 64 con perdita binaria ponderata di entropia incrociata, l'ottimizzatore Adam e stop precoce basato sulla perdita di validazione. L'addestramento era limitato a 50 epoche e si applicava una fermata anticipata con pazienza K = 5. Se la perdita di validazione non migliorava per cinque epoche consecutive, l'addestramento veniva interrotto e i pesi del modello venivano ripristinati a quelli dell'epoca con la perdita di validazione più bassa. Pertanto, 50 epoche rappresentavano il budget massimo per la formazione piuttosto che una durata fissa di addestramento. Per la regolarizzazione è stata applicata una probabilità di abbandono di 0,3. Le impostazioni architettoniche includevano 64 filtri Conv1D, 64 unità LSTM per direzione, una finestra di lunghezza T = 20 e un passo di s = 1. La strategia di addestramento adottata è riassunta nell'Algoritmo 3 (File Supplementare 1). Le equazioni di aggiornamento Adam utilizzate per l'ottimizzazione sono fornite nel File Supplementare 3A.

L'ottimizzatore Adam era configurato con un tasso di apprendimento di , un tasso di decadimento al primo momento (β₁) di 0,9, un tasso di decadimento al secondo momento (β₂) di 0,999 e una costante di stabilità numerica () di 1 × 10-7. Non sono state utilizzate opzioni di ottimizzatore aggiuntive e non è stato applicato decay di peso o clipping di gradiente.

Generazione di Allarmi e Mitigazione Automatica
La sola rilevazione è insufficiente nelle reti IoMT sensibili alla latenza, dove una risposta rapida è fondamentale per garantire la sicurezza del paziente. Il Livello di Generazione e Mitigazione degli Allarmi operativizza la decisione di intrusione presa dal modello BiLSTM Esteso e dal meccanismo di logging della blockchain. Se δ_t = 1, il modulo blockchain aggiunge un nuovo blocco contenente i dettagli dell'intrusione . Contemporaneamente, viene eseguito uno smart contract per attivare azioni di mitigazione (Equazione 22):

(12)

Qui, BlockCreation garantisce una registrazione forense immutabile dell'evento, NodeIsolation (_{n j}) mette in quarantena il nodo IoMT compromesso per prevenire ulteriori danni e AdminAlert fornisce notifiche in tempo reale agli amministratori di sistema. Per operare questa pipeline di risposta a doppio livello, il pseudocodice viene presentato nell'Algoritmo 4 (File Supplementare 1).

L'elaborazione degli eventi smart-contract e i meccanismi di risposta off-chain sono descritti nel File Supplementare 3E.

Ogni voce che viene compilata nel registro blockchain viene memorizzata come un record IntrusionBlock, i cui campi e formati dati sono elencati nella Tabella 8. Il registro è un array solo appendibile di questi record, e la testa attuale della catena memorizza l'hash del blocco aggiunto più recentemente.

S. No.	Campo	Tipo di Dati	Dimensioni	Descrizione
1	hashID	bytes32	32 byte	Block hash Hi = Keccak-256(Di ∥ Ti ∥ probabilità ∥ PrevHash)
2	Timestamp	uint256	32 byte	Tempo di creazione del blocco Ti (secondi dell'epoca Unix, dal timestamp del blocco)
3	nodeId	bytes32	32 byte	Identificatore del nodo IoMT nj
4	patientId	bytes32	32 byte	Identificatore paziente/dispositivo (metadati forensi)
5	attackClass	uint16	2 byte	Codice della categoria d'attacco (0 = Normale, 1 = DDoS, 2 = Spoofing, ...)
6	probabilitàBp	uint16	2 byte	Probabilità di intrusione prevista ŷ in punti base (0–10000, cioè 0,00–100,00%)
7	dataDigest	bytes32	32 byte	DigestD i delle caratteristiche selezionate dell'evento
8	Firma	Byte	Variabile (65 byte)	Firma ECDSA Sigi del digest degli eventi dal gateway (r, s, v)
9	prevHash	bytes32	32 byte	Hash del blocco precedente (PrevHash), collegando la catena
10	isolata	bool	1 byte	Se l'isolamento dei nodi sia stato attivato per questo record

Tabella 8: Struttura del record IntrusionBlock memorizzato nel registro blockchain. Questa tabella descrive i campi, i tipi di dati, le dimensioni di archiviazione e gli scopi dei record del registro blockchain utilizzati per memorizzare eventi di intrusione. La struttura supporta la verifica dell'integrità crittografica, la tracciabilità forense e i meccanismi di risposta automatica.

La latenza complessiva di mitigazione può essere espressa come la somma del ritardo di rilevamento (T_d) dal modello Extended BiLSTM e del ritardo di esecuzione della blockchain (T_b) (Equazione 23):

(23)

Analisi della complessità computazionale
L'efficienza del framework BiLSTM–Blockchain esteso proposto è determinata sia dal costo computazionale del modello BiLSTM sia dal sovraccarico introdotto dal modulo blockchain. Il framework proposto integra il rilevamento BiLSTM esteso con il logging blockchain per soddisfare i requisiti di sicurezza fondamentali della triade Confidentiality, Integrity, and Availability (CIA).

Sia la lunghezza della sequenza di input preprocessata T, la dimensione delle caratteristiche d e la dimensione nascosta della BiLSTM h.

Per ogni passo temporale, un BiLSTM elabora input di dimensione d con dimensione nascosta h. Poiché è bidirezionale (avanti + indietro) (Equazione 24):

) (24)

Qui, T è la lunghezza della sequenza (passi di tempo), d è la dimensione delle caratteristiche di input, h è la dimensione di stato nascosta

Il livello di attenzione calcola i pesi di importanza e aggrega stati nascosti con complessità (Equazione 25).

(25)

che è lineare sia nella lunghezza della sequenza T sia nella dimensione nascosta h.

La complessità complessiva di rilevamento per sequenza è quindi indicata come segue (Equazione 26):

(26)

dimostrando che la modellazione temporale domina il costo computazionale, mentre il meccanismo di attenzione introduce solo un leggero sovraccarico.

Per ogni evento di intrusione rilevato, la registrazione della blockchain esegue operazioni di hashing, firma e aggiunta di blocchi (Equazione 27):

(27)

Per N eventi di rilevamento intrusione, la complessità combinata diventa la seguente (Equazione 28):

(28)

che può essere semplificato come segue (Equazione 29):

(29)

Perché il sovraccarico della blockchain cresce linearmente con il numero di eventi e rimane trascurabile rispetto ai calcoli di elaborazione di sequenze.

La complessità computazionale è riassunta nelle Equazioni 24–29. L'interpretazione dettagliata è fornita nel File Supplementare 3F.

Risultati

I risultati sono organizzati in modo da rispecchiare i passaggi metodologici del Protocollo, con ogni sottosezione che riporta le osservazioni prodotte dal corrispondente passaggio.

Gestione dei dataset e configurazione sperimentale
I tre dataset benchmark sono stati analizzati indipendentemente e non fusi. Poiché UNSW-NB15, CICIDS2017 e Bot-IoT utilizzano schemi di funzionalità e convenzioni di etichettatura differenti, ogni dataset è stat...

Discussione

Il presente studio propone un framework integrato Extended BiLSTM–Blockchain per il rilevamento e la prevenzione delle intrusioni negli ambienti IoMT. I risultati dimostrano che il framework identifica efficacemente i modelli di intrusione nel traffico eterogeneo di rete IoMT combinando apprendimento temporale bidirezionale con logging forense basato su blockchain. L'architettura bidirezionale consente al modello di catturare sia dipendenze temporali in avanti che all'indietro all'intern...

Materiali

Elenco dei materiali utilizzati in questo articolo

Nome	Azienda	Numero di catalogo	Commenti
AQU-IMF-RFE Feature Selection Module	Self-developed	N/A	Metodo di selezione delle caratteristiche ibrido che integra Mutual Information, Aquila Optimizer e Recursive Feature Elimination
Attention Layer	Self-developed (Keras-based)	N/A	Meccanismo di attenzione temporale utilizzato per il ponderamento delle caratteristiche nel modello Extended BiLSTM
Bot-IoT Dataset	UNSW Canberra Cyber	N/A	Dataset di benchmark pubblico utilizzato per la valutazione del rilevamento delle intrusioni
CICIDS2017 Dataset	Canadian Institute for Cybersecurity	N/A	Dataset di benchmark pubblico per il rilevamento delle intrusioni
Ethereum Client (Geth)	Ethereum Foundation	1.13.15	Client blockchain utilizzato per distribuire e gestire la rete Proof-of-Authority
Extended BiLSTM Model	Self-developed	N/A	Modello di rilevamento delle intrusioni basato su apprendimento profondo che integra Conv1D, BiLSTM, apprendimento residuale e attenzione temporale
Jupyter Notebook	Project Jupyter	7.x	Ambiente interattivo utilizzato per l'implementazione, la sperimentazione e la visualizzazione dei risultati
NumPy	NumPy Developers	2.4.4	Libreria per il calcolo numerico utilizzata per il pre-processing e l'addestramento del modello
Pandas	Pandas Development Team	3.0.2	Libreria per l'elaborazione dei dati utilizzata per il pre-processing e l'analisi dei dati
Proof-of-Authority Blockchain Network	Self-developed	N/A	Rete blockchain autorizzata utilizzata per la registrazione immutabile delle intrusioni e la mitigazione automatizzata
Python	Python Software Foundation	3.12.7	Lingua di programmazione utilizzata per il pre-processing dei dati, lo sviluppo del modello, l'integrazione blockchain e la valutazione
Random Forest Estimator	Scikit-learn Developers	N/A	Classificatore Random Forest utilizzato per Recursive Feature Elimination (RFE)
Scikit-learn	Scikit-learn Developers	1.8.0	Libreria di apprendimento automatico utilizzata per il pre-processing, la selezione delle caratteristiche e la valutazione del modello
Solidity Compiler (solc)	Solidity Team	0.8.19	Compilatore utilizzato per la compilazione e il deployment dei contratti intelligenti
Solid-State Drive (SSD)	Dell	512 GB	Archiviazione utilizzata per i dataset, i modelli addestrati e il registro blockchain
System Memory (RAM)	Dell	128 GB	Memoria principale utilizzata durante il pre-processing, l'addestramento del modello, l'esecuzione blockchain e la valutazione
TensorFlow	Google	2.16.1	Framework di apprendimento profondo utilizzato per implementare e addestrare il modello Extended BiLSTM
UNSW-NB15 Dataset	UNSW Canberra Cyber	N/A	Dataset di benchmark pubblico utilizzato per l'addestramento e la valutazione
Web3.py	Web3.py Developers	6.15.1	Interfaccia Python utilizzata per la comunicazione tra il sistema di rilevamento delle intrusioni e la rete blockchain
Windows Operating System	Microsoft	Windows 11	Sistema operativo utilizzato per tutti gli esperimenti
Workstation / Server	Dell	PowerEdge R740	Piattaforma di calcolo utilizzata per l'addestramento del modello, il deployment blockchain e la valutazione