Research Article

Rede de Memória Bidirecional Integrada a Blockchain de Curto Prazo para Detecção de Intrusões em Tempo Real na Internet de Saúde de Coisas Médicas

July 17th, 2026

In This Article

Summary

Loading...
$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Este protocolo descreve a implementação de um sistema de detecção de intrusões de memória bidirecional de curto prazo integrado em blockchain para redes da Internet das Coisas Médicas em saúde, permitindo detecção de ataques em tempo real, registro forense à prova de adulteração e mitigação automatizada.

Abstract

Loading...
$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Ambientes de Internet das Coisas Médicas (IoMT) em saúde exigem sistemas de detecção de intrusões que não apenas identifiquem ciberataques com precisão, mas também ofereçam responsabilidade forense, auditoria e capacidades de resposta rápida. Abordagens convencionais de detecção de intrusão enfatizam principalmente o desempenho da classificação, oferecendo suporte limitado para registro de eventos à prova de adulteração e investigação pós-incidente. Este estudo apresenta uma estrutura de detecção de intrusões com consciência forense que integra uma rede Bidirecional Estendida de Memória de Curto Prazo (BiLSTM) com uma camada de blockchain com permissão para suportar detecção em tempo real, registro seguro e mitigação automatizada em sistemas IoMT de saúde. O protocolo combina pré-processamento de dados, seleção de recursos AQU-IMF-RFE, modelagem de sequências temporais, aprendizado baseado em atenção, conexões residuais e gravação de eventos baseada em blockchain. O modelo BiLSTM Estendido foi treinado e avaliado independentemente nos conjuntos de dados de referência UNSW-NB15, CICIDS2017 e Bot-IoT usando pré-processamento reproduzível, particionamento de dados estratificado e sementes aleatórias fixas. Eventos de intrusão detectados pelo modelo foram registrados em uma blockchain de Prova de Autoridade por meio de contratos inteligentes que permitiam registros imutáveis e ações de resposta automatizada. Os resultados experimentais demonstraram alto desempenho em detecção de intrusões com baixas taxas de falsos positivos em todos os conjuntos de dados avaliados, mantendo rastreabilidade forense e capacidade de resposta em tempo real. A camada blockchain fornecia registros de auditoria resistentes a adulteração e mitigação automatizada sem introduzir uma sobrecarga computacional proibitiva. Essas descobertas demonstram que a integração da detecção de intrusões baseada em deep learning com o logging forense habilitado por blockchain melhora a confiabilidade, responsabilidade e implantabilidade prática dos sistemas de cibersegurança em saúde.

Introduction

Loading...
$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

No sistema de saúde, a digitalização levou a uma nova era de serviços de saúde inteligentes, conectados e centrados no paciente. A infraestrutura médica moderna depende fortemente da comunicação em rede e da troca de dados entre sensores vestíveis, sistemas remotos de monitoramento de pacientes, prontuários eletrônicos de saúde (EHRs)1,2 e plataformas inteligentes de diagnóstico. No entanto, essa interconectividade crescente também expande a superfície de ataque das redes de saúde, expondo-as a ameaças cibernéticas como vazamentos de dados, ransomware, ataques de negação de serviço distribuída (DDoS) e ataquesman-in-the-middle 3. Essas intrusões resultam em perdas financeiras substanciais e, mais importante, podem colocar em risco a segurança do paciente quando dados médicos sensíveis ou funcionalidades críticas de dispositivos são comprometidas.

A escala e complexidade dos sistemas da Internet das Coisas Médicas (IoMT) agravam ainda mais esses desafios de segurança. Redes modernas de saúde devem fornecer simultaneamente comunicação de baixa latência, alta confiabilidade e garantias robustas de segurança, requisitos que os mecanismos tradicionais de segurança frequentemente têm dificuldade emsatisfazer 4. O rápido crescimento do tráfego IoMT, caracterizado por fontes de dados heterogêneas, padrões de comunicação dinâmicos e exigências regulatórias rigorosas, como a Lei de Portabilidade e Responsabilidade de Seguros de Saúde (HIPAA) e o Regulamento Geral de Proteção de Dados (GDPR), exige sistemas inteligentes de detecção de intrusões (IDSs) capazes de alcançar altas taxas de detecção enquanto minimizam alarmesfalsos 5.

Em ambientes de saúde regulados, a detecção de intrusões não é apenas um requisito operacional, mas também uma função de responsabilização. Alertas de segurança podem acionar o isolamento do dispositivo, afetar a continuidade do cuidado e, posteriormente, se tornar alvo de auditorias, revisões regulatórias ou investigações legais. Consequentemente, um IDS IoMT eficaz deve fornecer detecção precisa em tempo real, decisões explicáveis que apoiem a triagem de incidentes e registros à prova de adulteração que garantam não repúdio e rastreabilidadeforense 6. Esse requisito desloca o objetivo da detecção de intrusões da classificação centrada em desempenho para uma governança de segurança centrada na confiança e na responsabilidade.

Técnicas de aprendizado profundo, particularmente redes de Memória de Curto Prazo Longo (LSTM) e Memória Bidirecional de Curto Prazo (BiLSTM), demonstraram forte capacidade em modelar dependências temporais dentro do tráfego de rede e detectar comportamentos anômalos7. No entanto, os IDSs baseados em BiLSTM existentes frequentemente sofrem com superajuste, atenção insuficiente a eventos temporais críticos e generalização limitada em dispositivos IoMT heterogêneos e ambientes de saúde. Além disso, as redes IoMT estão expostas a uma ampla gama de ameaças cibernéticas que afetam a Confidencialidade, Integridade e Disponibilidade (CIA) de dados e serviços médicos, conforme resumido na Tabela 1.

Tipo de AtaqueContexto do IoMTDimensão da CIA AfetadaImpacto nos Sistemas de Saúde
Acesso NãoAutorizado 19Exploração de mecanismos fracos de autenticação para acessar dispositivos de pacientes ou prontuários médicosConfidencialidade, IntegridadeVazamento de dados e controle não autorizado de dispositivos médicos
Falsificação / Personificação19Dispositivo malicioso imita um nó legítimo do IoMTIntegridadeLeituras falsas que podem levar a diagnósticos errados ou tratamentos inseguros
Escuta21Interceptação de dados médicos não criptografados durante a transmissãoConfidencialidadeViolações de privacidade e exposição de informações sensíveis de pacientes
Manipulação de Dados / Exploits de Firmware19Modificação do firmware do dispositivo ou dados de saúde transmitidosIntegridadeDiagnóstico incorreto ou decisões terapêuticas inadequadas
Ransomware20Criptografia de dados de pacientes ou firmware de dispositivos médicosDisponibilidade, IntegridadeBloqueio de sistemas críticos e atrasos no tratamento
Negação de Serviço (DoS) / Negação de Serviço Distribuída (DDoS)6Sobrecarga de dispositivos médicos ou redes de saúdeDisponibilidadeInterrupção do serviço afetando sistemas de monitoramento e operações da unidade de terapia intensiva (UTI)
Ataques por CanalLateral 22Extração de chaves criptográficas por meio de técnicas de temporização ou análise de energiaConfidencialidadeComprometimento de dispositivos e roubo de chaves criptográficas

Tabela 1: Ataques cibernéticos comuns que afetam ambientes de saúde da Internet das Coisas Médicas. Esta tabela resume ataques cibernéticos representativos que têm como alvo sistemas da Internet das Coisas Médicas (IoMT), seu contexto operacional, as dimensões de segurança de Confidencialidade, Integridade e Disponibilidade (CIA) afetadas, e seu impacto potencial na prestação de serviços de saúde, segurança do paciente e operação de dispositivos médicos.

A tecnologia blockchain oferece várias vantagens que podem complementar a detecção de intrusões em ambientes IoMT. Como resumido na Tabela 2, blockchain permite o registro imutável de eventos para validação forense, facilita mitigação automatizada por meio de contratos inteligentes, remove pontos únicos de falha por meio de operações descentralizadas e apoia a conformidade com as regulamentações de proteção de dados em saúde mantendo trilhas de auditoria rastreáveis. Apesar desses benefícios, os mecanismos de segurança baseados em blockchain continuam subutilizados nos IDSs de saúde.

CaracterísticaDescriçãoBenefícios no Contexto da Saúde
Integridade dos DadosCada transação é criptograficamente hashada e vinculada ao bloco anteriorGarante a imutabilidade dos registros de pacientes e dispositivos
Detecção de AdulteraçãoQualquer modificação nos dados armazenados altera o hash do bloco e invalida a cadeiaPermite detecção rápida de modificação não autorizada de registros
Controle de AcessoContratos inteligentes aplicam permissões e políticas de autorização pré-definidasRestringe o acesso a informações sensíveis de saúde a usuários autorizados e dispositivos
Proveniência dos DadosCada evento é assinado digitalmente e com carimbo de data e horaApoia rastreabilidade forense, auditoria e conformidade regulatória
Consenso de Baixa LatênciaO mecanismo de consenso Proof-of-Authority (PoA) permite validação rápida de transações com menor sobrecarga computacional do que a Proof-of-WorkSuporta registro de eventos quase em tempo real em ambientes críticos de saúde

Tabela 2: Benefícios da tecnologia blockchain para sistemas de detecção de intrusões na Internet das Coisas Médicas na saúde. Esta tabela resume as principais funcionalidades do blockchain e seus benefícios associados em ambientes de Internet das Coisas Médicas (IoMT) em saúde. As capacidades listadas suportam registros imutáveis, detecção de adulteração, controle de acesso, procedência de dados e mecanismos de consenso de baixa latência necessários para a detecção segura e auditável de intrusões.

Além da avaliação de desempenho, a integração com blockchain oferece proteção contra múltiplas ameaças de segurança em ambientes IoMT. A Tabela 3 resume os pontos fortes e limitações do blockchain nesse contexto, destacando ameaças que são efetivamente mitigadas, como manipulação e rejeição de dados, e ameaças que exigem salvaguardas adicionais. A camada blockchain suporta registro de baixa latência adequado para ambientes de saúde em tempo real, resiliência bizantina contra nós defeituosos ou maliciosos, e escalabilidade em redes hospitalares distribuídas e dispositivos IoMT.

Ameaça à SegurançaResolvido pelo Blockchain?MecanismoNotas
Manipulação de Dados27SimLigação de hash criptográficaQualquer modificação invalida a integridade da cadeia
Repudiação 26SimAssinaturas digitais associadas a cada blocoPrevine a negação de eventos de intrusão registrados
FalhaCentralizada 25SimLivro-razão distribuído mantido entre gateways autorizadosElimina um único ponto de falha
Ataque Sybil24ParcialConsenso de Procuração Autorizado exigindo validadores confiáveisPode ser mitigado por meio da autorização de validador baseada em identidade
51% Ataque23ParcialRequer o comprometimento da maioria dos validadores autorizadosMenos provável em implantações privadas de blockchain PoA
Proveniência dos Dados26SimRegistros de eventos com carimbo de data e assinatura digitalApoia rastreabilidade forense e conformidade regulatória

Tabela 3: Ameaças de segurança abordadas pela integração do blockchain em ambientes de Internet das Coisas Médicas em saúde. Esta tabela resume as principais ameaças de segurança relevantes para sistemas da Internet das Coisas Médicas (IoMT) e indica até que ponto a tecnologia blockchain mitiga cada ameaça. Os mecanismos de proteção subjacentes e as considerações de implementação são fornecidos para cada categoria de ameaça.

A maioria dos IDSs existentes depende de regras pré-definidas ou modelos leves de aprendizadode máquina 8,9. Embora tais abordagens possam identificar padrões de ataque conhecidos, elas frequentemente têm dificuldades para lidar com a natureza dinâmica e em constante evolução das ameaças cibernéticas modernas. Eles são particularmente inadequados para garantir infraestruturas de saúde baseadas em IoMT em rápido crescimento, onde alarmes falsos, adaptabilidade limitada e baixa auditabilidade podem afetar significativamente a eficiência operacional. Sistemas baseados em regras frequentemente geram altas taxas de falsos positivos porque não conseguem distinguir de forma confiável anomalias benignas de ataquesgenuínos 9. Modelos convencionais de aprendizado de máquina treinados com conjuntos de dados estáticos ou desatualizados, assim como as abordagens existentes de detecção de intrusões baseadas em deep learning, frequentemente falham em generalizar comportamentos emergentes de ataque, incluindo intrusõeszero-day 10,11. Além disso, as abordagens tradicionais de registro centralizado continuam vulneráveis a adulterações, limitando assim a confiabilidade das investigações forensespós-incidente 12. Muitas soluções IDS existentes também impõem um overhead computacional substancial, tornando-as difíceis de implantar em dispositivos e gateways IoMT com recursoslimitados 13. Como resultado, os ambientes IoMT em saúde continuam vulneráveis a ataques cibernéticos sofisticados e em múltiplas etapas. Enfrentar esses desafios exige uma estrutura inteligente, segura e eficiente em recursos, capaz de aprender padrões temporais de tráfego em tempo real, ao mesmo tempo em que garante confiabilidade forense e mitigação automática das ameaças detectadas.

Apesar dos avanços significativos em aprendizado de máquina e detecção de intrusões baseada em deep learning, permanecem várias lacunas críticas. Primeiro, muitos modelos IDS existentes são desenvolvidos e avaliados usando conjuntos de dados estáticos e, portanto, carecem de adaptabilidade a comportamentos de ataque em constante evolução. Segundo, embora arquiteturas avançadas de deep learning possam melhorar a precisão da detecção, elas frequentemente oferecem interpretabilidade limitada e falham em priorizar padrões de tráfego clinicamente importantes. Terceiro, e mais importante, os atuais frameworks de IDS geralmente não fornecem suporte intrínseco para confiabilidade forense, auditabilidade ou manutenção de registros imutável, capacidades essenciais para conformidade regulatória, investigação de incidentes e responsabilidade legal nos sistemas de saúde.

Embora os mecanismos de registro baseados em blockchain ofereçam integridade e transparência dos dados, raramente são integrados de forma coesa com modelos avançados de detecção de intrusões baseados em deep learning em ambientes IoMT sensíveis à latência. Estudos existentes normalmente focam em melhorar o desempenho da detecção sem abordar a integridade forense ou em mecanismos de segurança baseados em blockchain sem incorporar detecção avançada de anomalias temporais. Consequentemente, permanece uma lacuna significativa no desenvolvimento de uma estrutura unificada capaz de fornecer simultaneamente detecção de intrusões espaço-temporais em tempo real, registro forense à prova de adulteração, mitigação automatizada e implantação prática em ambientes IoMT de saúde heterogêneos e com recursos limitados.

Motivado por esses desafios, este estudo visa desenvolver uma estrutura de detecção de intrusões que aprimore as redes BiLSTM por meio de mecanismos de atenção e camadas personalizadas para melhorar a priorização de características temporais, integre tecnologia blockchain para registro de intrusões seguro e verificável e resposta automatizada, e opere de forma eficiente em ambientes de IoMT em tempo real em saúde. Hipotetizamos que integrar uma arquitetura BiLSTM Estendida aprimorada com atenção com registros forenses baseados em blockchain e mecanismos automatizados de mitigação aumentará a eficácia da detecção de intrusões, ao mesmo tempo em que proporciona a auditoriabilidade, confiabilidade e responsabilidade necessárias em ambientes de saúde regulados.

Este trabalho aborda uma lacuna fundamental na pesquisa de segurança do IoMT ao tratar a detecção de intrusões como um problema de responsabilidade forense, e não apenas como um problema de classificação. A estrutura proposta integra detecção impulsionada por inteligência artificial (IA), registro imutável de eventos e mecanismos automatizados de resposta em uma arquitetura unificada que apoia a segurança clínica, conformidade regulatória e confiança operacional. A crescente adoção de dispositivos IoMT e infraestruturas de saúde conectadas à nuvem tornou as redes de saúde alvos atraentes para ataques cibernéticos, incluindo ransomware, manipulação de dados, acesso não autorizado e ataques de negação de serviço que ameaçam a confidencialidade, integridade e disponibilidade das informações dos pacientes. O framework BiLSTM–Blockchain Estendido proposto estabelece um processo de segurança em circuito fechado que conecta a detecção de ataques diretamente à validação forense e mitigação automatizada.

As principais contribuições deste estudo são cinquenta. Primeiro, um modelo de detecção de intrusões temporais clinicamente alinhado é desenvolvido estendendo uma arquitetura BiLSTM convencional com aprendizado temporal bidirecional, conexões residuais, mecanismos de atenção e camadas personalizadas para melhorar a detecção de padrões complexos de ataque no tráfego da rede de saúde. Segundo, uma camada de segurança leve baseada em blockchain está integrada ao modelo BiLSTM Estendido para fornecer registros imutáveis, seguros e à prova de adulteração de eventos de intrusão e ações do sistema. Terceiro, um pipeline IDS em tempo real de ponta a ponta é desenvolvido para ambientes de saúde, permitindo análise de tráfego ao vivo e previsão de intrusões com baixa latência e alta precisão. Quarto, o framework proposto é avaliado de forma abrangente usando três conjuntos de dados de referência públicos disponíveis, a saber: UNSW-NB15, CICIDS2017 e Bot-IoT. Por fim, a arquitetura foi projetada como uma estrutura de edge cloud escalável e extensível, adequada para implantação prática em redes de saúde, infraestruturas médicas e aplicações de e-saúde.

Ao combinar as capacidades de aprendizado temporal das redes BiLSTM Estendidas com a confiança e imutabilidade proporcionadas pela tecnologia blockchain, a estrutura proposta oferece um IDS seguro e confiável, adaptado às necessidades em evolução de cibersegurança dos ambientes de saúde. A estrutura preenche lacunas críticas na segurança das redes de saúde e estabelece uma base para uma adoção mais ampla da integração de IA e blockchain na proteção de infraestruturas críticas de saúde.

Protocol

Loading...
$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Todos os experimentos foram conduzidos exclusivamente usando conjuntos de dados de intrusão de rede de referência públicos (UNSW-NB15, CIC-IDS-2017 e Bot-IoT), que contêm registros de tráfego de rede sem informações pessoais ou médicas identificáveis. Os conjuntos de dados foram usados de acordo com suas respectivas licenças e termos de uso. Como não houve participantes humanos, amostras de pacientes ou dados pessoais identificáveis envolvidos, não foi necessário aprovação ética institucional nem consentimento informado.

Visão geral do Quadro Proposto
Esta seção apresenta a proposta de estrutura de detecção e prevenção de intrusão em duas camadas para proteger ambientes IoMT. A estrutura integra uma rede BiLSTM Estendida para detecção de intrusões espaço-temporais com uma camada de blockchain leve para registro à prova de adulteração e mitigação automatizada. Ao contrário das abordagens convencionais de IDS, que focam exclusivamente na precisão da detecção, a arquitetura proposta é projetada para suportar simultaneamente detecção em tempo real, responsabilidade forense e conformidade regulatória, requisitos essenciais em sistemas de saúde. O fluxo de trabalho geral e a arquitetura do framework de detecção de intrusão BiLSTM–Blockchain proposto para redes IoMT são ilustrados na Figura 1.

figure-protocol-1
Figura 1. Arquitetura do framework proposto de detecção de intrusão BiLSTM–Blockchain estendido para redes da Internet das Coisas Médicas. Representação esquemática da estrutura proposta mostrando os fluxos de trabalho de treinamento e implantação. No fluxo de trabalho de treinamento, dispositivos da Internet das Coisas Médicas (IoMT) geram tráfego de rede que passa por pré-processamento de dados e engenharia de recursos antes de serem analisados pelo modelo Bidirecional de Memória Prolongada de Curto Prazo (BiLSTM) com atenção temporal. Os parâmetros do modelo são otimizados por meio de computação da função de perda e treinamento iterativo. No fluxo de trabalho de implantação, o modelo treinado realiza a detecção de intrusão de acordo com a função de decisão definida na Equação 13. Eventos de intrusão detectados são encaminhados para o módulo blockchain, onde são realizados registros imutáveis, isolamento de nós e geração de alertas por parte dos administradores. BiLSTM, Memória Bidirecional de Curto Prazo Longo; IoMT, Internet das Coisas Médicas. Por favor, clique aqui para ver uma versão ampliada desta figura.

Dispositivos IoMT geram fluxos de dados heterogêneos compostos por tráfego de rede, metadados de dispositivos e sinais relacionados ao paciente. Tais entradas brutas são frequentemente ruidosas, redundantes e inconsistentes, tornando-as inadequadas para treinamento direto do modelo. Portanto, um pipeline de pré-processamento é aplicado para garantir a qualidade e a estrutura dos dados antes de introduzi-los no modelo BiLSTM Estendido. O pseudocódigo detalhado de pré-processamento é fornecido no Algoritmo 1 (Arquivo Suplementar 1), que descreve o pipeline de pré-processamento aplicado aos fluxos de dados IoMT antes do treinamento BiLSTM Estendido (pseudocódigo no Arquivo Suplementar 1; implementação no Arquivo Suplementar 2). A arquitetura completa do BiLSTM Estendido está resumida no Algoritmo 2 (Arquivo Suplementar 1).

Fluxo de Trabalho de Reprodução End-To-End
O estudo completo pode ser reproduzido usando os passos abaixo. Software e hardware estão listados na Configuração Experimental, e o código suplementar cobre cada etapa.

Obtenha os conjuntos de dados → baixe o UNSW-NB15. Use os arquivos UNSW_NB15_training-set.csv e UNSW_NB15_testing-set.csv. Baixe CICIDS2017. Use os cinco arquivos diurnos do Machine LearningCSV (de segunda a sexta-feira). Baixe Bot-IoT. Use os arquivos de subconjunto de 5 % UNSW_2018_IoT_Botnet_Full5pc_1_to_4. Estudos anteriores de detecção de intrusão geralmente se baseavam em conjuntos de dados de referência como KDD Cup 9914; no entanto, este estudo utiliza os conjuntos de dados mais recentes UNSW-NB15, CICIDS2017 e Bot-IoT para representar melhor o tráfego de rede contemporâneo. Processe cada conjunto de dados separadamente. O conjunto de dados UNSW-NB15 está disponível na Universidade de New South Wales em https://research.unsw.edu.au/projects/unsw-nb15-dataset (última modificação: 8 de fevereiro de 2024). O conjunto de dados CICIDS2017 está disponível no Instituto Canadense de Cibersegurança em https://www.unb.ca/cic/datasets/ids-2017.html (lançado: julho de 2017). O conjunto de dados Bot-IoT está disponível na Universidade de New South Wales em https://research.unsw.edu.au/projects/bot-iot-dataset (última modificação: 5 de fevereiro de 2024). Todos os conjuntos de dados foram acessados em maio de 2025 para este estudo.

Pré-processar os dados → remover registros corrompidos. Preencha valores faltantes usando meios de conjunto de treinamento. Aplique a redução de ruído EMA (α = 0,3). Normalize as características para [0,1] usando estatísticas do conjunto de treinamento. Códigos de etiqueta e códigos categóricos. Construa janelas deslizantes (T = 20, passada = 1). Essas etapas de pré-processamento suportam uma detecção robusta de intrusões ao reduzir o ruído e melhorar a qualidade das representações do tráfego de rede para IDSs baseados em aprendizado de máquina15,16.

Selecione características (AQU-IMF-RFE) → Classifique características por informação mútua. Refinar com o Aquila Optimizer. Aplicar RFE de Floresta Aleatória com validação cruzada 10 vezes. Mantenha os recursos finais. Essa estratégia híbrida de seleção de características segue o conceito mais amplo de combinar técnicas complementares de detecção deintrusões 17 e é implementada usando a estrutura AQU-IMF-RFE desenvolvida em nosso trabalhoanterior 18.

Treine o modelo → Para cada conjunto de dados, os dados foram particionados aleatoriamente em conjuntos de treinamento (80%) e de teste (20%) usando uma semente aleatória fixa de 42. Vinte por cento da partição de treinamento foi ainda reservada como conjunto de validação. Construa o BiLSTM Estendido. Treine usando perda binária ponderada de entropia cruzada e o otimizador Adam (taxa de aprendizado = 0,001, tamanho do lote = 64, máximo de 50 épocas, com parada antecipada). Salve o modelo treinado. O uso de modelos de aprendizado profundo temporal é bem adequado para tráfego heterogêneo doIoMT 19. O fluxo completo de treinamento do modelo está resumido no Algoritmo 3 (Arquivo Suplementar 1). Os pesos finais das classes foram calculados automaticamente a partir das distribuições de classes do conjunto de treinamento de acordo com as Equações 19 e 20. Os pesos de classe resultantes foram os seguintes: UNSW-NB15: figure-protocol-2, figure-protocol-3; CICIDS2017: figure-protocol-4, figure-protocol-5; e Bot-IoT (subconjunto de 5%): figure-protocol-6, figure-protocol-7. O grande valor de wn para o conjunto de dados Bot-IoT reflete a severa sub-representação de amostras benignas na partição de treinamento do subconjunto de 5%.

Implante a blockchain → inicie a cadeia de Prova de Autoridade (PoA). Implante o contrato inteligente e anote seu endereço. Autorize as contas do gateway. Execute o cliente de modo que cada intrusão detectada seja registrada e acione isolamento e alertas. O fluxo completo de detecção, registro de blockchain e mitigação é resumido no Algoritmo 4 (Arquivo Suplementar 1). A camada blockchain foi implementada usando o cliente go-ethereum (Geth) versão 1.13.15 para operar a rede PoA com permissões, o compilador Solidity (solc) versão 0.8.19 para compilação e implantação de contratos inteligentes, e a biblioteca web3.py versão 6.15.1 para comunicação entre o IDS e a rede blockchain.

Avalie → teste o modelo no conjunto de teste estendido. Calcule precisão, precisão, recall, pontuação F1 e taxa de falsos positivos. Gravar latência e throughput. Verifique a integridade do livro-razão da blockchain. O fluxo completo de avaliação é resumido no Algoritmo 5 (Arquivo Suplementar 1). A latência de detecção (Td) foi medida imediatamente antes da chamada de inferência do modelo até o momento em que as probabilidades previstas foram retornadas. A latência de mitigação de ponta a ponta (Td +T b) foi medida do mesmo ponto de partida até a conclusão da transação correspondente de criação de blocos na blockchain. A taxa de transferência foi calculada como o número total de janelas de teste pré-processadas processadas pelo pipeline completo de detecção e registro dividido pelo tempo de relógio de parede decorrido necessário para uma única passagem completa pelo conjunto de testes de cada conjunto de dados. A carga de trabalho consistia nas partições de teste janelas, preservando a distribuição original benigna para intrusão. Janelas maliciosas também geravam a sobrecarga de registro de blockchain, enquanto janelas inofensivas assumiam apenas o custo de detecção de intrusões.

Gerar figuras e tabelas → plotar as curvas de precisão e perda, matriz de confusão e gráficos de avaliação comparativa. Construa as tabelas de comparação. O fluxo completo de geração de figuras e tabelas está resumido no Algoritmo 6 (Arquivo Suplementar 1). O código-fonte completo desenvolvido sob medida usado para gerar todas as figuras e tabelas é fornecido no Arquivo Suplementar 2. Em particular, o script figures.py reproduz as figuras do manuscrito diretamente dos resultados experimentais salvos (por exemplo, histórico de treinamento e arquivos de matriz de confusão), enquanto os scripts restantes geram os dados processados e métricas de desempenho usadas para construir as tabelas reportadas.

A Figura 2 mostra o fluxo de dados em nível de implementação entre os módulos IDS e blockchain. A BiLSTM Estendida produz uma decisão por janela (Equação 13); em uma classificação maliciosa, o cliente gateway constrói e assina uma transação e a submete via web3/JSON-RPC ao smart contract PoA, que adiciona um bloco ligado por hash (Equação 14) ao livro contámbulo imutável e emite eventos (BlockCreated, NodeIsolated e AdminAlert) que acionam o isolamento do nó e alertas de administrador.

figure-protocol-8
Figura 2. Interação em nível de implementação entre módulos de detecção de intrusão e blockchain. Diagrama de fluxo de trabalho ilustrando a comunicação entre o sistema de detecção de intrusão e os componentes da blockchain. O modelo BiLSTM Estendido classifica cada janela de entrada e aplica a regra de decisão definida na Equação 13. Quando uma intrusão é detectada, o cliente gateway gera e assina uma transação que é transmitida por Web3.py/JSON-RPC para o contrato inteligente Proof-of-Authority (PoA). O contrato adiciona um bloco ligado por hash ao livro-razão imutável de acordo com a Equação 14 e emite eventos BlockCreated, NodeIsolated e AdminAlert que acionam ações de contenção e notificação. IDS, Sistema de Detecção de Intrusões; BiLSTM, Memória Bidirecional de Curto Prazo Longo; Procuração, Prova de Autoridade; JSON-RPC, Notação de Objetos em JavaScript–Chamada de Procedimento Remoto. Por favor, clique aqui para ver uma versão ampliada desta figura.

Representação dos Dados
Vamos considerar R como o fluxo bruto de tráfego do IoMT. Após o pré-processamento, cada registro figure-protocol-9 bruto é mapeado em um vetor de características d-dimensional normalizado (Equação 1):

figure-protocol-10 (1)

Aqui, f (⋅) é a função de transformação de características que mapeia registros brutos em um vetor de características normalizado em d dimensões. Seja a rede IoMT composta por um conjunto de nós (Equação 2):

N = {n 1 , n2, ... ,n k} (2)

Cada nó n j  R produz um fluxo de dados em série temporal (Equação 3):

figure-protocol-11(3)

Aqui, xt é o vetor de características no tempo t, com d características (por exemplo, tamanho do pacote, tipo de protocolo, endereço de origem/destino) comumente observadas no tráfego de redes de saúde da Internet dasCoisas 19. O conjunto de rótulos correspondente é (Equação 4):

figure-protocol-12  (4)

Aqui, yt=0 representa o tráfego normal e yt =1 denota uma intrusão.

Pré-processamento de dados
O pipeline de pré-processamento inclui as seguintes etapas, que abordam desafios comuns de qualidade de dados e segurança associados ao tráfegoIoMT 20:

Limpeza de Dados e Tratamento de Valor Faltante:
Um registro era identificado como corrompido e removido antes da imputação se satisfesse qualquer uma das seguintes condições explícitas: (i) todos os campos de características no registro estavam faltando (ou seja, o registro inteiro era nulo), ou (ii) o registro continha um valor não finito (infinito positivo ou negativo) em qualquer campo numérico após coerção do tipo. A segunda regra remove entradas inválidas, como aquelas produzidas por divisão por zero durante o cálculo de características de fluxo (por exemplo, valores infinitos de vazão decorrentes de fluxos de duração zero). Após a remoção dos registros corrompidos, os valores restantes ausentes foram imputados por meio da substituição média calculada por característica, por conjunto de dados e apenas da partição de treinamento; Os meios resultantes foram aplicados aos conjuntos de treinamento, validação e teste para evitar vazamento de informações. A imputação não foi condicional à classe, e as médias não foram agrupadas entre conjuntos de dados.

Redução de ruído temporal:
A redução de ruído temporal foi realizada usando um filtro de média móvel exponencial por característica (EMA) aplicado ao longo do eixo temporal. A forma recursiva (causal ) yt = α·xt + (1 − α)·yt−1 foi usada, com fator de suavização α = 0,3, implementada via a função ewm do pandas com ajustar=Falso. Cada característica foi suavizada de forma independente. Como um filtro exponencial (resposta infinita ao impulso), a EMA não possui janela fixa ou tamanho de kernel; O fator de suavização α é o único parâmetro que governa o grau de suavização e a memória efetiva do filtro.

Normalização Min–Max:
A normalização min–max foi aplicada para escalar cada característica até a faixa [0,1] usando a transformação x′=(x−min)/(max−min+ε), onde ε = 1 × 10−8. As estatísticas mínima e máxima eram calculadas por característica, por conjunto de dados e apenas a partir da partição de treinamento; Essas estatísticas de treinamento armazenadas foram então aplicadas para normalizar os conjuntos de treinamento, validação e teste, prevenindo o vazamento de informações ocultas. Durante a inferência, valores de características que ficam fora do alcance de treinamento foram reduzidos ao intervalo [0,1].

Codificação de Características Categóricas:
As características categóricas eram convertidas para forma numérica usando codificação de rótulos. Isso foi aplicado a todas as variáveis categóricas: no UNSW-NB15, os campos proto, serviço e estado; no Bot-IoT, o campo proto; CICIDS2017 não contém campos categóricos entre as características selecionadas. A codificação foi implementada com o LabelEncoder ajustado por variável.

Janelas Temporais para Aprendizado Sequencial:
O fluxo de características pré-processado foi segmentado em sequências de comprimento fixo usando uma janela deslizante de comprimento T = 20 passos de tempo com um passo de s = 1. Cada janela gerada foi validada antes da inclusão. Uma janela era aceita apenas se ela contivesse exatamente T = 20 passos de tempo consecutivos e todos os valores das características fossem finitos. Fluxos menores que T = 20 registros não produziam janelas. Essa configuração (T = 20, s = 1, 95% de sobreposição) foi aplicada de forma consistente em todos os experimentos e conjuntos de dados. O fluxo completo de pré-processamento é resumido no Algoritmo 1 (Arquivo Suplementar 1).

O objetivo do pré-processamento é permitir um mapeamento preditivo das sequências de entrada para rótulos de intrusão (Equação 5).

figure-protocol-13(5)

parametrizado por θ, isso prevê se um evento é benigno ou malicioso.

Seleção de Recursos Usando AQU-IMF-RFE
A seleção de características foi realizada usando AQU-IMF-RFE, um método híbrido que integra Informação Mútua (MI), o Aquila Optimizer (AO) e a Eliminação de Características Recursivas (RFE), introduzido em nosso trabalhoanterior 18. O método opera em três etapas. Na primeira etapa, a informação mútua entre cada característica e o rótulo da classe é calculada para obter uma classificação inicial de relevância. Na segunda etapa, o Aquila Optimizer realiza uma busca global sobre subconjuntos de características candidatos usando suas quatro estratégias de otimização. No terceiro estágio, o subconjunto refinado é passado por Eliminação de Características Recursivas com validação cruzada 10 vezes usando um estimador de Floresta Aleatória (RF).

O Aquila Optimizer foi configurado com um tamanho populacional de 100, um máximo de 10 iterações, um fator de exploração de 0,1, uma taxa de aprendizado de 0,1 e um fator de atração de 0,005. Aplicado independentemente a cada conjunto de dados, AQU-IMF-RFE manteve 14 recursos para o UNSW-NB15, 24 para CICIDS2017 e 12 para Bot-IoT. O pseudocódigo completo é fornecido no Arquivo Suplementar 1, e os subconjuntos de características selecionados estão listados na Tabela 4.

Tabela 4A. Recursos Selecionados Retidos para o UNSW-NB15
S. Não.CaracterísticaTipoCategoria
1durNumérico (float)Básico
2sbytesNumérico (inteiro)Básico
3TaxaNumérico (float)Básico
4dloadNumérico (float)Básico
5sinpktNumérico (float)Tempo
6DinpktNumérico (float)Tempo
7SjitNumérico (float)Tempo
8TCPrttNumérico (float)Tempo
9SinacaNumérico (float)Tempo
10ackdatNumérico (float)Tempo
11smeanNumérico (inteiro)Conteúdo
12ct_srv_srcNumérico (inteiro)Conexão
13ct_dst_src_ltmNumérico (inteiro)Conexão
14ct_srv_dstNumérico (inteiro)Conexão
Tabela 4B. Características selecionadas mantidas para CICIDS2017
S. Não.Característica
1Porto de destino
2Duração do Fluxo
3Comprimento total dos pacotes forwarding
4Comprimento Total dos Pacotes Reversos
5Comprimento Máximo de Pacote Encaminhado
6Comprimento Máximo de Pacote Reverso
7Média do Comprimento dos Pacotes Invertido
8Pacotes de Fluxo
9Tempo Máximo de Inter-Chegada do Fluxo
10Total de Tempo Inter-Chegada Avançado
11Comprimento do cabeceio para frente
12Comprimento do cabeçalho invertido
13Pacotes Diretos por Segundo
14Comprimento Máximo do Pacote
15Média do Comprimento do Pacote
16Desvio padrão do comprimento do pacote
17Variância do comprimento do pacote
18Tamanho médio do pacote
19Tamanho médio dos segmentos para trás
20Bytes Diretos do Subfluxo
21Subfluxo de bytes retroativos
22Bytes iniciais da janela encaminhados
23Bytes iniciais da janela ao contrário
24Média do comprimento do pacote para frente
Tabela 4C. Recursos Selecionados Retidos para Bot-IoT
S. Não.CaracterísticaTipo
1seqNumeric
2MédiaNumeric
3StdDevNumeric
4minNumeric
5MaxNumeric
6srateNumérico (float)
7drateNumérico (float)
8N_IN_Conn_P_SrcIPNumérico (inteiro)
9N_IN_Conn_P_DstIPNumérico (inteiro)
10ProtoCategórico (codificado)
11state_numberNumérico (inteiro)
12TaxaNumérico (float)

Tabela 4: Recursos selecionados pelo método de seleção de características AQU-IMF-RFE. Esta tabela lista os subconjuntos finais de características selecionados pelo framework de seleção de características AQU-IMF-RFE para os conjuntos de dados UNSW-NB15, CICIDS2017 e Bot-IoT. Nomes de características, tipos de dados e categorias funcionais são fornecidos quando aplicável.

Configuração Experimental
Todos os experimentos foram realizados em um servidor Dell PowerEdge R740 equipado com um processador Intel Xeon Silver 4214 operando em uma frequência base de 2,20 GHz, com 12 núcleos físicos, 24 threads lógicas, 16,5 MB de cache e uma velocidade Intel Ultra Path Interconnect (UPI) de 9,6 GT/s. O servidor estava configurado com 128 GB de RAM, um SSD de estado sólido (SSD) de 512 GB e operava no Microsoft Windows 11. A pilha de software compreendia Python 3.12.7, TensorFlow 2.16.1, scikit-learn 1.8.0, pandas 3.0.2 e NumPy 2.4.4. A camada blockchain foi implementada na mesma estação de trabalho usando uma rede Ethereum PoA. A comunicação entre o IDS e a blockchain era realizada via JSON-RPC usando o cliente go-ethereum (Geth) versão 1.13.15, o compilador Solidity (solc) versão 0.8.19 para compilação e implantação de contratos inteligentes, e a biblioteca Web3.py versão 6.15.1. O tempo de treinamento reportado, a latência de inferência e o throughput foram medidos nessa configuração de hardware e software.

Arquitetura e Treinamento em Modelos
O modelo BiLSTM Estendido constitui o componente central de detecção do framework, baseando-se em abordagens anteriores de detecção de intrusão baseadas em aprendizado desenvolvidas para ambientesIoMT 21. Estudos anteriores de detecção de intrusão destacaram tanto a importância de equilibrar o desempenho da detecção com a redução de falsoalarme 15 quanto os desafios únicos de aplicar métodos de aprendizado de máquina ao tráfego de redeem evolução 16. Arquiteturas colaborativas de detecção de intrusão em redes neurais demonstraram ainda o valor do aprendizado profundo de características sequencialmente para tráfego complexode rede 22. Enquanto modelos BiLSTM padrão capturam dependências temporais bidirecionais, o tráfego IoMT apresenta tanto padrões de rajada de curto prazo quanto dependências de longo alcance causadas por ataques multiestágio. Para resolver isso, o modelo proposto estende o BiLSTM com extração de características temporais, aprendizado temporal bidirecional aprimorado, conexões residuais e priorização temporal baseada em atenção. LSTMs bidirecionais (BiLSTM) superam essa limitação ao combinar estados ocultos para frente e para trás, permitindo uma representação temporal mais rica dos padrões de tráfego IoMT, conforme apresentado no Algoritmo 2 (Arquivo Suplementar 1).

Seja a sequência de entrada X(nj) = {x 1 , x2 , ... , xT }, onde cada xt ∈ Rd é um vetor de características pré-processado.

Extração de Características Temporais:
Uma convolução leve unidimensional é aplicada ao longo da dimensão temporal para enfatizar anomalias temporais de curto alcance (Equação 6):

U = φ (Conv1D(X(n j)), U = {u1,u 2, ..., uT } (6)

Aqui, φ(⋅) é uma função de ativação não linear e as características convolutórias ut são alimentadas para o BiLSTM.

A camada Conv1D extrai padrões temporais de curto alcance antes da modelagem de sequência bidirecional. Parâmetros completos de implementação são fornecidos no Arquivo Suplementar 3B.

Aprendizado LSTM Bidirecional Empilhado:
Os estados ocultos para frente e para trás são calculados como (Equação 7):

figure-protocol-14(7)

A representação final da BiLSTM é a concatenação de estados ocultos passados (para frente) e futuros (para trás) (Equação 8).

figure-protocol-15(8)

Duas camadas BiLSTM empilhadas modelam dependências temporais bidirecionais. Parâmetros arquitetônicos detalhados são fornecidos no Arquivo Suplementar 3B. Os detalhes da inicialização dos pesos são fornecidos no Arquivo Suplementar 3B.

Conexão residual e normalização
Após projeção linear para dimensões correspondentes, conexões residuais e normalização de camadas são aplicadas (Equação 9):

figure-protocol-16

Projeção residual e normalização de camadas alinham as representações convolucionais e de características BiLSTM antes da atenção. Parâmetros detalhados de implementação são fornecidos no Arquivo Suplementar 3B.

Mecanismo de Atenção
Embora o BiLSTM forneça uma modelagem temporal forte, nem todos os passos de tempo contribuem igualmente para a previsão. Para enfatizar carimbos de tempo críticos (por exemplo, picos anômalos repentinos), é introduzido um mecanismo de atenção. Cada estado figure-protocol-17 oculto recebe uma pontuação de relevância αt para aumentar a precisão da detecção (Equação 10).

figure-protocol-18

Aqui, Wa é um parâmetro treinável e os pesos de atenção satisfazemfigure-protocol-19

O vetor de contexto c agrega os estados ocultos com base em sua importância aprendida (Equação 11):

figure-protocol-20

O mecanismo de atenção agrega representações temporais em um vetor de contexto. Parâmetros detalhados de implementação são fornecidos no Arquivo Suplementar 3B.

Camada de Saída e Classificação
O vetor de contexto agregado é passado por uma camada totalmente conexa, seguido por uma ativação sigmoide para obter a previsão final (Equação 12):

figure-protocol-21

Aqui, Wc e bc são parâmetros treináveis, e σ(·) é a função de ativação sigmoide que mapeia a saída para o intervalo [0,1]. Um limiar é aplicado para classificar o tráfego como benigno (figure-protocol-22) ou intrusivo (figure-protocol-23).

A regularização de abandono e o limiar fixo de classificação usado durante a inferência são descritos no Arquivo Suplementar 3B.

A arquitetura Extended BiLSTM é idêntica entre os três conjuntos de dados; apenas a dimensão da característica de entrada difere, assumindo valores de 14, 24 e 12 para UNSW-NB15, CICIDS2017 e Bot-IoT, respectivamente. Como a camada Conv1D mapeia qualquer entrada de dimensão para uma representação fixa de 64 canais, todas as camadas subsequentes são independentes do conjunto de dados, e apenas a forma de entrada e a contagem de parâmetros Conv1D variam com . A arquitetura completa camada por camada está resumida na Tabela 5, com as contagens de parâmetros expressas em termos de d; Os totais resultantes são 184.641, 186.561 e 184.257 parâmetros treináveis para D = 14, D = 24 e D = 12, respectivamente.

S. Não.Camada (Tipo)Forma de SaídaParâmetros TreináveisFunção de Ativação
1Entrada(20, d)0
2Conv1D (64 filtros, tamanho do núcleo = 3, mesmo preenchimento de volume)(20, 64)192d + 64ReLU
3Camada 1 de LSTM bidirecional (64 unidades por direção)(20, 128)66,048tanh / sigmoid
4Camada 2 de LSTM bidirecional (64 unidades por direção)(20, 128)98,816tanh / sigmoid
5Projeção Residual Densa(20, 128)8,320Linear
6Adição Residual(20, 128)0
7Normalização de Camada (eixo = −1, ε = 1 × 10⁻³)(20, 128)256
8Atenção Temporal (Wa ∈ R¹²⁸×¹)128128Softmax
9Camada Densa Oculta648,256ReLU
10Desistência (p = 0,3)640
11Camada de Saída Densa165Sigmoide

Tabela 5: Arquitetura camada por camada do modelo de Memória Bidirecional Estendida de Curto Prazo Longo. Esta tabela resume a arquitetura do modelo proposto de Memória Bidirecional Estendida de Curto Prazo (BiLSTM), incluindo tipos de camadas, dimensões de saída, contagens de parâmetros treináveis e funções de ativação.

O software e o ambiente computacional usados para todos os experimentos são resumidos na Tabela 6.

ComponenteVersão / Especificação
Sistema OperacionalJanelas
Plataforma de ServidorDell PowerEdge
CPUProcessador de 64 núcleos
RAM128 GB
ArmazenamentoSSD de 512 GB
Python3.12.7
NumPy2.4.4
Pandas3.0.2
scikit-learn1.8.0
TensorFlow / Keras2.16.1
Web3 (cliente blockchain)6.15.1
conta eth-0.1
Compilador de Solidity (solc)0.8.19
go-ethereum (Geth)1.13.15

Tabela 6: Software e ambiente computacional usados para implementação e avaliação do framework proposto. Esta tabela resume as especificações de hardware, componentes de software, ferramentas de blockchain e números de versão usados para pré-processamento de dados, seleção de recursos, treinamento de modelos, implantação de blockchain e avaliação de desempenho.

Decisão de Intrusão e Resposta Automatizada
A detecção de intrusão em ambientes de saúde só é eficaz se seguida de resposta rápida e mitigação. A Camada de Detecção de Intrusão converte a probabilidade prevista em uma decisão. Formalmente, a decisão de intrusão no passo temporal t é representada da seguinte forma (Equação 13):

figure-protocol-24

Aqui, figure-protocol-25 é a probabilidade prevista de intrusão no tempo t e figure-protocol-26 é o limiar de classificação.

Uma vez detectada uma intrusão, a Camada de Detecção de Intrusão se conecta diretamente com o módulo blockchain, que realiza registro imutável, mitigação automatizada e aplicação de segurança em circuito fechado. Detalhes do evento, incluindo informações de origem, informações de destino e recursos de tráfego selecionados, são registrados em um novo bloco blockchain. Contratos inteligentes executam ações de mitigação em tempo real, como isolamento de nós e alertas de administradores. Essa arquitetura em malha fechada permite que os resultados da detecção de intrusão sejam direcionados diretamente para os mecanismos de prevenção, minimizando assim a latência de mitigação. Assim, a Camada de Detecção de Intrusão serve como a ponte entre a detecção temporal usando o modelo BiLSTM Estendido e a resposta segura usando tecnologia blockchain, completando a funcionalidade de ponta a ponta do framework proposto.

Registro Forense Baseado em Blockchain
Embora o modelo BiLSTM Estendido permita a detecção de intrusões em tempo real, armazenamento seguro e auditoria verificável de eventos de intrusão são igualmente críticos em ambientes de saúde IoMT. Mecanismos tradicionais de registro centralizado são vulneráveis a manipulações e comprometem a rastreabilidade forense. Para enfrentar essa limitação, o framework proposto incorpora um módulo blockchain leve que garante imutabilidade, descentralização e resposta automatizada baseada em contratos inteligentes.

Cada evento de intrusão detectado gera um bloco que é adicionado à blockchain. Um bloco Bi é definido da seguinte forma (Equação 14):

figure-protocol-27

Aqui, Hi é o hash criptográfico dos dados do evento, carimbo de tempo e resultado da previsão, Ti é o carimbo de tempo, Di contém características selecionadas do evento de intrusão, Sigi é a assinatura digital, e PrevHash vincula o bloco ao bloco anterior, garantindo imutabilidade.

Esse design garante resistência a adulteração porque qualquer modificação de Di ou Ti altera o hash do bloco e quebra a integridade da cadeia. Também oferece auditoria porque todas as anomalias detectadas são armazenadas permanentemente e verificáveis. A mitigação automatizada é suportada por meio de contratos inteligentes que executam ações pré-definidas, como isolamento de nós e alertas de administrador. A descentralização é alcançada por meio de múltiplos gateways IoMT mantendo o livro-razão distribuído, eliminando assim um único ponto de falha.

A geração de blocos utiliza a função de hash criptográfico Keccak-256, a primitiva nativa de hash do ambiente Ethereum/Solidity (invocada através do keccak256 do Solidity). Para cada bloco de intrusão, o hash do bloco é calculado da seguinte forma:

figure-protocol-28

Aqui, Di é o resumo da característica do evento, Ti é o carimbo de tempo, e PrevHash é o hash do bloco anterior. Os campos são concatenados usando a codificação compactamente compacta do Solidity (abi.encodePacked) antes do hash, produzindo um digest de 256 bits.

O mesmo cálculo do Keccak-256 é usado pela rotina de verificação em cadeia, que recalcula cada hash de bloco a partir de seus campos armazenados e confirma que ele corresponde ao valor registrado, validando assim a integridade da cadeia. O Keccak-256 foi selecionado porque é o algoritmo padrão de hashing resistente a colisões usado nativamente dentro dos contratos inteligentes Ethereum. O contrato inteligente foi desenvolvido em Solidity e compilado usando o compilador Solidity (solc) versão 0.8.19. Foi implantado em uma rede privada Ethereum Proof-of-Authority (PoA) operada usando a versão 1.13.15 do Geth. A rede blockchain foi configurada com quatro nós validadores usando o protocolo de consenso Clique Proof-of-Authority, um ID de cadeia de 9848, um período de bloco de 5 s e um limite de gás de bloco de 30.000.000. A comunicação entre o motor de detecção de intrusões BiLSTM Estendido e a camada blockchain foi implementada usando a biblioteca Web3.py versão 6.15.1 através da interface HTTP JSON-RPC.

Mecanismo de Consenso do Ponto de Interesse
Como os sistemas IoMT em saúde são altamente sensíveis à latência, o framework proposto emprega um mecanismo de consenso PoA em vez do caro Proof-of-Work (PoW)23, que é computacionalmente caro. No PoA, um conjunto fixo de nós validadores confiáveis, como gateways hospitalares, autoriza transações, proporcionando tanto eficiência quanto resiliência.

A complexidade temporal da validação de blocos sob PoW pode ser expressa da seguinte forma (Equação 15):

figure-protocol-29

Aqui, d representa a dificuldade de mineração.

Em contraste, a complexidade temporal do consenso PoA é dada da seguinte forma (Equação 16):

figure-protocol-30

porque a validação requer apenas verificação por assinatura digital por nós validadores autorizados.

Como resultado, o PoA oferece operação de baixa latência adequada para alertas médicos em tempo real, eficiência energética ao evitar mineração computacionalmente intensiva e resiliência contra um número limitado de validadores maliciosos. A rede PoA foi configurada com quatro nós validadores, e essa configuração foi mantida fixa durante todos os experimentos para garantir medições consistentes de latência, avaliação de desempenho reproduzível e comparação justa entre todos os conjuntos de dados de benchmark.

Implementação de Blockchain e Operação de Contratos Inteligentes
O componente blockchain foi implementado em uma rede Ethereum autorizada operando sob o modelo de consensoPoA 24. A rede era executada usando o cliente go-ethereum (Geth) com o protocolo de consenso CliquePoA 25, no qual um conjunto de nós validadores autorizados (sealer) é responsável por produzir e validar blocos. O contrato inteligente de logging de intrusões (IoMTIntrusionLedger) foi escrito em Solidity e implantado nessa rede, seguindo arquiteturas de segurança IoT baseadas em blockchain para gerenciamento de eventos descentralizadoe seguro 26. Apenas contas de gateway autorizadas on-chain (via a função de controle de acesso do contrato) podiam enviar registros de invasão, consistentes com arquiteturas de contratos inteligentes de blockchain autorizadas para aplicações daInternet das Coisas 27. A camada blockchain foi implementada usando o cliente go-ethereum (Geth) versão 1.13.15 para operar a rede PoA com permissões, o compilador Solidity (solc) versão 0.8.19 para compilação e implantação de contratos inteligentes, e a biblioteca Web3.py versão 6.15.1 para comunicação entre o IDS e a rede blockchain.

Parâmetros detalhados de implantação e configuração da blockchain são fornecidos no Arquivo Suplementar 3C.

Cada registro de intrusão é assinado digitalmente antes de ser registrado no livro-caixa, apoiando a auditabilidade em saúde baseada em blockchain e a manutenção segura de registrosforenses 28. Procedimentos de geração e verificação de assinatura digital, incluindo ECDSA sobre a curva secp256k129,30, são descritos no Arquivo Suplementar 3D. Cada gateway possui um par de chaves Ethereum consistindo em uma chave privada de 256 bits (32 bytes) e a chave pública correspondente, da qual seu endereço de conta é derivado; a geração de chaves segue o procedimento padrão do Ethereum, usando uma chave privada aleatória de 256 bits criptograficamente segura, com a chave pública obtida pela multiplicação escalar secp256k1. Para criar uma assinatura, o cliente gateway calcula o digest de recurso de evento Di e o assina com sua chave privada usando o formato de assinatura de mensagens EIP-191, produzindo uma assinatura de 65 bytes composta pelos componentes r, s e v. A assinatura é enviada junto com o registro de intrusão. A verificação é realizada on-chain pelo contrato inteligente: usando a pré-compilação EVM ecreach, o contrato recupera o endereço do signatário a partir do digest e da assinatura assinados e exige que ele seja igual ao endereço do gateway autorizado que enviou a transação. Se o endereço recuperado não corresponder a um gateway autorizado, a transação é rejeitada. Isso vincula cada entrada do livro maior a um gateway autorizado específico e impede registros de intrusões não autorizadas ou falsificadas.

Contratos inteligentes são acionados automaticamente após a detecção figure-protocol-31de intrusão, garantindo resposta em tempo real sem necessidade de intervenção manual (Equação 17):

figure-protocol-32(17)

O módulo blockchain opera em paralelo com o classificador BiLSTM Estendido. Uma vez detectada uma anomalia: (i) o evento é rotulado e classificado pelo BiLSTM, (ii) um bloco é gerado, assinado e anexado ao livro-razão da blockchain, e (iii) contratos inteligentes aplicam políticas de resposta automática.

O contrato inteligente de registro de intrusões (IoMTIntrusionLedger) mantém um livro-razão apenas anexo dos blocos de intrusão e um registro de contas de gateway autorizadas, além de expor as funções resumidas na Tabela 7. O contrato impõe dois papéis de acesso por meio de modificadores: onlyAdmin (o administrador que faz a implantação) e onlyGateway (contas autorizadas a enviar registros de intrusão). O estado consiste no mapeamento de autorização do gateway, no array do bloco-razão e na cabeça atual da cadeia (o hash do bloco mais recente).

S. Não.Função / ComponenteTipoAcessoLógica
1construtorConstrutorDefine o deployer como administrador e o autoriza como gateway inicial.
2setGateway (endereço, bool)FunçãoonlyAdminAdiciona ou remove uma conta de gateway autorizada; emite GatewayUpdated.
3recordIntrusion(nodeId, patientId, attackClass, probabilityBp, dataDigest, signature, isolate)FunçãoonlyGatewayCalcula Hi = Keccak-256(Di ∥ Ti ∥ probabilidade ∥ PrevHash); verifica a assinatura ECDSA do gateway em Di via ecrecover; anexa o bloco ao livro-caixa; avança a cabeça da corrente; emite BlockCreated, opcionalmente NodeIsolated e AdminAlert. Retorna Hi.
4verifyChain()Função de visualizaçãoPúblicoRecalcula o hash de cada bloco a partir de seus campos armazenados e verifica a ligação PrevHash; retorna verdadeiro apenas se toda a cadeia for consistente (detecção de adulteração).
5ledgerLength()Função de visualizaçãoPúblicoRetorna o número de blocos no livro-razão (ledger).
6_recoverSigner(hash, sig)Função InternaDivide a assinatura de 65 bytes em (r, s, v) e recupera o endereço de assinatura via pré-compilação ecreole.
7BlockCreated / NodeIsolated / AdminAlert / GatewayAtualizadoEventosEmitido para ouvintes off-chain para registrar drives, isolamento de nós, alertas de administrador e atualizações do registro do gateway.
8onlyAdmin / onlyGatewayModificadoresRestringa funções ao administrador e aos gateways autorizados, respectivamente.

Tabela 7: Funções, eventos e componentes de controle de acesso do contrato inteligente IoMTIntrusionLedger. Esta tabela resume as principais funções, eventos e modificadores de controle de acesso implementados dentro do contrato inteligente da blockchain com permissão. Esses componentes suportam autorização de gateways, registro de intrusões, verificação de blockchain, geração de eventos e mitigação automatizada.

A propriedade de imutabilidade da blockchain decorre diretamente da Equação 14, onde qualquer modificação em dados de eventos ou carimbos de data invalida a cadeia de hash. Assim, o blockchain oferece integridade dos dados, rastreabilidade e auditabilidade para sistemas de saúde por meio de registros forenses imutáveis. Os registros de intrusão de pacientes e dispositivos permanecem inalterados após armazenados, cada bloco se conecta de forma segura ao bloco anterior, permitindo a reconstrução cronológica de eventos, e administradores ou reguladores de saúde podem verificar incidentes de intrusão sem risco de falsificação.

Função de Perda e Otimização de Modelos
O modelo BiLSTM Estendido proposto aborda o problema de classificação binária de distinguir entre eventos normais de tráfego e intrusão em redes IoMT. Para orientar o processo de treinamento, é adotada uma perda binária de entropia cruzada (BCE), que é bem adequada para saídas probabilísticas da camada de ativação sigmoide. Para um conjunto de dados com N amostras, a perda é definida da seguinte forma (Equação 18):

figure-protocol-33(18)

Aqui, figure-protocol-34 é o rótulo de verdade fundamental da i-ésima sequência de entrada (0 = benigno, 1 = intrusão), e figure-protocol-35 é a probabilidade prevista de intrusão.

A estrutura opera como uma linha de classificação em duas etapas. O primeiro estágio realiza a detecção de intrusão binária: o BiLSTM Estendido produz uma saída figure-protocol-36 sigmoide e aplica o limiar τ = 0,5 para classificar cada janela como benigna ou intrusiva (Equações 12,13), treinada com perda binária ponderada de entropia cruzada. Um segundo estágio pode realizar categorização de ataques, na qual janelas identificadas como intrusões são passadas para um classificador multiclasse que atribui a categoria específica de ataque usando uma camada softmax de saída treinada com entropia cruzada categórica. O presente estudo foca e avalia a etapa de detecção binária. Os dois estágios compartilham a mesma espinha dorsal de extração de características do BiLSTM Estendido (Conv1D, BiLSTM, camadas residuais, de normalização e de atenção); Eles diferem apenas em sua camada de saída (sigmoid para detecção e softmax para categorização) e na função de perda correspondente. A fase de detecção binária e a etapa de categorização multiclasse foram treinadas e avaliadas sob as mesmas partições de dados, sementes aleatórias e condições de treinamento descritas acima.

Embora o tráfego IoMT seja frequentemente desequilibrado, uma perda binária ponderada de entropia cruzada é usada para penalizar a classificação incorreta da classe minoritária. Os pesos de classe são calculados usando o número de amostras de intrusão Np, o número de amostras benignas Nn e o número total de amostras N (Equações 19,20):

figure-protocol-37

figure-protocol-38

A ponderação garante que o modelo não seja tendencioso para a classe dominante de tráfego benigno e permaneça sensível a eventos raros, porém críticos, de intrusão.

A perda binária ponderada de entropia cruzada é dada da seguinte forma (Equação 21):

figure-protocol-39(21)

O treinamento foi realizado usando mini-lotes do tamanho 64. No início de cada época, as amostras de treinamento eram embaralhadas aleatoriamente antes de serem particionadas em lotes, de modo que a composição em lotes variava entre épocas e o modelo não via exemplos em ordem fixa. Os lotes não eram explicitamente balanceados ou estratificados por classe; em vez disso, cada lote refletia a distribuição natural de classes do conjunto de treinamento, e o desequilíbrio de classes era tratado por meio da perda binária de entropia cruzada ponderada por classe (Equações 19–21). O subconjunto de validação reservado da partição de treinamento permaneceu fixo entre épocas e não foi embaralhado nos lotes de treinamento.

Os pesos das classes na perda binária ponderada de entropia cruzada não foram definidos manualmente, mas foram calculados automaticamente para cada conjunto de dados a partir das contagens de classes do conjunto de treinamento, de acordo com as Equações 19 e 20. Para o conjunto de dados UNSW-NB15, os pesos de classe resultantes foram figure-protocol-40 para a classe normal e figure-protocol-41 para a classe de intrusão. Para o conjunto de dados CICIDS2017, os pesos resultantes da classe normal figure-protocol-42 e figure-protocol-43 da classe de intrusão. Para o conjunto de dados Bot-IoT (subconjunto de 5%), os pesos resultantes da classe normal figure-protocol-44 e figure-protocol-45 da classe de intrusão.

Estratégia de Treinamento e Otimização
O modelo BiLSTM Estendido foi treinado usando mini-lotes de tamanho B = 64 com perda binária ponderada de entropia cruzada, o otimizador Adam e parada precoce baseada na perda de validação. O treinamento foi limitado a 50 épocas, e a parada precoce foi aplicada com paciência K = 5. Se a perda de validação não melhorasse por cinco épocas consecutivas, o treinamento era interrompido e os pesos do modelo eram restaurados para aqueles da época com menor perda de validação. Assim, 50 épocas representavam o orçamento máximo de treinamento em vez de uma duração fixa de treinamento. Uma probabilidade de abandono de 0,3 foi aplicada para regularização. Os ajustes arquitetônicos incluíam 64 filtros Conv1D, 64 unidades LSTM por direção, um comprimento de janela de T = 20 e uma passada de s = 1. A estratégia de treinamento adotada é resumida no Algoritmo 3 (Arquivo Suplementar 1). As equações de atualização Adam usadas para otimização são fornecidas no Arquivo Suplementar 3A.

O otimizador Adam foi configurado com uma taxa de aprendizado de figure-protocol-46, uma taxa de decaimento no primeiro momento (β1) de 0,9, uma taxa de decaimento no segundo momento (β2) de 0,999 e uma constante de estabilidade numérica (figure-protocol-47) de 1 × 10-7. Nenhuma opção adicional de otimizador foi utilizada, e nenhum decaimento de peso ou clipping de gradiente foi aplicado.

Geração de Alertas e Mitigação Automatizada
A detecção sozinha é insuficiente em redes IoMT sensíveis à latência, onde a resposta rápida é crítica para garantir a segurança do paciente. A Camada de Geração e Mitigação de Alertas operacionaliza a decisão de intrusão tomada pelo modelo BiLSTM Estendido e pelo mecanismo de registro da blockchain. Se δt = 1, o módulo blockchain adiciona um novo bloco contendo os detalhes figure-protocol-48da intrusão . Simultaneamente, um contrato inteligente é executado para acionar ações de mitigação (Equação 22):

figure-protocol-49(12)

Aqui, o BlockCreation garante um registro forense imutável do evento, o NodeIsolation (nj) coloca o nó IoMT comprometido para evitar danos adicionais, e o AdminAlert entrega notificações em tempo real aos administradores do sistema. Para operar esse pipeline de resposta de camadas duplas, o pseudocódigo é apresentado no Algoritmo 4 (Arquivo Suplementar 1).

Processamento de eventos por smart contract e mecanismos de resposta off-chain são descritos no Arquivo Suplementar 3E.

Cada entrada comprometida no livro-razão da blockchain é armazenada como um registro IntrusionBlock, cujos campos e formatos de dados estão listados na Tabela 8. O livro razão é um array apenas anexo desses registros, e a cabeça atual da cadeia armazena o hash do bloco adicionado mais recentemente.

S. Não.CampoTipo de DadoTamanhoDescrição
1hashIdbytes3232 bytesHash do bloco Hi = Keccak-256(Di ∥ Ti ∥ probabilidade ∥ PrevHash)
2Carimbo de tempouint25632 bytesTempo de criação de bloco Ti (segundos de época Unix, a partir do carimbo de tempo do bloco)
3nodeIdbytes3232 bytesIdentificador do nó IoMT nj
4pacienteIdbytes3232 bytesIdentificador de paciente/dispositivo (metadados forenses)
5Classe de ataqueuint162 bytesCódigo da categoria de ataque (0 = Normal, 1 = DDoS, 2 = Falsificação, ...)
6probabilidadeBpuint162 bytesProbabilidade de intrusão prevista ŷ em pontos base (0–10000, ou seja, 0,00–100,00%)
7dataDigestbytes3232 bytesResumo Di dos eventos selecionados se destaca
8assinaturaBytesVariável (65 bytes)Assinatura ECDSA Sigi do digest de eventos pelo gateway (r, s, v)
9prevHashbytes3232 bytesHash do bloco anterior (PrevHash), ligando a cadeia
10isoladobool1 byteSe o isolamento de nó foi acionado para esse registro

Tabela 8: Estrutura do registro IntrusionBlock armazenado no livro-razão da blockchain. Esta tabela descreve os campos, tipos de dados, tamanhos de armazenamento e propósitos dos registros do livro razão da blockchain usados para armazenar eventos de intrusão. A estrutura suporta verificação de integridade criptográfica, rastreabilidade forense e mecanismos automáticos de resposta.

A latência total de mitigação pode ser expressa como a soma do atraso de detecção (Td) do modelo BiLSTM Estendido e do atraso de execução da blockchain (Tb) (Equação 23):

figure-protocol-50(23)

Análise de Complexidade Computacional
A eficiência do framework BiLSTM–Blockchain Estendido proposto é determinada tanto pelo custo computacional do modelo BiLSTM quanto pelo overhead introduzido pelo módulo blockchain. A estrutura proposta integra a detecção Estendida de BiLSTM com registro em blockchain para satisfazer os requisitos centrais de segurança da tríade de Confidencialidade, Integridade e Disponibilidade (CIA).

Seja o comprimento da sequência de entrada pré-processada T, a dimensão de característica d, e a dimensão oculta do BiLSTM h.

Para cada passo de tempo, um BiLSTM processa entrada de dimensão d com tamanho oculto h. Como é bidirecional (para frente + para trás) (Equação 24):

figure-protocol-51) (24)

Aqui, T é o comprimento da sequência (passos de tempo), d é a dimensão de característica de entrada, h é a dimensão de estado oculto

A camada de atenção calcula pesos de importância e agrega estados ocultos com complexidade (Equação 25).

figure-protocol-52(25)

que é linear tanto na sequência de comprimento T quanto na dimensão oculta h.

A complexidade total de detecção por sequência é, portanto, dada da seguinte forma (Equação 26):

figure-protocol-53(26)

demonstrando que a modelagem temporal domina o custo computacional, enquanto o mecanismo de atenção introduz apenas um overhead leve.

Para cada evento de intrusão detectado, o registro da blockchain realiza operações de hash, assinatura e anexação de blocos (Equação 27):

figure-protocol-54(27)

Para N eventos de detecção de intrusão, a complexidade combinada torna-se a seguinte (Equação 28):

figure-protocol-55(28)

que pode ser simplificado da seguinte forma (Equação 29):

figure-protocol-56(29)

porque o overhead da blockchain cresce linearmente com o número de eventos e permanece negligenciável em comparação com os cálculos de processamento de sequências.

A complexidade computacional é resumida nas Equações 24–29. A interpretação detalhada é fornecida no Arquivo Suplementar 3F.

Results

Loading...
$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Os resultados são organizados para espelhar as etapas metodológicas do Protocolo, com cada subseção relatando as observações produzidas pelo passo correspondente.

Manuseio de conjuntos de dados e configuração experimental
Os três conjuntos de dados de referência foram analisados de forma independente, e não fundidos. Como UNSW-NB15, CICIDS2017 e Bot-IoT usam esquemas de características e convenções de rotulagem diferentes, cada conjunto de dados foi pré-processado, janelado e avaliado separadamente usando sua própria divisão 80:20 de treino/teste. O modelo BiLSTM Estendido foi treinado e testado em cada conjunto de dados de forma independente, e as métricas de desempenho (precisão, precisão, recordação e pontuação F1) são reportadas separadamente para cada conjunto de dados. Esse protocolo de avaliação independente evita inconsistências no espaço de características que surgiriam da combinação de conjuntos de dados heterogêneos e permite que a robustez do framework proposto seja avaliada em três ambientes de rede distintos.

O modelo BiLSTM-BC Estendido proposto foi treinado e avaliado usando tráfego normal e malicioso pré-processado extraído dos conjuntos de dados CICIDS2017, UNSW-NB15 e Bot-IoT. Os dados foram particionados usando uma única divisão estratificada de retenção. O conjunto de dados UNSW-NB15 fornece partições pré-definidas de treinamento e testes, que foram usadas diretamente neste estudo. Para os dois conjuntos de dados restantes (CICIDS2017 e Bot-IoT), as amostras janelas pré-processadas foram divididas em conjuntos de treinamento e teste usando uma divisão 80:20 com amostragem aleatória estratificada (scikit-learn train_test_split, estratificada por rótulo de classe), preservando assim a proporção benigna para intrusão entre as partições. Dentro do conjunto de treinamento, 20% adicionais foram reservados para validação (Keras validation_split), resultando em uma partição efetiva de 64% de treinamento, 16% de validação e 20% de testes. O conjunto de validação era usado para paradas precoces. Uma semente aleatória fixa de 42 foi aplicada ao scikit-learn, NumPy e TensorFlow para suportar a reprodutibilidade. A rede BiLSTM Estendida foi otimizada usando o otimizador Adam, com taxa de aprendizado de 0,001, tamanho de lote de 64 e máximo de 50 épocas de treinamento.

Resultados da seleção de características
Antes do treinamento do modelo, a seleção de características era realizada independentemente para cada conjunto de dados usando AQU-IMF-RFE, um procedimento de Eliminação de Características Recursiva guiado pelo Aquila Optimizer (AO), no qual as características candidatas eram classificadas de acordo com sua informação mútua (MI) com o rótulo da classe e eliminadas iterativamente enquanto o Aquila Optimizer buscava o subconjunto ótimo de características. Campos de identificador (por exemplo, IDs de fluxo, endereços IP e números de porta) e campos textuais de categoria de ataque foram excluídos antes da seleção de recursos para evitar vazamento de informações. Esse procedimento manteve 14 recursos para UNSW-NB15, 24 recursos para CICIDS2017 e 12 recursos para Bot-IoT. A lista completa de variáveis de entrada selecionadas, seus tipos de dados e seus conjuntos de dados de origem é fornecida na Tabela 4, e uma descrição ampliada de cada recurso está incluída no Arquivo Suplementar 2.

Treinamento e convergência
Durante o treinamento, o modelo demonstrou convergência estável, com desempenho tanto no treinamento quanto na validação melhorando à medida que os parâmetros da rede se aproximavam de seus valores ótimos. A arquitetura camada a camada do modelo BiLSTM Estendido proposto é resumida na Tabela 5, enquanto o software e o ambiente computacional usados para implementação e avaliação são apresentados na Tabela 6. As funções de smart contract blockchain que suportam registro de intrusões e mitigação automatizada são resumidas na Tabela 7, e a estrutura do registro de intrusão blockchain é apresentada na Tabela 8. O conjunto completo de hiperparâmetros de treinamento usados neste estudo é resumido na Tabela 9, apoiando a reprodutibilidade do arcabouço proposto.

Hiperparâmetro de TreinamentoValor
Taxa de Aprendizado0.001
OtimizadorAdam
Tamanho do lote64
Épocas Máximas50
Função de Ativação de SaídaSigmoide
Divisão entre testes de trem80:20, estratificado
Divisão de validação20% da partição de treinamento
Semente aleatória42
Comprimento da janela de entrada20 passos de tempo
Passada com janela deslizante1
Filtros Conv1D64
Tamanho do kernel Conv1D3
Enchimento Conv1DMesma coisa
Ativação Conv1DReLU
Camadas BiLSTM2
Unidades BiLSTM64 unidades por direção
Dimensão de saída do BiLSTM128
Ativação do LSTMTanh
Dimensão de projeção residual128
Paciência para parar cedo5 épocas
Unidades densas de camada oculta64
Ativação densa em camada ocultaReLU
Taxa de evasão escolar0.3
Unidades de saída1
Limiar de classificação0.5
Função de PerdaEntropia Cruzada Binária Ponderada (WBCE)

Tabela 9: Configuração de hiperparâmetros usada para treinar o modelo de Memória Bidirecional Estendida de Curto Prazo Longo. Esta tabela lista os principais hiperparâmetros de treinamento usados durante o desenvolvimento do modelo de detecção de intrusões Bidirecional Bidirecional de Curto Prazo (BiLSTM), incluindo configurações de otimização, função de ativação, tamanho do lote, duração do treinamento e função de perda.

A Tabela 10 apresenta as precisões de treinamento e validação do modelo proposto ao longo de 50 épocas, registradas em intervalos de 5 épocas. O modelo mostrou melhora rápida durante as primeiras 10 épocas, alcançando precisões de treinamento e validação de 96,0% e 95,5%, respectivamente. Após a época 20, os ganhos de precisão tornaram-se incrementais, e ambas as curvas convergiram de perto. Na época 50, o modelo estabilizou com 99,1% de precisão no treinamento e 98,5% de validação, indicando sobreajuste mínimo e forte desempenho de generalização. A curva de aprendizado correspondente é mostrada na Figura 3, ilustrando a progressão da precisão do treinamento e validação ao longo do processo de otimização.

ÉpocaPrecisão do Treinamento (%)Precisão de Validação (%)
172.170
59089
109695.5
1597.196.5
2097.897.2
2598.297.5
3098.597.8
3598.798
4098.998.2
459998.4
5099.198.5

Tabela 10: Treinamento e validação da precisão durante o treinamento do modelo de Memória Bidirecional Estendida de Curto Prazo Longo. Esta tabela relata a precisão do treinamento e validação medida em épocas selecionadas durante a otimização do modelo Bidirecional Estendido de Memória de Curto Prazo (BiLSTM). Esses valores foram usados para gerar a curva de convergência de precisão mostrada na Figura 3.

figure-results-1
Figura 3. Precisão de treinamento e validação do modelo BiLSTM Estendido. Gráfico de linhas mostrando a precisão da classificação durante o treinamento do modelo. O eixo x representa épocas de treinamento (1–50), e o eixo y representa a precisão da classificação (%). Círculos azuis indicam precisão no treinamento, e quadrados laranja indicam precisão de validação. Por favor, clique aqui para ver uma versão ampliada desta figura.

A Tabela 11 apresenta os valores de perda de treinamento e validação registrados nos mesmos intervalos de 5 épocas. Durante a fase inicial de treinamento, a perda de treinamento diminuiu de 0,64 para 0,28, enquanto a perda de validação diminuiu de 0,67 para 0,31 na época 5. Após a época 20, a taxa de redução de perdas tornou-se mais gradual, e ambas as curvas convergiram de forma constante. Na época 50, a perda de treinamento estabilizou em 0,08, enquanto a perda de validação permaneceu próxima em 0,12, indicando apenas uma pequena diferença entre as duas curvas. Essa convergência reflete otimização eficaz, sobreajuste limitado e boa generalização para dados antes inéditos. As curvas correspondentes de perda de treinamento e validação são apresentadas na Figura 4. A eficiência computacional dos modelos avaliados, incluindo latência de inferência e throughput, está resumida na Tabela 12. A análise detalhada dessas medições é apresentada posteriormente na subseção Eficiência computacional.

ÉpocaPerda de TreinamentoPerda de validação
10.640.67
50.280.31
100.130.17
150.110.15
200.10.14
250.0950.13
300.090.125
350.0850.122
400.0830.12
450.0820.118
500.080.12

Tabela 11: Perda de treinamento e validação durante o treinamento do modelo de Memória Bidirecional Estendida de Curto Prazo Longo. Esta tabela relata valores de perda binária ponderada por entropia cruzada ponderados em treinamento e validação em épocas selecionadas durante a otimização do modelo Bidirecional Estendido de Memória de Curto Prazo (BiLSTM) Proposto. Esses valores foram usados para gerar a curva de convergência de perdas mostrada na Figura 4.

figure-results-2
Figura 4. Perda de treinamento e validação do modelo BiLSTM Estendido. Gráfico linear mostrando perda binária ponderada de entropia cruzada durante o treinamento do modelo. O eixo x representa épocas de treinamento (1–50), e o eixo y representa valores de perda. Círculos azuis indicam perda de treinamento, e quadrados laranja indicam perda de validação. Por favor, clique aqui para ver uma versão ampliada desta figura.

ModeloLatência (Média de ms/evento)Taxa de Transferência (Eventos/s Média)
Árvore de Decisão40845
Máquina de Vetores de Suporte75670
LSTM110559
Proposta de Estrutura BiLSTM–Blockchain Estendida135320

Tabela 12: Comparação de latência e taxa de transferência de modelos de detecção de intrusão. Esta tabela compara a latência de inferência e o throughput de processamento entre modelos representativos de detecção de intrusão de aprendizado de máquina e deep learning. A latência é reportada como milissegundos por evento e a taxa de transferência é reportada como eventos processados por segundo.

Desempenho de detecção
A Tabela 13 apresenta a avaliação comparativa do framework proposto em relação aos modelos convencionais de ML e DL de linha de base entre os três conjuntos de dados de referência. O modelo proposto alcançou precisões de 98,9% no CICIDS2017, 95,9% no UNSW-NB15 e 98,8% no Bot-IoT, juntamente com altas sensibilidades de 96,9%, 97,6% e 98,8%, respectivamente. No CICIDS2017 e no UNSW-NB15, o modelo proposto alcançou a maior precisão entre todos os modelos avaliados, enquanto no Bot-IoT alcançou a maior precisão (98,8%), acompanhada pela linha de base da Árvore de Decisão (DT). No Bot-IoT, o modelo proposto superou levemente a linha de base do LSTM (98,3%) e teve desempenho comparável à linha de base da Support Vector Machine (SVM) (98,7%); As margens de desempenho menores neste conjunto de dados refletem seu extremo desequilíbrio de classes, no qual o tráfego benigno constitui apenas uma fração muito pequena do conjunto de testes. No geral, o modelo proposto manteve um forte equilíbrio entre sensibilidade e precisão, demonstrando desempenho robusto em detecção de intrusão em todos os conjuntos de dados, ao mesmo tempo em que forneceu a avaliação mais confiável nos conjuntos de dados de referência mais equilibrados (CICIDS2017 e UNSW-NB15). As comparações correspondentes de precisão, exatidão e recordação entre conjuntos de dados e modelos de referência são apresentadas nas Figuras 5–7.

Conjunto de dadosModeloSensibilidade (%)Especificidade (%)Precisão (%)Precisão (%)Recall
(%)
CICIDS2017BiLSTM–Blockchain Estendido Proposto96.999.498.997.596.9
LSTM93.398.597.593.993.3
SVM94.898.898.195.194.8
DT93.198.797.594.693.1
UNSW-NB15BiLSTM–Blockchain Estendido Proposto97.693.995.995.197.6
LSTM95.288.592.291.195.2
SVM96.591.194.193.196.5
DT96.992.294.893.896.9
Bot-IoTBiLSTM–Blockchain Estendido Proposto98.890.598.899.398.8
LSTM98.389.498.399.298.3
SVM98.788.498.799.398.7
DT98.893.698.899.398.8

Tabela 13: Comparação de desempenho de modelos de detecção de intrusão entre conjuntos de dados de referência. Esta tabela compara a estrutura proposta e os modelos de detecção de intrusão de linha de base nos conjuntos de dados CICIDS2017, UNSW-NB15 e Bot-IoT, utilizando métricas de desempenho de sensibilidade, especificidade, precisão, precisão e recall.

figure-results-3
Figura 5. Comparação de precisão entre conjuntos de dados e modelos de aprendizado de máquina/deep learning. Gráfico de barras agrupado comparando a precisão da classificação (%) obtida por diferentes modelos nos conjuntos de dados CICIDS2017, UNSW-NB15 e Bot-IoT. As barras representam o modelo proposto, Memória de Curto Prazo Longo (LSTM), Máquina de Vetores de Suporte (SVM) e Árvore de Decisão (DT). O eixo x representa conjuntos de dados, e o eixo y representa a precisão da classificação (%). Por favor, clique aqui para ver uma versão ampliada desta figura.

figure-results-4
Figura 6. Comparação precisa de modelos de classificação entre conjuntos de dados de detecção de intrusões. Gráfico de barras agrupado mostrando a precisão (%) obtida por diferentes modelos nos conjuntos de dados CICIDS2017, UNSW-NB15 e Bot-IoT. O eixo x representa modelos de classificação, e o eixo y representa precisão (%). LSTM, Memória de Curto Prazo Longo; SVM, Máquina Vetorial de Suporte; DT, Árvore de Decisão. Por favor, clique aqui para ver uma versão ampliada desta figura.

figure-results-5
Figura 7. Lembre-se da comparação de modelos de classificação entre conjuntos de dados de detecção de intrusões. Gráfico de barras agrupado mostrando a recordação (%) obtida por diferentes modelos nos conjuntos de dados CICIDS2017, UNSW-NB15 e Bot-IoT. O eixo x representa modelos de classificação, e o eixo y representa a recordação (%). LSTM, Memória de Curto Prazo Longo; SVM, Máquina Vetorial de Suporte; DT, Árvore de Decisão. Por favor, clique aqui para ver uma versão ampliada desta figura.

Para compreender melhor a contribuição de cada componente arquitetônico, foi realizado um estudo de ablação. Os resultados, resumidos na Tabela 14, mostram que o mecanismo de atenção melhorou a priorização temporal, as camadas residual e convolucional aprimoraram a extração de características e o aprendizado estabilizado, e a integração com blockchain proporcionou registros forenses à prova de adulteração juntamente com mitigação automatizada. Cada aprimoramento arquitetônico contribuiu incrementalmente para melhorar a precisão da detecção, ao mesmo tempo em que reduziu as previsões de falsos positivos.

Variante do ModeloPrecisão (%)Precisão (%)Recall
(%)
F1-Score (%)Taxa de Falsos Positivos
(%)
Notas
BiLSTM Simples97.593.993.393.671.47Modelo básico de detecção sequencial de intrusões
BiLSTM + Atenção98.0495.1894.8595.011.18O mecanismo de atenção prioriza características temporais informativas
BiLSTM Estendido (Residual + Conv1D)97.594.693.0693.821.3Conexões residuais e camadas convolucionais melhoram a extração de características temporais e a estabilidade do treinamento
BiLSTM Estendido + Blockchain98.997.596.997.30.59Framework completo com detecção de intrusões, registro imutável e mitigação automatizada

Tabela 14: Estudo de ablação de componentes arquitetônicos no framework proposto para detecção de intrusão. Esta tabela resume a contribuição de componentes arquitetônicos individuais, incluindo mecanismos de atenção, aprendizado residual, extração de características convolucionais e integração com blockchain, para o desempenho geral do framework proposto.

Para cada variante de ablação, um único componente da estrutura proposta foi removido enquanto todas as condições restantes foram mantidas constantes. O mesmo conjunto de dados, entradas janelas pré-processadas, divisão estratificada 80:20 de train/test idêntica com partição de validação, semente aleatória fixa (42), otimizador (Adam), taxa de aprendizado (0,001), tamanho do lote (64), máximo de 50 épocas de treinamento, critério de parada precoce (paciência = 5), taxa de abandono (0,3) e arquitetura de rede foram mantidos em todos os experimentos. Apenas o componente em avaliação foi modificado, garantindo assim que as diferenças de desempenho observadas fossem atribuíveis exclusivamente ao componente removido.

A estrutura proposta manteve um equilíbrio favorável entre precisão e recordação em comparação com os modelos de linha de base (LSTM, SVM e DT), demonstrando melhor discriminação de padrões sutis de ataque sem aumentar substancialmente as previsões falsos positivos. Esse desempenho equilibrado se reflete na diferença consistentemente pequena entre valores de precisão e de recordação, indicando um alto score F1 e uma generalização robusta em tráfego de rede heterogêneo. Comparações de precisão e recordação são apresentadas nas Figuras 6 e 7.

Comparado com linhas de base IDS representativas, incluindo SVM, DT e LSTM, a estrutura proposta demonstrou uma vantagem consistente de desempenho nos conjuntos de dados de benchmark com tráfego benigno suficiente. Em CICIDS2017, o modelo BiLSTM–Blockchain Estendido proposto alcançou 98,9% de precisão, superando as linhas de base de LSTM (97,5%), DT (97,5%) e SVM (98,1%). No UNSW-NB15, alcançou 95,9% de precisão, novamente a maior entre os modelos avaliados (LSTM 92,2%, SVM 94,1%, DT 94,8%). No Bot-IoT, caracterizado por desequilíbrio extremo de classe com uma classe benigna muito pequena, o modelo proposto alcançou 98,8% de precisão, correspondendo à linha base da DT e superando marginalmente as linhas de base LSTM (98,3%) e SVM (98,7%). Modelos tradicionais de aprendizado de máquina apresentavam capacidade comparativamente limitada para modelar dependências temporais de longo alcance, enquanto o LSTM melhorava o aprendizado de características temporais; No entanto, nenhum desses modelos básicos oferecia registro forense resistente a adulteração ou rastreabilidade automatizada de eventos baseada em blockchain. Ao integrar aprendizado residual, um mecanismo de atenção e logging imutável baseado em blockchain com a arquitetura BiLSTM Estendida, o framework proposto combinou desempenho competitivo em detecção de intrusão com responsabilidade forense verificável além da fornecida pelos métodos básicos. O componente blockchain registra cada intrusão detectada como uma entrada do livro-razão imutável contendo o identificador de bloco, carimbo de data, dados de eventos criptografados, hash criptográfico e assinatura digital. Um exemplo da estrutura de registros blockchain é mostrado na Figura 8. A precisão comparativa e a taxa de erro entre os modelos avaliados são apresentadas nas Figuras 9 e 10, respectivamente, enquanto a Figura 11 compara os tempos de treinamento dos modelos avaliados. As métricas gerais de desempenho do framework proposto, incluindo precisão, precisão, recordação, F1-score e taxa de falsos positivos, são resumidas na Figura 12, e a comparação combinada de precisão e F1-score é apresentada na Figura 13.

figure-results-6
Figura 8. Exemplo de registro de intrusão em blockchain gerado após a detecção de intrusão. Exemplo ilustrativo de um registro blockchain criado após a detecção de intrusão. O registro contém um identificador de bloco, identificador de paciente/dispositivo, carimbo de data, dados de eventos criptografados, hash do bloco anterior, hash do bloco atual e assinatura digital. A estrutura do registro corresponde à representação do blockchain definida na Equação 14. Por favor, clique aqui para ver uma versão ampliada desta figura.

figure-results-7
Figura 9. Comparação de precisão entre o framework proposto e os modelos de detecção de intrusão de referência. Gráfico de barras comparando a precisão da classificação do framework BiLSTM–Blockchain Estendido proposto com modelos de detecção de intrusões de benchmark. O eixo x representa modelos de classificação, e o eixo y representa a precisão da classificação (%). LSTM, Memória de Curto Prazo Longo; SVM, Máquina Vetorial de Suporte; DT, Árvore de Decisão. Por favor, clique aqui para ver uma versão ampliada desta figura.

figure-results-8
Figura 10. Comparação de taxa de erro entre o framework proposto e os modelos de detecção de intrusão de benchmark. Gráfico de barras mostrando as taxas finais de erro obtidas pelo framework BiLSTM–Blockchain Estendido proposto e pelos modelos de detecção de intrusões de benchmark. O eixo x representa modelos de classificação, e o eixo y representa a taxa de erro (%). Por favor, clique aqui para ver uma versão ampliada desta figura.

figure-results-9
Figura 11. Comparação de tempo de treinamento de modelos de detecção de intrusão. Gráfico de barras mostrando a duração do treinamento com relógio de parede de cada modelo avaliado. O eixo x representa modelos de classificação, e o eixo y representa o tempo de treinamento (segundos). Os tempos de treinamento foram medidos usando o ambiente de computação experimental descrito no protocolo. Por favor, clique aqui para ver uma versão ampliada desta figura.

figure-results-10
Figura 12. Métricas de desempenho do framework BiLSTM–Blockchain Estendido proposto. Gráfico de barras resumindo o desempenho do framework proposto. As métricas incluem precisão, exatião, recordação (taxa de detecção) e pontuação F1. A taxa de falsos positivos (FPR = 0,59%) também é registrada como uma anotação na figura. O eixo y representa valores de desempenho (%). FPR, taxa de falsos positivos. Por favor, clique aqui para ver uma versão ampliada desta figura.

figure-results-11
Figura 13. Comparação de precisão e pontuação F1 entre modelos de detecção de intrusão. Gráfico de barras agrupado comparando a precisão da classificação e o escore F1 entre os modelos avaliados de detecção de intrusão. Barras roxas representam precisão, e barras verdes representam a pontuação F1. O eixo x representa modelos de classificação, e o eixo y representa desempenho (%). LSTM, Memória de Curto Prazo Longo; SVM, Máquina Vetorial de Suporte; DT, Árvore de Decisão. Por favor, clique aqui para ver uma versão ampliada desta figura.

A matriz de confusão obtida na etapa de classificação binária é apresentada na Tabela 15 e visualizada na Figura 14. Agrupados nos três conjuntos de teste de referência, o modelo classificou corretamente 486.798 instâncias normais, com 4.916 amostras normais classificadas erroneamente como intrusões. Para a classe de intrusão, 877.494 instâncias de intrusão foram corretamente identificadas, enquanto 12.978 amostras de intrusão foram classificadas incorretamente como normais. Esses resultados demonstram alta capacidade discriminativa com relativamente poucos erros de classificação, indicando desempenho confiável para detecção de intrusões binárias em ambientes IoMT. A precisão relatada, o escore F1, a latência e o throughput correspondem exclusivamente ao estágio de detecção de intrusão binária avaliado neste estudo.

ModeloConjunto de dadosTamanho do conjunto de testeTrue ClassNormal previstoIntrusão previstaTotal (Verdadeiro)
BiLSTM Estendido Proposto - BlockchainCICIDS 2017566149Normal4519462673454619
Intrusão3426108104111530
Total (Previsível)455372110777566149
UNSW-NB 1582332Normal34764223637000
Intrusão10874424545332
Total (Previsível)358514648182332
Bot-IoT733705Normal88795
Intrusão8465725145733610
Total (Previsível)8553725152733705
LSTMCICIDS 2017566149Normal4479466673454619
Intrusão7396104134111530
Total (Previsível)455342110807566149
UNSW-NB 1582332Normal32765423537000
Intrusão21534317945332
Total (Previsível)349184741482332
Bot-IoT733705Normal851095
Intrusão12465721145733610
Total (Previsível)12550721155733705
SVMCICIDS 2017566149Normal4492575362454619
Intrusão5743105787111530
Total (Previsível)455000111149566149
UNSW-NB 1582332Normal33729327137000
Intrusão15684376445332
Total (Previsível)352974703582332
Bot-IoT733705Normal841195
Intrusão9465724145733610
Total (Previsível)9549724156733705
DTCICIDS 2017566149Normal4486975922454619
Intrusão7743103787111530
Total (Previsível)456440109709566149
UNSW-NB 1582332Normal34129287137000
Intrusão13974393545332
Total (Previsível)355264680682332
Bot-IoT733705Normal89695
Intrusão8465725145733610
Total (Previsível)8554725151733705

Tabela 15: Matriz de confusão do modelo proposto de detecção de intrusão. Esta tabela apresenta a matriz de confusão obtida a partir da avaliação do modelo proposto por conjunto de testes. Linhas correspondem a rótulos de classe verdadeiros e colunas correspondem a rótulos de classe previstos para classes de tráfego normal e de intrusão.

figure-results-12
Figura 14. Matrizes de confusão do sistema proposto de detecção de intrusão BiLSTM–Blockchain Estendido entre os conjuntos de dados de referência. Matrizes de confusão mostrando resultados de classificação para os conjuntos de dados CICIDS2017, UNSW-NB15 e Bot-IoT. Linhas correspondem a rótulos verdadeiros e colunas correspondem a rótulos previstos. Os valores das células indicam o número de instâncias atribuídas a cada resultado de classificação. IDS, Sistema de Detecção de Intrusões. Por favor, clique aqui para ver uma versão ampliada desta figura.

A precisão por classes, recordação e valores de pontuação F1 derivados da matriz de confusão são resumidos na Tabela 16. Alta precisão indica que o framework proposto raramente classifica incorretamente o tráfego benigno como malicioso, reduzindo assim alertas desnecessários em ambientes de saúde. Da mesma forma, os altos valores de recall demonstram detecção eficaz de eventos de intrusão enquanto minimizam ataques perdidos. As pontuações consistentemente fortes no F1 em ambas as classes confirmam que a estrutura proposta alcançou um equilíbrio entre sensibilidade de detecção e precisão de classificação, apoiando sua adequação para a detecção de intrusões IoMT em tempo real.

ClassePrecisão (%)Recall
(%)
F1-Score
(%)
Normal97.49998.2
Intrusão99.4498.5498.99
Média98.4298.7798.59

Tabela 16: Métricas de desempenho por classe do modelo proposto de detecção de intrusão. Esta tabela reporta os valores de precisão, recordação e pontuação F1 para classes normais e de intrusão, juntamente com o desempenho médio geral obtido durante a avaliação do conjunto de testes.

Eficiência computacional
O desempenho em tempo real foi avaliado usando medições de tempo offline nas janelas de teste pré-processadas, em vez de um ambiente de transmissão ao vivo. Para cada conjunto de dados, as amostras de teste pré-processadas em janelas foram processadas através do pipeline completo de detecção e registro da blockchain, e o tempo de execução do relógio de parede foi registrado. Os limites de tempo foram definidos da seguinte forma. A latência de detecção (T_d) foi medida desde o instante imediatamente anterior à chamada de inferência do modelo até que as probabilidades previstas fossem retornadas. A latência de mitigação de ponta a ponta (T_mitigation = T_d + T_b) foi medida do mesmo ponto inicial até a conclusão da transação final de criação de blocos na blockchain, com o componente de escrita da blockchain (T_b) calculado como a diferença entre as duas medições. A verificação do livro razão era realizada após o temporizador de mitigação de latência ter parado e, portanto, foi excluído da latência reportada.

A taxa de transferência foi calculada como o número total de janelas processadas dividido pelo tempo de relógio de parede decorrido necessário para uma passagem completa pela partição de teste de cada conjunto de dados. A latência por evento foi obtida dividindo o tempo decorrido correspondente pelo número total de janelas processadas. A carga de trabalho consistia nas partições de teste janelas dos três conjuntos de dados de benchmark, preservando suas distribuições de classes benignas a intrusão. Janelas classificadas como maliciosas suportavam a sobrecarga adicional de registro de blockchain, incluindo computação digest, assinatura digital e execução de transações por contratos inteligentes, enquanto janelas benignas assumiam apenas o custo de detecção.

A comparação de latência e taxa de transferência entre os modelos representativos de detecção de intrusão é apresentada na Tabela 12. Modelos convencionais de aprendizado de máquina, incluindo DT e SVM, demonstraram menor latência de inferência e maior taxa de transferência do que o framework de aprendizado profundo proposto. A linha de base do LSTM alcançou desempenho intermediário. O framework BiLSTM–Blockchain Estendido proposto operava com uma latência de detecção de aproximadamente 135 ms por evento e um throughput de aproximadamente 320 eventos/s na implantação Clique PoA de nó único descrita na Configuração Experimental. Essas medições caracterizam o desempenho do protótipo de validador único, em vez de uma avaliação de escalabilidade multinós.

Além do desempenho em inferência, o tempo de treinamento de cada modelo avaliado foi comparado para avaliar a eficiência computacional. O tempo de treinamento é uma consideração importante para aplicações IoMT em tempo real, onde a implantação rápida do modelo é desejável. Como mostrado na Figura 11, a DT alcançou a menor latência por evento (aproximadamente 40 ms) e a maior taxa de transferência (aproximadamente 845 eventos/s), seguida pela SVM (aproximadamente 75 ms, 670 eventos/s) e pela LSTM (aproximadamente 110 ms, 559 eventos/s). A proposta framework Extended BiLSTM–Blockchain apresentou a maior latência (aproximadamente 135 ms) e o menor throughput (aproximadamente 320 eventos/s) entre os modelos avaliados. Esse custo computacional adicional decorre da arquitetura bidirecional, do mecanismo de atenção temporal e do registro imutável baseado em blockchain, que juntos proporcionam aprendizado aprimorado de características temporais e rastreabilidade forense à prova de adulteração. Embora esses componentes aumentem a latência por evento, a taxa de transferência alcançada permanece suficiente para monitoramento de intrusões quase em tempo real em ambientes IoMT.

Uma avaliação abrangente de escalabilidade, envolvendo múltiplos nós validadores e cargas de transações variadas, estava além do escopo do protótipo atual de nó único. Avaliar o throughput e a latência como funções da contagem de validadores e da carga de transações sob condições controladas representa uma direção importante para trabalhos futuros que visam caracterizar a escalabilidade do framework em ambientes hospitalares distribuídos de maior porte.

Registro e mitigação de blockchain
A Figura 8 ilustra um exemplo de registro de intrusão em blockchain. Cada bloco armazena de forma segura uma transação de intrusão ou dados médicos dentro do livro-razão da blockchain, registrando um identificador único de bloco (Block_ID), identificador de paciente ou dispositivo (Patient_ID), carimbo de data, dados de intrusão criptografados, o hash do bloco anterior, o hash do bloco atual e uma assinatura digital. Coletivamente, esses campos fornecem confidencialidade, integridade, imutabilidade, autenticação e rastreabilidade forense dentro do proposto framework de detecção de intrusões BiLSTM–Blockchain Estendido.

No geral, os resultados apoiam a hipótese central de que integrar um detector de intrusão BiLSTM Estendido com atenção aprimorada com uma camada de registro baseada em blockchain proporciona detecção de intrusões precisa, eficiente e à prova de adulteração para redes IoMT. A estrutura proposta alcançou uma precisão geral de 98,71% e uma pontuação F1 de 98,99%, superando consistentemente os modelos de referência avaliados em aprendizado de máquina e deep learning, mantendo uma convergência estável e evidências mínimas de sobreajuste. O estudo de ablação demonstrou que cada componente arquitetônico, incluindo as camadas convolucional e residual, o mecanismo de atenção e a integração com blockchain, contribuiu incrementalmente para o desempenho geral da detecção e para a capacidade forense. No protótipo de nó único, a estrutura manteve uma latência média de aproximadamente 135 ms por evento e um throughput de aproximadamente 320 eventos por segundo, enquanto fornecia registro de intrusões imutável e verificável. Coletivamente, essas descobertas apoiam a adequação da proposta de estrutura integrada de detecção e blockchain para detecção de intrusões em tempo real e registro forense seguro em ambientes IoMT.

Disponibilidade de Dados:
Os conjuntos de dados de referência usados neste estudo são publicamente disponíveis. O conjunto de dados UNSW-NB15 está disponível no repositório UNSW Canberra (https://research.unsw.edu.au/projects/unsw-nb15-dataset), o conjunto de dados CICIDS2017 está disponível no Instituto Canadense de Cibersegurança (https://www.unb.ca/cic/datasets/ids-2017.html), e o conjunto de dados Bot-IoT está disponível no repositório UNSW Canberra (https://research.unsw.edu.au/projects/bot-iot-dataset).

Os materiais completos necessários para reproduzir o estudo são fornecidos como arquivos suplementares. O Arquivo Suplementar 1 contém o pseudocódigo completo para os algoritmos de pré-processamento, seleção de recursos, treinamento de modelos, detecção de intrusões, blockchain e contratos inteligentes descritos no Protocolo. O Arquivo Suplementar 2 contém a implementação completa do pipeline de pré-processamento de dados, modelo BiLSTM Estendido, scripts de treinamento e avaliação, cliente blockchain, scripts de geração de figuras e pipeline de execução de ponta a ponta. O README que acompanha fornece instruções passo a passo para reproduzir o fluxo de trabalho, incluindo preparação do conjunto de dados, treinamento de modelos, avaliação, geração de figuras e implantação opcional de blockchain. O arquivo requirements.txt que acompanha especifica as dependências do pacote Python necessárias para recriar o ambiente computacional.

FiguraTipo de figuraGerado a partir de
1Diagrama de arquitetura conceitualSoftware de desenho vetorial
2Diagrama de fluxo de dados em nível de implementaçãoSoftware de desenho vetorial
3Curva de convergência de precisãoHistórico de treinamento (precisão de treinamento e validação por época)
4Curva de convergência de perdasHistórico de treinamento (perda de treinamento e validação por época)
5Gráfico de barras comparativas de precisãoValores de precisão por modelo
6Gráfico de barras comparativas de precisãoValores de precisão por modelo
7Gráfico de barras comparativas de recallValores de recall por modelo
8Diagrama de estrutura de blocos da blockchainEstrutura conceitual de registros blockchain
9Tabela comparativa de precisãoValores de precisão por método
10Gráfico comparativo de taxa de erroValores de taxa de erro por método
11Tabela comparativa de tempos de treinamentoDuração dos treinos medidos
12Gráfico de resumo de desempenhoValores de precisão, recordação, exatidão, pontuação F1 e taxa de falsos positivos no modelo proposto
13Gráfico de precisão e comparação de pontuação F1Precisão por método e valores de pontuação F1
14Matriz de confusãoContagens de matrizes de confusão

Tabela 17: Fontes de dados usadas para gerar os números incluídos no estudo. Esta tabela resume as fontes de dados e as saídas computacionais usadas para gerar cada figura apresentada no manuscrito. Os números quantitativos foram gerados programaticamente a partir de históricos de treinamento de modelos, métricas de avaliação, saídas de matrizes de confusão e medições de desempenho, enquanto diagramas conceituais foram criados usando software de desenho vetorial.

Arquivo Suplementar 1. Algoritmos e pseudocódigo para o proposto framework de detecção de intrusões BiLSTM–Blockchain Estendido. Este arquivo suplementar contém o pseudocódigo completo para o pipeline de pré-processamento (Algoritmo 1), Detecção de Intrusão BiLSTM Estendida (Algoritmo 2), treinamento de modelos com parada precoce (Algoritmo 3), detecção e mitigação de intrusões baseada em blockchain (Algoritmo 4), seleção de características AQU-IMF-RFE (Algoritmo 5) e o procedimento de registro de intrusões de contratos inteligentes (Algoritmo 6). Por favor, clique aqui para baixar este arquivo.

Arquivo Suplementar 2. Código-fonte para a proposta estrutura de detecção de intrusões BiLSTM–Blockchain estendida. Este arquivo suplementar contém a implementação completa do pipeline de pré-processamento, modelo BiLSTM Estendido, treinamento e avaliação do modelo, pipeline de execução de ponta a ponta, cliente blockchain e scripts de geração de figuras necessários para reproduzir os resultados reportados. Por favor, clique aqui para baixar este arquivo.

Arquivo Suplementar 3. Procedimentos detalhados de implementação e otimização para o framework proposto de detecção de intrusões BiLSTM–Blockchain estendido. Este arquivo suplementar fornece detalhes de implementação omitidos do Protocolo principal para maior brevidade, incluindo (A) Otimização do treinamento BiLSTM estendido e formulação matemática (objetivo de treinamento, otimização Adam, parada precoce e configuração de hiperparâmetros); (B) implementação detalhada em redes neurais (Conv1D, BiLSTM empilhado, projeção residual, mecanismo de atenção, inicialização de peso, dropout e configurações de classificação); (C) implantação de blockchain e implementação de contratos inteligentes; (D) procedimentos de geração e verificação de assinaturas digitais; (E) processamento de eventos por contratos inteligentes e fluxo de trabalho automatizado de resposta; e (F) interpretação da análise de complexidade computacional. Esses detalhes suportam a total reprodutibilidade do framework proposto, mantendo a legibilidade do Protocolo principal. Por favor, clique aqui para baixar este arquivo.

README.
Instruções para reproduzir o fluxo de trabalho proposto. Este arquivo fornece instruções de instalação de software, preparação de conjuntos de dados, execução de todo o pipeline de processamento, treinamento de modelos, avaliação, geração de figuras, implantação de blockchain e orientações de reprodutibilidade para o framework proposto.

requirements.txt
Dependências de software para reprodução do ambiente computacional. Este arquivo lista as dependências de pacotes em Python e os requisitos de versão compatível necessários para executar os componentes de pré-processamento, treinamento de modelo, avaliação, blockchain e visualização do framework proposto.

Discussion

Loading...
$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

O presente estudo propõe uma estrutura integrada de BiLSTM–Blockchain Estendida para detecção e prevenção de intrusões em ambientes IoMT. Os resultados demonstram que a estrutura identifica efetivamente padrões de intrusão no tráfego heterogêneo da rede IoMT ao combinar aprendizado temporal bidirecional com registro forense baseado em blockchain. A arquitetura bidirecional permite que o modelo capture tanto dependências temporais para frente quanto para trás dentro do tráfego de rede, resultando em alta precisão (99,44%), uma recall de 98,54% e uma pontuação F1 de 98,99% para a classe de intrusão, mantendo uma baixa taxa de falsos positivos (aproximadamente 1,0%) em comparação com os modelos de detecção de intrusão avaliados na linha de base. Ao contrário das arquiteturas LSTM unidirecionais convencionais ou baseline, que podem falhar em capturar dependências temporais de longo alcance, o modelo proposto reconhece de forma mais eficaz padrões de tráfego sequencial, melhorando a discriminação entre tráfego de rede benigno e malicioso. Esses achados apoiam a hipótese do estudo de que integrar um detector Extended BiLSTM com atenção aprimorada com uma camada de registro blockchain melhora tanto o desempenho da detecção de intrusão quanto a responsabilidade forense.

A estrutura proposta pode ser posicionada dentro de várias direções de pesquisa já estabelecidas. Uma linha de pesquisa foca na detecção de intrusões aprimorada por seleção de características para sistemas IoMT, incluindo abordagens baseadas em árvores efiltros 8, detectores de aprendizado em conjunto9 e nosso framework de seleção de características AQU-IMF-RFE previamentereportado 18. Essas abordagens melhoram a precisão da detecção por meio da redução de dimensionalidade, mas geralmente dependem de classificadores que não modelam explicitamente dependências temporais bidirecionais no tráfego de rede. A estrutura proposta complementa, em vez de substituir, esses métodos usando AQU-IMF-RFE18 para construir um espaço de recursos otimizado, sobre o qual o BiLSTM Estendido realiza a detecção de intrusões temporais enquanto a camada blockchain fornece registros forenses imutáveis. Uma segunda linha de pesquisa emprega modelos de aprendizado de sequências para detecção de intrusões, incluindo arquiteturas BiLSTM aprimoradaspor atenção 7, IDSs de redebaseadas em BiLSTM 31 e abordagens recorrentes de redesneurais 32,33. De acordo com esses estudos, os achados atuais confirmam o valor da modelagem temporal bidirecional, com o BiLSTM Estendido aumentado de atenção alcançando escores F1 mais altos do que as linhas de base LSTM e CNN avaliadas neste estudo. No entanto, ao contrário desses modelos focados em detecção, o framework proposto incorpora também o registro de blockchain à prova de adulteração. Uma terceira direção de pesquisa explora a segurança baseada em blockchain para sistemas de saúde e IoT, incluindo arquiteturas de saúde habilitadas por blockchain e integridadeforense 28,34,35, controle de acesso a blockchain com permissão 36,37 e detecção de intrusões federadas orientadas por blockchain para o IoMT38. Embora esses estudos estabeleçam o valor da imutabilidade e da auditabilidade, geralmente tratam a detecção de intrusão e o registro forense como processos separados ou empregam mecanismos de consenso mais intensivos em computação. Em contraste, o framework proposto integra uma blockchain PoA leve e permissada diretamente com o detector de intrusões para fornecer logging imutável e mitigação orientada a eventos, mantendo baixo overhead computacional. Em relação às abordagens recentes de deep learning do IoMT, incluindo a detecção de intrusões baseada em engenhariade recursos 39 e o aprendizado federado para IoTmédico 40, a principal contribuição do presente estudo é a integração da detecção temporal bidirecional com rastreabilidade forense baseada em blockchain dentro de um framework unificado, em vez de apenas melhorias na precisão da detecção.

A integração com blockchain adiciona confiança, responsabilidade e capacidades forenses importantes ao framework proposto. Registros imutáveis da blockchain garantem que eventos de intrusão não possam ser modificados após a gravação, apoiando assim a conformidade regulatória e a auditoria forense em ambientes de saúde. Cada evento registrado armazena identificadores de dispositivo, carimbos de data, hashes criptográficos e assinaturas digitais que facilitam verificação transparente e rastreabilidade. Além disso, a camada de contratos inteligentes possibilita mitigação automatizada orientada a eventos, gerando flags de isolamento de nós e alertas de administrador que são processados por um ouvinte off-chain, reduzindo assim o tempo de resposta enquanto preserva um registro auditável de cada evento de segurança. Coletivamente, essas capacidades estendem o framework além da detecção convencional de intrusões, integrando detecção, registro seguro e resposta automatizada em uma única arquitetura.

Devem ser reconhecidas várias limitações do presente estudo. Metodologicamente, a avaliação do modelo foi realizada usando uma única divisão estratificada de hold-out com uma semente aleatória fixa (42), em vez de validação cruzada repetida ou múltiplas inicializações aleatórias. Os hiperparâmetros foram selecionados a partir de valores padrão estabelecidos, em vez de por meio de um procedimento exaustivo de otimização. A avaliação experimental baseou-se em três conjuntos de dados de referência públicos (UNSW-NB15, CICIDS2017 e Bot-IoT)41,42,43, que, embora amplamente aceitos, representam capturas estáticas de tráfego em vez de tráfego de rede em constante evolução. Seu desequilíbrio inerente de classe também pode influenciar o desempenho do modelo, apesar da aplicação do treinamento ponderado por turma. Além disso, a arquitetura BiLSTM Estendida contém mais parâmetros treináveis e requer tempos de treinamento mais longos do que as linhas de base convencionais de aprendizado de máquina devido à sua estrutura bidirecional recorrente e mecanismo de atenção. Embora a latência de inferência medida suporte a implantação em tempo real na estação de trabalho de avaliação, os requisitos computacionais e de memória podem exceder as capacidades dos dispositivos de borda IoMT com recursos limitados, tornando a implantação em nível de gateway ou baseada em servidor mais prática. A estrutura ainda assume que a detecção de intrusão e o registro da blockchain ocorrem em nós de gateway confiáveis e que os nós validadores de PoA com permissão se comportam de forma honesta. O registro de blockchain introduz uma latência média de confirmação de aproximadamente 2 s, e o crescimento do livro maior pode se tornar uma preocupação de escalabilidade em implantações em larga escala. A suposição de validador confiável é uma característica inerente das blockchains PoAautorizadas 24,25, enquanto desafios mais amplos de segurança blockchain foram revisados em outroslugares 24. Consequentemente, mitigar a conivência de validadores em implantações multi-institucionais continua sendo um tema importante para futuras investigações. Por fim, embora as estatísticas de pré-processamento tenham sido derivadas exclusivamente da partição de treinamento para evitar vazamento de informações, o uso de conjuntos de dados de benchmark offline pré-processados em vez de tráfego de rede ao vivo pode superestimar o throughput prático, e artefatos conhecidos de rotulagem e amostragem dentro dos conjuntos de dados de benchmark podem introduzir viés específico de cada conjunto. Embora o mecanismo de atenção ofereça um grau de interpretabilidade, a estrutura permanece em grande parte uma caixa-preta de aprendizado profundo, potencialmente limitando a transparência para clínicos e analistas de segurança que precisam de mais alertas interpretáveis. Essa limitação é consistente com observações relatadas em pesquisas anteriores de detecção de intrusão de aprendizado profundo 6,11,44.

Existem várias oportunidades para ampliar ainda mais o arcabouço proposto. A validação em bancadas de teste IoMT ao vivo ou redes operacionais de hospitais forneceria evidências adicionais de desempenho no mundo real além dos conjuntos de dados de referência offline. A implementação do blockchain poderia ser expandida do protótipo atual de nó único para uma implantação multivalidadora distribuída, permitindo uma avaliação abrangente de escalabilidade. Técnicas de compressão, poda ou quantização de modelos podem facilitar a implantação em dispositivos de borda com recursos limitados. Pesquisas adicionais também poderiam incorporar aprendizado online para lidar com desvio de conceitos e ataqueszero-day 45, aprendizado federado para permitir treinamento colaborativo de modelos entre instituições de saúde sem compartilhar dados sensíveisde pacientes 40, e métodos explicáveis de IA para fornecer alertas de intrusão mais transparentes para clínicos e profissionais de cibersegurança.

No geral, a proposta de framework BiLSTM–Blockchain Estendido demonstra forte adaptabilidade, responsabilidade forense e desempenho robusto em detecção de intrusões. Ao integrar aprendizado temporal aprimorado por atenção com registro imutável em blockchain e mitigação automatizada, a estrutura combina alta precisão de detecção com rastreabilidade forense segura e baixas taxas de falsos positivos. Essas descobertas demonstram o potencial da abordagem proposta como um método prático para garantir ambientes IoMT em tempo real, ao mesmo tempo em que apoia auditorias confiáveis e resposta de segurança oportuna em sistemas de saúde.

Disclosures

Loading...
$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Conflito de Interesses:
Os autores declaram que não possuem interesses concorrentes relevantes para o conteúdo deste artigo.

Acknowledgements

Loading...
$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

Gostaria de expressar minha sincera gratidão ao Lakireddy Bali Reddy College of Engineering (A), Mylavaram, por fornecer as instalações de pesquisa essenciais para a conclusão deste trabalho. Os recursos e o apoio oferecidos pelo centro desempenharam um papel vital para viabilizar o progresso tranquilo da minha pesquisa. Sou profundamente grato aos meus orientadores, Dr. D. Veeraiah e Dr. L. Sumalatha, por sua orientação contínua, insights inestimáveis e incentivo inabalável ao longo deste estudo. Essa pesquisa não recebeu nenhuma bolsa específica de agências financiadoras dos setores público, comercial ou sem fins lucrativos.

Materials

List of materials used in this article
NameCompanyCatalog NumberComments
AQU-IMF-RFE Feature Selection ModuleSelf-developedN/AMétodo híbrido de seleção de recursos integrando Informação Mútua, Aquila Optimizer e Eliminação Recursiva de Recursos
Attention LayerSelf-developed (Keras-based)N/AMecanismo de atenção temporal usado para ponderação de recursos no modelo Extended BiLSTM
Bot-IoT DatasetUNSW Canberra CyberN/AConjunto de dados de referência público usado para avaliação de detecção de intrusão
CICIDS2017 DatasetCanadian Institute for CybersecurityN/AConjunto de dados de referência público para detecção de intrusão
Ethereum Client (Geth)Ethereum Foundation1.13.15Cliente de blockchain usado para implantar e operar a rede Proof-of-Authority
Extended BiLSTM ModelSelf-developedN/AModelo de detecção de intrusão de aprendizado profundo integrando Conv1D, BiLSTM, aprendizado residual e atenção temporal
Jupyter NotebookProject Jupyter7.xAmbiente interativo usado para implementação, experimentação e visualização de resultados
NumPyNumPy Developers2.4.4Biblioteca de computação numérica usada para pré-processamento e treinamento de modelo
PandasPandas Development Team3.0.2Biblioteca de processamento de dados usada para pré-processamento e análise de dados
Proof-of-Authority Blockchain NetworkSelf-developedN/ARede blockchain autorizada usada para registro imutável de intrusão e mitigação automatizada
PythonPython Software Foundation3.12.7Linguagem de programação usada para pré-processamento de dados, desenvolvimento de modelo, integração de blockchain e avaliação
Random Forest EstimatorScikit-learn DevelopersN/AClassificador Random Forest usado para Eliminação Recursiva de Recursos (RFE)
Scikit-learnScikit-learn Developers1.8.0Biblioteca de aprendizado de máquina usada para pré-processamento, seleção de recursos e avaliação de modelo
Solidity Compiler (solc)Solidity Team0.8.19Compilador usado para compilação e implantação de contratos inteligentes
Solid-State Drive (SSD)Dell512 GBArmazenamento usado para conjuntos de dados, modelos treinados e registro blockchain
System Memory (RAM)Dell128 GBMemória principal usada durante o pré-processamento, treinamento de modelo, execução de blockchain e avaliação
TensorFlowGoogle2.16.1Framework de aprendizado profundo usado para implementar e treinar o modelo Extended BiLSTM
UNSW-NB15 DatasetUNSW Canberra CyberN/AConjunto de dados de referência público usado para treinamento e avaliação
Web3.pyWeb3.py Developers6.15.1Interface Python usada para comunicação entre o sistema de detecção de intrusão e a rede blockchain
Windows Operating SystemMicrosoftWindows 11Sistema operacional usado para todos os experimentos
Workstation / ServerDellPowerEdge R740Plataforma de computação usada para treinamento de modelo, implantação de blockchain e avaliação

Reprints and Permissions

Request permission to reuse the text or figures of this JoVE article

Request Permission

Tags

EngineeringBiLSTMBlockchainIntrusion Detection SystemIoMTCybersecuritydeep learningReal Time DetectionAnomaly detectionNetwork Security
Video Coming Soon

Related Articles