El ¿milagroso? machine learning y el malware. Claves para ejercitar el escepticismo (I)

ElevenPaths    12 febrero, 2018
En el principio de la detección del malware se usó la firma. Después vino la heurística, la nube, el big data y en los últimos tiempos, machine learning y la inteligencia artificial. Métodos y técnicas que, convenientemente rodeados de los «sospechosos habituales» (holístico, sinergias, disruptivo, etc.),  podemos encontrar en casi todo discurso. Pero independientemente del negocio alrededor, la tecnología es neutra y no debería ser ni mejor ni peor de por sí, sino más o menos adecuada para resolver un problema. Lo que quizás erosiona la fama de una tecnología pueden ser los titulares forzados cuando se abusa de ellos con fines no puramente tecnológicos. El machine learning aplicado al malware es infinitamente valioso. Eso sí, a veces parece fallar la ejecución del experimento que pretende ensalzarlo. Veamos por qué y ejercitemos el escepticismo.

«XYZ»: El nuevo sistema basado en machine learning, detecta el X%

Probablemente nos hemos topado con este titular a menudo. En general, existen dos métodos de marchine learning: el supervisado, donde se sabe qué se debe buscar, (por ejemplo malware y goodware) y se trata de encontrar reglas generales o elementos (características) que definan estas clases. Por otro lado, el no supervisado, donde no se conoce qué se busca (no está «etiquetado»), sino que se intenta detectar qué características definen grupos más o menos homogéneos, y si solo son dos grupos, qué es anómalo o no por ejemplo.

Trazar una línea entre lo normal y anormal debe hacerse de alguna forma. Si nos ceñimos al método no supervisado, resulta complejo saber qué es anómalo, y se necesitarán muchas iteraciones para una comprobación posterior. Iteraciones que habitualmente se traducen en participación humana o refuerzo puramente «tradicional» del análisis. Así lo hacía el MIT en su detección de anomalías en red que publicaron no hace tanto. En el mundo del malware, este enfoque es muy tendente a falsos positivos que deben ser validados por analistas. Reducir el coste humano en este proceso se busca desde siempre. Por eso las casas antivirus intentan minimizar el análisis manual y construir en lo posible un sistema de machine learning muy preciso que derive en el menor número de muestras que llegan a un analista humano. Cuando el analista saca nuevas conclusiones, el sistema se retroalimenta con mejores reglas para intentar que no se vuelvan a necesitar sus servicios. Aquí la apuesta de las empresas privadas es fuerte, y se juegan buena parte de su éxito en la eficiencia de este sistema, cuyos detalles suelen mantener «en secreto».

En el caso de supervisado, para construir un clasificador las muestras ya vienen etiquetadas. Un conjunto suele ser malware y otro goodware que pasan por una caja de machine learning mezcladas. Si al salir de la caja, las muestras se encuentran lo más separadas posible… el sistema es bueno y se acude al titular. Esto no es extraño entre las publicaciones académicas sobre detección de malware. Pero la cuestión que deberíamos plantearnos es… ¿Qué muestras se toman? ¿Quién las etiquetó como malware y goodware? No existe la brujería: el engranaje matemático que al fin y al cabo se construye en un sistema de machine learning aprenderá lo que se le enseña. Si se le muestra malware muy «típico» que cualquier motor es capaz de detectar, no funcionará mucho mejor que los propios antivirus. Si se le enseña “goodware” de libro, titubeará demasiado ante programas que se salgan de lo común y será tendente al falso positivo. Por tanto, el éxito de un sistema basado en machine learning verdaderamente útil «ahí fuera» radica (entre otros muchos puntos de ejecución) en:

  • ¿En qué te fijas para detectar malware? Peso del fichero, formato, librerías, opcodes, estático, dinámico, etc, etc, etc… esto es la labor del experto, definir convenientemente las «features».
  • ¿Cómo y con qué alimentas tu sistema? ¿Con malware de hace años? ¿Qué familias? ¿Muy detectado por los motores? ¿Con cuántas muestras?…

Esta segunda cuestión es fascinante. Y nadie dispone de la respuesta exacta. Las compañías antivirus en todo caso lo tienen claro: con lo más fresco posible, con la mayor cantidad de malware posible, confirmando por los analistas. El mundo académico, por el contrario, a veces sigue una estrategia diferente.

Claves para detectar un titular con gancho: ¿Qué es malware?

Pensemos un momento: si repasamos titulares y porcentajes, el problema del malware estaría ya resuelto. Entre todas las técnicas mostradas que anuncian (sobre el papel) detectar cerca del 100% del malware, ¿qué puede estar fallando como para que sigan existiendo las infecciones?

No es una pregunta retórica. El malware es complejo, cambiante, difícil de tratar… una carrera hacia adelante y una lucha contra la tecnología y el intelecto del atacado, una quimera donde los límites están mucho más difuminados de lo que pensamos tanto por las circunstancias técnicas como por incluso circunstancias temporales o culturales. Sin embargo, para una máquina que debe convertirse en un detector/clasificador supervisado, la definición y las etiquetas deben ser diáfanas: un grupo de tu conjunto es goodware, el otro malware… dime en qué debo fijarme y eso aprenderé. Y, paradójicamente, la fórmula más común para esto es acudir a los… antivirus. Infinidad de estudios se basan en los propios antivirus para etiquetar el malware. Si lo detectan X motores, es malware. Si no, será goodware. Pero existen dos parámetros absolutamente fundamentales. ¿Cuántos motores deben detectarlos? ¿Qué motores exactamente? ¿Los más populares (o sea, lo más usados por cuestiones técnicas, marketinianas…?… ¿Cuándo deben detectarlas? ¿Muestras «frescas» o consolidadas? Son preguntas fundamentales que habitualmente no cubren el verdadero enigma del malware… la «zona gris». Este problema no es nuevo, ya lo sé. En las comparativas antivirus tradicionales, el conjunto de test se ha utilizado desde siempre como arma arrojadiza, solo que ahora, con el machine learning, vuelve a la palestra como parte fundamental.

La zona gris está fuera de la «zona de confort» de los análisis y estudios

El hecho de considerar como “malware” las muestras detectadas por unos tres motores o más, es aceptada la literatura sobre machine learning de malware en general. Sin embargo, la elección de un buen «umbral» de detección (¿por qué 3?) es un ejercicio complejo que aún no ha sido resuelto ni estandarizado, pero que puede hacer que los resultados de una investigación basada en la clasificación arroje resultados muy diferentes dependiendo de qué se considere malware o goodware, términos que no siempre distinguen correctamente los propios motores antivirus.

Un ejemplo representativo de cómo la variable tiempo influye en qué es necesario conocer para mejorar la detección de malware imagen
Malware que, apenas dos días después, pasa de ser «goodware» a «malware típico».
Un ejemplo representativo de cómo la variable tiempo influye en qué es necesario conocer para mejorar la detección

 
Esa «zona gris» es en la que se mueve el malware fresco (apenas unos días ITW, o «ahí fuera»), funcional, poco detectado (pocos motores son capaces de detenerlo por firma) pero que más tarde acabará siendo moneda común y muy detectado. Esta franja temporal de acción es una ventana en movimiento, que es difícil perseguir y atajar. Y eso no suelen tenerlo en cuenta los estudios. Suelen reducir su «dataset» de estudio y análisis a un buen conjunto de muestras muy detectado, quizás desde hace años, y a otro de goodware muy común e «higiénico». El machine learning por tanto, aprenderá lo mismo que ya hace el propio antivirus y si bien el titular o conclusión de la investigación no será falso (…«se detectan el X% de muestras…») si que podríamos cuestionar qué problema real se está resolviendo: ¿Un problema de detección que ya tienen controlado los sistemas tradicionales de por sí? ¿Estamos investigando para detectar «lo de siempre» y «como siempre» pero con algo más de precisión? En algunos casos lo que se resuelve es un problema más bien académico: se mejora en el «problema de análisis previo». O sea, se demuestra que la técnica matemática X, es mejor que la Y usada sobre el mismo conjunto de muestras que usó el académico Z, en su estudio J. Esto no resulta ni bueno ni malo, es, efectivamente, una expansión de los límites del conocimiento y mejora de los procedimientos y técnicas, que no es mal que uno de los objetivos de la academia en sí mismos.

En una pequeña indagación en estudios académicos, podemos encontrar algunos ejemplos de cómo varían los criterios a la hora de definir qué es malware, y cuántas muestras son necesarias para tomar en consideración un estudio:

Ejemplo de un estudio en el que el malware se clasifica como tal si lo detecta un motor cualquiera imagen
Ejemplo de un estudio en el que el malware se clasifica como tal si lo detecta un motor cualquiera
  • Estudios que etiquetan muestras como malware, si son detectadas por un motor, cualquiera que sea, y esta será su «verdad». Teniendo en cuenta el mundo de los falsos positivos, la tasa de «equivocación temporal» que reina en este aspecto y que cualquiera de la industria puede corroborar… hace que el sistema se construya con una tara de base importante que es necesario matizar.
  • Este otro estudio, por ejemplo, etiqueta como malware si una muestra es detectada por 4 motores o más. No importa cuáles. Quizás esto mitigue el efecto «falso positivo» pero… ¿Por qué cuatro? ¿En qué dato científico se basa esto? ¿Qué cuatro motores? Sabemos que hay motores que licencian la tecnología de otros y que por tanto, siempre detectan «en pareja» o el mismo malware… ¿Se han tenido en cuenta estos aspectos?
  • Otros estudios intentan mejorar y apuntan a que al menos dos de 10 motores concretos, detecten algo como malware para establecerlo como su verdad.. ¿Por qué dos de diez? ¿En base a qué criterio se han elegido esos 10? 
  • Otros utilizan técnicas más «justas» para determinar si algo es malware y dárselo como material de aprendizaje a su máquina. En este ejemplo, se usa una especie de media en la que se tiene un umbral de 0.1 (empírico) en el que se relaciona el número de muestras y la cantidad de antivirus que la cazan. Sin duda curioso pero… ¿sabemos si es eficaz? ¿Y la variable tiempo?
Ejemplo de fórmula con la que se intenta construir un dataset de malware más "preciso" imagen
Ejemplo de fórmula con la que se intenta construir un dataset de malware más «preciso»

En estudios donde se usa de forma similar el machine learning pero se pretende evaluar tráfico malicioso en vez de malware, el problema de tomar «un buen conjunto de muestras inicial» es incluso mayor. Buena parte de los experimentos que anuncia éxitos en detección de anomalías en red, basan su conjunto de muestras en el conocido KDD dataset. De él existen varias versiones: KDD Cup 99, DARPA 98 y NSL-KDD, todos de hace más de 15 años… ¿Son las mismas amenazas de hoy las que podemos encontrar en él? Con estos datos de base, cuando se arañan unas décimas al porcentaje de detección, en realidad, ¿se está compitiendo con el estudio anterior o de verdad se está ganando en detección real?

Entendamos que las preguntas planteadas no tienen respuesta directa, no pretenden descalificar ningún estudio ni deben percibirse como retóricas. Muy al contrario, se formulan para plantear debates. Precisamente un reto interesante al que miramos de frente en ElevenPaths desde el área de innovación y laboratorio, es afrontar abiertamente esa zona gris y estrecharla al máximo.
Continuaremos la reflexión en la siguiente entrada.

También te puede interesar:
» El ¿milagroso? machine learning y el malware. Claves para ejercitar el escepticismo (II)

Sergio de los Santos
ssantos@11paths.com

Comentarios

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *