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

En el mundo digital, los investigadores de seguridad actúan como médicos del sistema inmunológico para las computadoras. Construyen herramientas para detectar software malicioso, o malware, antes de que pueda causar daño. Para entrenar estas herramientas, necesitan vastas bibliotecas de datos: grabaciones de cómo se comportan las computadoras cuando están sanas y grabaciones de cómo se comportan cuando están enfermas. La calidad de los datos de entrenamiento determina qué tan bien funcionan las herramientas de seguridad resultantes. Si los datos son defectuosos, las herramientas fallarán en el mundo real, a menudo pasando por alto amenazas peligrosas o generando falsas alarmas. Un desafío importante en este campo es asegurar que la forma en que los investigadores dividen sus datos en grupos de entrenamiento y de prueba no introduzca sesgos accidentalmente. Si un programa informático ve una pieza específica de malware durante el entrenamiento y luego ve exactamente la misma pieza durante la prueba, no está aprendiendo realmente a detectar nuevas amenazas; simplemente está memorizando la respuesta. Además, los investigadores deben decidir si juzgan una herramienta de seguridad por qué tan bien atrapa momentos individuales de actividad sospechosa, o por qué tan bien identifica programas infectados completos, lo cual puede ser una tarea muy diferente.

Un equipo de investigadores de la Universidad de Tarim dirigió recientemente su atención a una nueva y inusualmente detallada biblioteca de datos llamada CIC-YNU-IoTMal2026. Este conjunto de datos es un tesoro para los expertos en seguridad porque registra tres tipos diferentes de información simultáneamente para miles de programas informáticos. Captura el tráfico de red que fluye de entrada y salida, la actividad del sistema como el uso de la CPU y la lista específica de comandos que el programa da al sistema operativo. Estos programas se ejecutaron en cuatro tipos diferentes de chips de computadora para ver si las herramientas de seguridad podían funcionar en diferentes hardware. Los investigadores no construyeron una nueva herramienta de seguridad; en su lugar, actuaron como auditores. Examinaron el conjunto de datos en sí para ver si las formas estándar de probar las herramientas de seguridad en estos datos estaban ocultando problemas graves. Querían saber si las puntuaciones altas reportadas por otros investigadores eran reales o si eran el resultado de errores sutiles en el manejo de los datos.

La auditoría comenzó analizando cómo se dividían los datos. El método más común es tomar todos los momentos registrados de actividad y mezclarlos aleatoriamente, poniendo algunos en un montón de entrenamiento y otros en un montón de prueba. Los investigadores encontraron que este enfoque era fundamentalmente defectuoso para este conjunto de datos específico. Debido a que los datos registran programas enteros, mezclar los momentos significaba que el montón de prueba contenía momentos de programas que ya estaban en el montón de entrenamiento. De hecho, cada momento de prueba compartía su programa padre con el conjunto de entrenamiento, y un pequeño porcentaje de los momentos de prueba eran duplicados exactos de momentos de entrenamiento. Esto significaba que cualquier herramienta de seguridad probada de esta manera estaba, esencialmente, siendo calificada en preguntas para las cuales ya había visto las respuestas. Si bien esto no infló artificialmente las puntuaciones en este conjunto de datos en particular, significó que los resultados no podían confiarse para predecir qué tan bien funcionaría una herramienta con programas nuevos y realmente no vistos. Los investigadores concluyeron que la única forma justa de probar estas herramientas es mantener los programas enteros juntos, asegurando que ningún programa aparezca tanto en el grupo de entrenamiento como en el de prueba.

Incluso cuando los investigadores corrigieron el método de división de datos, descubrieron un segundo problema, más engañoso. El conjunto de datos contiene miles de diminutas instantáneas de actividad, y muchas herramientas de seguridad son juzgadas por qué tan bien atrapan estas instantáneas individuales. Los investigadores descubrieron que este método oculta un modo de falla peligroso. Alrededor del dieciséis por ciento de los programas maliciosos en el conjunto de datos fueron completamente ignorados por las herramientas de seguridad. Estos programas ignorados no eran sofisticados; simplemente estaban latentes. Se habían ejecutado en el entorno de prueba pero no habían despertado para iniciar sus actividades maliciosas, por lo que parecían exactamente programas inofensivos. Debido a que los programas maliciosos que sí despertaron eran muy ruidosos y generaban cientos de instantáneas de actividad, dominaban las estadísticas. Los programas silenciosos y latentes fueron opacados, haciendo que la herramienta de seguridad pareciera mucho mejor de lo que realmente era. Los investigadores enfatizaron que para obtener una imagen real de la seguridad, uno debe juzgar la herramienta basándose en si atrapa el programa completo, no solo los momentos ruidosos.

El estudio también investigó cómo se desempeñaban las herramientas cuando se enfrentaban a diferentes tipos de chips de computadora. El conjunto de datos incluía programas ejecutándose en cuatro arquitecturas diferentes, y los investigadores probaron si una herramienta entrenada en tres de ellas podía detectar amenazas en la cuarta. Los resultados fueron contundentes. Cuando la herramienta fue probada en un tipo específico de chip llamado ARM, que es común en muchos dispositivos pequeños, colapsó. La herramienta se volvió tan poco confiable que marcaba programas inofensivos como peligrosos casi el ochenta por ciento de las veces, mientras seguía atrapando casi todo el malware. Este fallo no se debió a que la herramienta no pudiera reconocer el malware; fue porque los programas inofensivos en el chip ARM se comportaban de manera diferente a los programas inofensivos en los otros chips. La herramienta había aprendido los patrones incorrectos de lo que era "normal" en ese hardware específico. Los investigadores encontraron que este problema podía corregirse de manera muy económica. Al mostrarle a la herramienta solo una pequeña fracción de los programas inofensivos del nuevo chip —menos del uno por ciento del total de los datos—, el desempeño de la herramienta se recuperó instantáneamente a la perfección cercana. Esto sugirió que la solución para la seguridad entre chips no son algoritmos nuevos y complejos, sino simplemente exponer la herramienta a unos pocos ejemplos del nuevo entorno.

Finalmente, los investigadores analizaron los diferentes tipos de datos disponibles: tráfico de red, actividad del sistema y trazas de comandos. Encontraron que, en un entorno controlado, combinar los tres tipos de datos hacía que las herramientas de seguridad fueran casi perfectas. Sin embargo, esta perfección era frágil. Cuando las herramientas se veían obligadas a depender únicamente del tráfico de red, perdían los programas latentes. Cuando dependían solo de las trazas de comandos, fallaban por completo cuando la arquitectura del chip cambiaba. La combinación más robusta resultó ser una mezcla de tráfico de red y actividad del sistema, lo que evitaba las debilidades específicas de los otros métodos. Los investigadores también observaron que el tipo específico de modelo matemático utilizado para construir la herramienta importaba muy poco. Ya fuera que usaran un modelo lineal simple o una red neuronal compleja, los resultados eran casi idénticos. Esto demostró que el factor determinante para el éxito no era la sofisticación de la herramienta, sino las decisiones tomadas sobre cómo dividir los datos, cómo definir un éxito y cómo manejar los diferentes tipos de chips de computadora.

El artículo concluye con un conjunto de directrices claras para cualquiera que utilice este conjunto de datos. Recomiendan siempre mantener los programas enteros juntos al dividir los datos, reportar los resultados basándose en si se atrapan programas completos en lugar de solo momentos individuales, y ser transparentes sobre cómo se tratan los programas desconocidos o no clasificados. También instan a los investigadores a probar sus herramientas en diferentes chips de computadora y a reportar cuánto varían los resultados si el experimento se ejecuta múltiples veces. La lección más importante es que el camino hacia una mejor seguridad no reside en construir modelos más complejos, sino en hacer mejores preguntas y utilizar datos más limpios. Al corregir los métodos de evaluación, la comunidad puede asegurar que las herramientas que construyen realmente funcionen cuando más se necesiten.