Evaluation Pitfalls and Multimodal Baselines for the \dataset{} IoT Malware Dataset

No mundo digital, pesquisadores de segurança atuam como médicos do sistema imunológico para computadores. Eles constroem ferramentas para detectar software malicioso, ou malware, antes que ele possa causar danos. Para treinar essas ferramentas, eles precisam de vastas bibliotecas de dados: gravações de como os computadores se comportam quando estão saudáveis e gravações de como se comportam quando estão doentes. A qualidade dos dados de treinamento determina o quão bem as ferramentas de segurança resultantes funcionarão. Se os dados forem falhos, as ferramentas falharão no mundo real, muitas vezes deixando passar ameaças perigosas ou gerando alarmes falsos. Um grande desafio neste campo é garantir que a maneira como os pesquisadores dividem seus dados em grupos de treinamento e teste não introduza acidentalmente um viés. Se um programa de computador vir uma peça específica de malware durante o treinamento e depois vir exatamente essa mesma peça durante o teste, ele não está realmente aprendendo a detectar novas ameaças; está simplesmente memorizando a resposta. Além disso, os pesquisadores devem decidir se julgam uma ferramenta de segurança pela capacidade de capturar momentos individuais de atividade suspeita ou por quão bem ela identifica programas inteiros infectados, o que pode ser uma tarefa muito diferente.

Uma equipe de pesquisadores da Universidade de Tarim voltou recentemente sua atenção para uma nova e incomumente detalhada biblioteca de dados chamada CIC-YNU-IoTMal2026. Este conjunto de dados é um tesouro para especialistas em segurança porque registra três tipos diferentes de informações simultaneamente para milhares de programas de computador. Ele captura o tráfego de rede fluindo para dentro e para fora, a atividade do sistema, como o uso da CPU, e a lista específica de comandos que o programa dá ao sistema operacional. Esses programas foram executados em quatro tipos diferentes de chips de computador para ver se as ferramentas de segurança poderiam funcionar em diferentes hardwares. Os pesquisadores não construíram uma nova ferramenta de segurança; em vez disso, atuaram como auditores. Eles examinaram o próprio conjunto de dados para ver se as formas padrão de testar ferramentas de segurança com esses dados estavam escondendo problemas sérios. Eles queriam saber se as pontuações altas relatadas por outros pesquisadores eram reais ou se eram o resultado de erros sutis na forma como os dados foram manipulados.

A auditoria começou analisando como os dados foram divididos. O método mais comum é pegar todos os momentos registrados de atividade e embaralhá-los aleatoriamente, colocando alguns em um monte de treinamento e outros em um monte de teste. Os pesquisadores descobriram que essa abordagem era fundamentalmente falha para este conjunto de dados específico. Como os dados registram programas inteiros, o embaralhamento dos momentos significava que o monte de teste continha momentos de programas que já estavam no monte de treinamento. Na verdade, cada momento de teste compartilhava seu programa pai com o conjunto de treinamento, e uma pequena porcentagem dos momentos de teste eram duplicatas exatas de momentos de treinamento. Isso significava que qualquer ferramenta de segurança testada dessa forma estava, essencialmente, sendo avaliada em perguntas para as quais já tinha visto as respostas. Embora isso não tenha inflado artificialmente as pontuações neste conjunto de dados específico, significava que os resultados não podiam ser confiados para prever o quão bem uma ferramenta funcionaria em programas novos e verdadeiramente inéditos. Os pesquisadores concluíram que a única maneira justa de testar essas ferramentas é manter programas inteiros juntos, garantindo que nenhum programa apareça tanto no treinamento quanto no teste.

Mesmo quando os pesquisadores corrigiram o método de divisão de dados, descobriram um segundo problema, mais enganoso. O conjunto de dados contém milhares de pequenas instantâneas de atividade, e muitas ferramentas de segurança são julgadas pela forma como capturam essas instantâneas individuais. Os pesquisadores descobriram que esse método esconde um modo de falha perigoso. Cerca de dezesseis por cento dos programas maliciosos no conjunto de dados foram completamente ignorados pelas ferramentas de segurança. Esses programas ignorados não eram sofisticados; eles estavam simplesmente dormentes. Eles haviam sido executados no ambiente de teste, mas falharam em "acordar" e iniciar suas atividades maliciosas, portanto, pareciam exatamente com programas inofensivos. Como os programas maliciosos que acordaram eram muito barulhentos e geravam centenas de instantâneas de atividade, eles dominaram as estatísticas. Os programas quietos e dormentes foram abafados, fazendo com a ferramenta de segurança parecer muito melhor do que realmente era. Os pesquisadores enfatizaram que, para obter uma imagem real de segurança, deve-se julgar a ferramenta pelo fato de ela capturar o programa inteiro, não apenas os momentos barulhentos.

O estudo também investigou como as ferramentas se comportaram diante de diferentes tipos de chips de computador. O conjunto de dados incluía programas rodando em quatro arquiteturas diferentes, e os pesquisadores testaram se uma ferramenta treinada em três delas conseguiria detectar ameaças na quarta. Os resultados foram drásticos. Quando a ferramenta foi testada em um tipo específico de chip chamado ARM, que é comum em muitos dispositivos pequenos, ela colapsou. A ferramenta tornou-se tão pouco confiável que sinalizou programas inofensivos como perigosos quase oitenta por cento das vezes, enquanto ainda capturava quase todo o malware. Essa falha não foi porque a ferramenta não conseguiu reconhecer o malware; foi porque os programas inofensivos no chip ARM se comportaram de maneira diferente dos programas inofensivos nos outros chips. A ferramenta aprendeu os padrões errados para o que era o "normal" naquele hardware específico. Os pesquisadores descobriram que esse problema poderia ser resolvido de forma muito barata. Ao mostrar à ferramenta apenas uma fração minúscula dos programas inofensivos do novo chip — menos de um por cento do total de dados — o desempenho da ferramenta recuperou-se instantaneamente para perto da perfeição. Isso sugeriu que a solução para a segurança entre chips não são algoritmos novos e complexos, mas simplesmente expor a ferramenta a alguns exemplos do novo ambiente.

Finalmente, os pesquisadores analisaram os diferentes tipos de dados disponíveis: tráfego de rede, atividade do sistema e rastros de comandos. Eles descobriram que, em um ambiente controlado, combinar os três tipos de dados tornava as ferramentas de segurança quase perfeitas. No entanto, essa perfeição era frágil. Quando as ferramentas foram forçadas a depender apenas do tráfego de rede, elas perderam os programas dormentes. Quando dependeram apenas dos rastros de comandos, falharam completamente quando a arquitetura do chip mudou. A combinação mais robusta revelou-se uma mistura de tráfego de rede e atividade do sistema, o que evitou as fraquezas específicas dos outros métodos. Os pesquisadores também observaram que o tipo específico de modelo matemático usado para construir a ferramenta importava muito pouco. Quer utilizassem um modelo linear simples ou uma rede neural complexa, os resultados eram quase idênticos. Isso provou que o fator determinante para o sucesso não era a sofisticação da ferramenta, mas as escolhas feitas sobre como dividir os dados, como definir um sucesso e como lidar com os diferentes tipos de chips de computador.

O artigo conclui com um conjunto de diretrizes claras para qualquer pessoa que utilize este conjunto de dados. Eles recomendam sempre manter programas inteiros juntos ao dividir os dados, relatar resultados baseados no fato de programas inteiros serem capturados em vez de apenas momentos individuais, e ser transparente sobre como programas desconhecidos ou não classificados são tratados. Eles também instam os pesquisadores a testar suas ferramentas em diferentes chips de computador e a relatar o quanto os resultados variam se o experimento for executado múltiplas vezes. A lição mais importante é que o caminho para uma melhor segurança não reside na construção de modelos mais complexos, mas em fazer perguntas melhores e usar dados mais limpos. Ao corrigir os métodos de avaliação, a comunidade pode garantir que as ferramentas que constroem realmente funcionarão quando forem mais necessárias.