Virus Bulletin: Reflexiones sobre detección heurística

Virus Bulletin: Reflexiones sobre detección heurística
	VSantivirus No. 1568 Año 8, viernes 22 de octubre de 2004 Virus Bulletin: Reflexiones sobre detección heurística http://www.vsantivirus.com/heuristica-comparativas.htm Virus Bulletin: Reflexiones sobre la forma de examinar la detección heurística en comparativas de productos. Por Andrew Lee. Eset LLC, USA. Examinando la detección heurística en un escenario del mundo real "Llegará el día en que el pensamiento estadístico será tan necesario para el ejercicio de una eficaz ciudadanía como la habilidad para leer y escribir." H. G. Wells (1866-1946) Los resultados publicados habitualmente sobre las pruebas efectuadas con productos antivirus no poseen, en general, base científica, tienen serios errores en la premisas de análisis o utilizan una demostrable incorrecta metodología. Y en las peores situaciones, algunos tienen todos estos errores a la vez. Desafortunadamente, esto es frecuentemente verdad en análisis conducidos por populares publicaciones informáticas, cuyos analistas parecen pensar que evaluando contra "unos pocos ejemplos recolectados por Internet o a través de nuestro correo electrónico", constituyen una evaluación válida sobre las posibilidades de detección de un producto antivirus. Lamentablemente, esto también ha sido cierto para algunas las evaluaciones conducidas por reconocidos analistas de productos antivirus, cuya interpretación de los resultados ha terminado siendo salvajemente modificado, para su publicación por sus respectivas revistas. Las revisiones en las publicaciones para consumidores, son extensamente más leídas que las publicaciones de la industria antivirus y en general, dichos lectores no están suficientemente capacitados para comprender el significado de dichos resultados. Como consecuencia de esto, la confianza pública en los productos antivirus termina siendo el resultado de una aventura. Un clásico ejemplo ocurre cercano al año 2000 cuando CNET evalúa productos utilizando unas infames herramientas denominadas Rosenthal Utilities (RU). Las utilidades Rosenthal generaban archivos benignos (léase no víricos) con datos que contenían parcialmente código viral. La sección elegida del ejecutable mostraba un mensaje en pantalla. Obviamente, debería haberse evaluado que la detección de cualquier archivo generado con estas utilidades generaría lo que se denomina un falso positivo ya que el mismo no era un virus, sino una porción inofensiva del mismo. Sin embargo, CNET evaluaba los productos de acuerdo con su capacidad de detectar estos archivos generados con las utilidades Rosenthal. Dos años más tarde, CNET no sólo continuaba cometiendo el mismo error [1] sino que complicando aún más esta situación, alteraba virus reales, como VBS/Loveletter (con lo cual estaba creando nuevos virus) para defenestrar aquellos productos que "fallaban" en estas evaluaciones. Eventualmente y parcialmente debido a la presión de la industria [2, 3] CNET fue reduciendo progresivamente el uso de estos archivos generados con las utilidades Rosenthal. Los indetectables Particularmente mal explicada y consecuente y frecuentemente malintencionada, resulta la interpretación que se efectúa sobre las posibilidades de detección heurística de los productos antivirus, cuya evaluación ha sido tristemente inadecuado en casi todos los casos que el autor ha podido observar. Este artículo tiene como finalidad la de discutir, sobre bases científicas, las tecnologías heurísticas en que se asientan los productos antivirus en escenarios del mundo real, pero comenzaremos por describir más generalmente la metodología de evaluación. 101 metodologías para el análisis científico Una buena evaluación deberá probar una hipótesis, con total definición de sus premisas y metodología de ejecución y deberá registrar cualquier limitación y hecho relevante. Cuando se comparan productos que tienen distintas características, deberá aclararse específicamente cuáles serán las características a analizar y comparar, así como cuáles y determinadas funcionalidades o particularidades, son comunes a todos ellos. Tanto como sea posible, los examinadores deberán analizar y comparar lo semejante contra lo semejante en otros productos. Cuando la metodología de análisis está deseando tener un efecto sobre el rendimiento del producto (por ejemplo, verificar los "mejores parámetros" o valores predeterminados) esto debería quedar indicado. La puntuación, si existe, debería reflejar solamente las características comunes analizadas y cualquier parámetro adicional no debería ser incluido en la puntuación o, incluirse por separado. Cualquier carga adicional debería ser explicitada claramente de modo que los resultados en bruto estén disponibles. Al efectuar cualquier análisis comparativo, estos parámetros deberían ser esenciales: - Integridad de los datos estadísticos usando métodos reconocidos. - Documentación completa. - Presentación de los resultados que deberían emanar desde el análisis científico de los datos obtenidos alejado de miradas subjetivas. (Asombrosamente, esto es lo que a menudo tiene cierto parecido cuando se muestra el valor final dado a la calificación de los datos obtenidos en los análisis). - La disponibilidad de conjuntos completos de muestras de productos de diversos fabricantes y entes independientes (esto es lo último para quienes pudieran tener la habilidad para verificar cualquier tipo de resultado después de realizado por los examinadores). Demasiado a menudo los ejemplos seleccionados están seriamente dañados, llevando a resultados incorrectos de la comparación. El peor error incluye el análisis contra archivos no replicables, archivos alterados o con nombres cambiados (esto más tarde será todo un asunto, por ejemplo, si el análisis por extensión es un valor predeterminado y la comparativa se realiza contra estos valores por defecto). El tamaño de la muestra a considerar también es todo un tema. Comparar productos contra dos o tres archivos no va a probar casi nada sobre las posibilidades de detección del producto: el más pequeño tamaño de muestreo puede producir el mayor error de apreciación. Sin embargo, se da aquí una interesante paradoja ya que en términos de detección de virus, estadísticamente, sólo menos del 5% de todos los conjuntos de muestras (todos los virus escritos) tienen alguna importancia en el mundo real. La mayoría de esos virus sólo existen en las denominadas colecciones "zoo" (o "virus de colección") en poder de varias empresas antivirus y laboratorios relacionados. A los efectos de los análisis comparativos, los virus que aparecen en WildList [6] son más significativos que aquellos que se encuentran en las colecciones "zoo". Como dato adicional, WildList posee dos niveles de clasificación: la lista principal (Top list) que está constituida por aquellos virus que han sido informados por al menos dos delegados de WildList y la lista suplementaria, cuando sólo se ha recibido una muestras de un solo agente WildList. Una muestra de virus con un sólo informe recibido tiene un valor estadísticamente apenas más significativo que un virus "zoo". Debemos hacer aquí un pequeño acuerdo sobre qué constituye un conjunto de muestras "zoo" y consecuentemente, entender que la mayoría de los examinadores usarán diferentes conjuntos de muestras "zoo" (así como sucede con frecuencia que las comparativas son efectuadas contra "archivos que hemos encontrado en nuestro correo") lo cual introduce desestabilizantes errores. Esto también es considerablemente posible, dado el monumental crecimiento de nuevos ejemplos todos los meses que incrementan significativamente las estadísticas de muestras basura en las colecciones "zoo". Entre la basura hay una enorme cantidad de material en zona "gris", como pudieran ser archivos de registro que han sido dejados por virus (como instancias de registro de un archivo) o archivos que han sido usados como parte de una secuencia de infección. También pudiera haber archivos dañados (que no pueden ser replicados), troyanos, bromas (Joke), intentos de virus, archivos desinfectados (que pudieran estar incluidos en archivos no víricos dejados o abandonados por virus), archivos antiguos que ya no podrán ser ejecutados en sistemas modernos y otra gran cantidad y variedad de otro tipo de "ruido". [4, 5] Esto y una falta de acuerdo en las definiciones sobre que debería ser detectado o informado, significa que las comparativas o análisis de productos están incrementando la dificultad para ser ejecutados correctamente, ciertamente en términos de implicaciones estadísticas. Es importante conocer por qué un producto ha fallado con un determinado análisis así como saber qué es lo que ha fallado. Si el fracaso ha sido como resultado de un diseño defectuoso del examen, sería posible proveer la documentación del mismo para probarlo bajo esas particulares condiciones. La documentación debería ser escrita antes de efectuar las verificaciones así como debería proveerse las hipótesis de trabajo y la descripción exacta de la metodología a usarse. Cualquier desviación de la metodología indicada en la documentación debería ser informada y justificada. Las puntuaciones calculadas y sus fórmulas, deberían ser establecidas pudiendo ser demostradas y comprobadas vinculándoselas con las hipótesis de análisis. Cualquier ponderación de valor debería ser detallada y justificada ampliamente. Las fallas de los productos que ocurrieran fuera de las premisas establecidas, no deberían ser consideradas en la calificación final. Si por ejemplo, un producto tiene problemas de estabilidad o instalación y no se ha establecido dicho parámetro como hipótesis de análisis, dicho problema no debería ser considerado en la puntuación. Cuando el producto no pudiera ser analizado como consecuencia de ese problema, no contemplado en las hipótesis originales, debería quedar registrado que el mismo ha sido excluido a causa de esto pero que no se ha podido verificar el resto de los parámetros. Las fallas individuales en conjuntos de virus polimórficos deberían ser mostradas como un porcentaje de este valor discreto del conjunto, usualmente mayor de 1000 replicaciones por ejemplo, y no como un porcentaje sobre el índice sobre todas las detecciones o en caso contrario, la discriminación debería introducirse. Los valores resultantes deberían ser diferenciados de acuerdo a cada hipótesis y, si el promedio fuera calculado, este método de medición debería ser establecido previamente. Definiendo un escenario de examen para el análisis de la detección heurística Esto no intenta constituir una exhaustiva metodología ni pretende establecer el mejor escenario para examinar la capacidad de un producto para el análisis heurístico, pero sí, proveer elementos básicos sobre los que una exhaustiva metodología debería poder desarrollar. Para ser un verdadero examen de detección heurística, la muestra ideal sería aquella constituida por virus que todavía no han sido catalogados por este producto al momento de hacer la verificación. Esto es posible de efectuar examinando la heurística contra un gran conjunto de muestras, como por ejemplo las de WildCore y removiendo los archivos de actualización del producto (las firmas de virus) asumiendo que el producto trabaja también de este modo. El mejor camino sería el de "congelar" un producto en el tiempo (sin actualizar durante ese periodo) y posteriormente examinarlo en su accionar contra virus que han aparecido desde el momento de su "congelamiento" hasta el momento de la verificación. La capacidad heurística es usualmente actualizada con frecuencia, aún más que la detección convencional, por lo cual, analizar versiones muy antiguas de un producto (semanas o meses) no traerá una real indicación de su capacidad. Idealmente, debería examinarse la última versión de un producto, pero sin sus firmas de virus. Verificación de las muestras El conjunto de virus de muestra debería ser compuesto sólo por verificadas copias de ejemplos víricos. La única verificación válida de que un archivo es un virus, es su capacidad de replicarse (idealmente, a una segunda generación, aunque una replicación simple, usualmente ya califica, con la excepción de conjuntos de virus polimórficos). Usando un producto antivirus (o un grupo de productos) para determinar cuando o no algo es un virus y efectuar la selección del conjunto de muestras, es una metodología inválida porque su propio error de evaluación o su eficacia son determinantes estadísticamente. Si la evaluación es efectuada con muestras no replicadas (o se asume que han sido efectuadas por su viabilidad de extrapolación) no hay una base científica para el examen. Desafortunadamente hay muchos casos de exámenes en los cuales se usa una "caja negra" de selección de muestras combinada con la falta de documentación y la falta de disponibilidad de las muestras para una posterior nueva verificación. Especialmente cuando los conjuntos de muestras son pequeños, este tipo de problemas pueden cambiar significativamente los resultados de la comparativa. Parámetros e hipótesis Debería considerarse el precio de utilizar el modo predeterminado de ejecución de cada producto. Por ejemplo, algunos productos poseen una detección heurística más agresiva cuando analizan el tráfico de correo (POP3 y SMTP) que en el módulo de análisis residente. Si este fuera el caso, debería considerarse esto como el mejor escenario "de la vida real" y usarse el reajuste de análisis de componentes a sus parámetros por defecto para analizar correctamente o, en las versiones que admitan la configuración por línea de comandos, establecer los parámetros adecuados, si estuvieran disponibles. Algunas hipótesis de ejemplo para el examen de la capacidad heurística: 1. El módulo de análisis deberá tener habilitada la detección heurística de virus y detectar más del 0% de virus sin necesidad de actualizar su base de firmas de virus. 2. Cuanto mayor sea el porcentaje de detección, mejor será la capacidad de detección heurística. 3. La detección por análisis heurístico no deberá incrementar significativamente la incidencia de falsos positivos (sería muy útil definir un porcentaje, aunque no siempre esto es necesario). Ejemplos de premisas: - La heurística debería hacer descender la probabilidad de riesgo de ser infectado con nuevos virus aún no catalogados. - La habilitación de la detección heurística en el módulo de análisis debería provocar un incremento en la detección mayor de cero (o sea, que el resultado debería ser mejor que si no tuviera la heurística habilitada) incrementando las probabilidades de detectar nuevos o modificados virus, protegiéndolos contra ellos. Exámenes de control Es muy útil para cada producto el volver a examinarlo, dejando constancia de ello, contra el conjunto de las mismas muestras (por ejemplo, In the Wild) con el producto totalmente actualizado a la fecha de su comprobación. El propósito de esto, es dejar asentado si bajo condiciones normales de operación y actualización, la detección heurística sigue estando disponible con el mismo conjunto de muestras. Esta prueba otorga una implicancia clave desde el punto de vista estadístico. El índice de fallo del producto contra el mismo conjunto de muestras después de su actualización completa provee una inferencia estadística sobre el total del índice de errores contra el conjunto total de muestras "In the Wild". El índice de fallos sobre esta prueba de heurística no es una inferencia estadística contra el conjunto total de muestras "In the Wild". O sea, no es correcto decir que el índice de fallos (o detección) contra el conjunto total de muestras principales (WildCore) sea igual que contra el conjunto actualizado (y acotado) de muestras, con la excepción que el conjunto total de muestras WildCore haya estado siendo analizado totalmente por heurística y sin ningún tipo de actualización, porque la detección debería darse para las muestras "In the Wild" antes de haber sido acotadas las mismas. Alcanzar el correcto índice estadístico de errores es crítico para darle validez a los resultados de los exámenes. Idealmente, un examen completo sobre el producto actualizado contra las muestras principales "In the Wild" debería alcanzar los resultados correctos, pero el examen completo actualizado de detección contra el conjunto de muestras, después de haberse acotadas, tiene su impacto estadístico de tanta importancia como su incidencia estadística tenga el conjunto de muestras (por ejemplo, debería ser considerado, cuando se verifique al menos un 10% del tamaño del conjunto principal, contra índices de error esperados). También idealmente, una aproximación heurística debería mantener un índice del 0% de falsos positivos de la misma forma que un índice del 0% de falsos negativos. Un conjunto de muestras no infectadas determinará el índice de fallo. En este caso, la hipótesis no necesita un 0% de falsos positivos, aunque por supuesto, un alto valor estadístico de falsos positivos no sería deseado y podría ser usado como coeficiente hostil que desvíe los resultados. Debería notarse que ciertos escenarios de análisis, como por ejemplo, POP3 o el tráfico SMTP, pueden tener un alto valor de sospecha sobre cada archivo adosado y cada código ejecutable que es transferido, siendo que los falsos positivos no son deseables y tienen una impacto negativo directo sobre la estabilidad del sistema o la reacción del usuario, aunque no es una razón para no analizar la posibilidad de falsos positivos. La aparición de falsos positivos en un módulo de análisis en el acceso (residente en memoria) pudiera tener severas implicancias, particularmente para asediados soportes técnicos corporativos, siendo usual que se disponga, en esos casos, valores heurísticos predeterminados más benignos por esta razón. Idealmente, este control debería tener un orden de magnitud tan grande como el conjunto de muestras virales, preferentemente tan grande como el conjunto principal. En el caso de algún falso alerta, el archivo disparador de esto debería ser guardado y copias del mismo deberían estar disponibles para el desarrollador del producto. También debe hacerse notar cuando un falso positivo es generado como consecuencia de haber utilizado archivos de prueba modificados (algunos examinadores usan deliberadamente virus desnaturalizados o dañados para que sean mostrados como sospechosos) o archivos "normales" que puedan existir normalmente en los sistemas considerados. Idealmente, los fallos contra los archivos sospechosos deliberadamente modificados, deberían ser incluidos en una estadística separada o simplemente no ser registrados, después de todo, estamos discutiendo acerca de los escenarios de la vida real. Un control ideal sobre archivos "limpios" debería tomar la forma de un conjunto estadístico válido considerando un conjunto de archivos verificados no infectados existentes en un sistema normal de un usuario final. Metodología Como ha sido mencionado someramente en los párrafos anteriores, hay dos exámenes que deben ser completados acerca de las capacidades heurísticas y es importante establecer cómo los mismos serán abordados: la primera medición de la capacidad del producto debe hacerse sin actualizaciones y la segunda, contra virus específicos después de haber actualizado el programa. El primer análisis es para mostrar la disminución significativa de la detección en el transcurso del tiempo, así como la reacción cuando son encontrados nuevos tipos de virus y mientras tanto, probablemente lo más interesante del análisis, los resultados deberían ser mayormente irrelevantes cuando un producto correctamente instalado (y por supuesto, su heurística) es actualizado (de hecho, este examen necesariamente ignora). No sería de desear que la evaluación sobre la heurística de un producto que tiene más de tres meses sin actualizar refleje las actuales posibilidades del mismo. El segundo (y más discutible) examen es a partir de un punto congelado en el tiempo, siendo importante por varias razones: Primero, por que cada muestra debería ser nueva para cada producto, de otra forma, estaría indicando que la heurística no está siendo utilizada y en segundo término, porque el producto analizado debe ser el último disponible al público, antes de la aparición del código malicioso. La mayoría de los productos son actualizados automáticamente cada hora, o al menos diariamente, por lo que el examen no debería ser ejecutado usando un producto significativamente antiguo (no mayor de 12 horas). Implicancias estadísticas Examinar heurística trae naturalmente cierto grado de prejuicio o dudas, porque el conjunto de pruebas no es algo fijo. Si el examen es efectuado con diferentes puntos de actualización o el conjunto de muestras es expandido, el grado de influencia puede ser mayor o menor. Por esta razón, dos escenarios de prueba idénticos, usando diferentes puntos de congelamiento de las muestras antes y después de la actualización pueden producir resultados significativamente diferentes. Asumir esta situación sobre el rendimiento total de un producto sólo puede generar resultados valederos considerando un largo período de tiempo con exámenes reiterados. Esto proveerá un significativo promedio del rendimiento. Una simple actualización, por ejemplo, un día después de haber acotado (o congelado) un conjunto de muestras (para detectar el primer virus de una nueva familia) puede torcer el resultado significativamente si, como en el caso de las familias Bagle y Netsky, muchas variantes son lanzadas (una modificación de un virus conocido debería ser detectada heurísticamente de forma más sencilla que un ejemplo totalmente nuevo). Una amplia diversidad de familias apareciendo después del momento del congelamiento del conjunto de muestras reduce el índice de detección a través del rango completo del producto. Sería casi imposible crear un modelo totalmente acotado para examinar la capacidad heurística dado que requeriría un completo nuevo análisis a partir de cada muestra actualizada después del congelado original del conjunto de muestras, provocando a su vez, un nuevo punto de referencia sobre el momento de certidumbre a considerar para el examen. Habiendo dicho esto, es todavía posible crear un modelo de examen que otorgue resultados estadísticos válidos, si el suficiente rigor científico es aplicado y los resultados son expresados en términos no absolutos. Referencias [1] CNET. Demostrando una metodología defectuosa (a través de techrepublic): "Norton AntiVirus 2002: There's no better AV solution for Windows XP" http://techrepublic.com.com/5102-6270-1043870.html [2] En el año 2000, miembros de la industria antivirus, dirigidos por Joe Wells, escribieron una carta pública a CNET, denunciando su metodología de comparación: "Credibility and Ethics in Antivirus Product Reviewing. An Open Letter to CNET" http://www.nod32.com/news/joe_wells.htm [3] La respuesta de CNET, en mayo de 2002 "NOD32 trashed by CNet / ZDNet review !!!" http://www.nod32.com/news/cnet_zdnet.htm [4] "Bontchev. V.: Analysis and Maintenance of a Clean Virus Library.." http://www.virusbtn.com/old/OtherPapers/VirLib/ [5] "Kaminski, J. Malware Evolution As A Cause of Quality Deteroration Of Anti-Virus Solutions." En U.E. Gattiker (Ed.) EICAR 2004 Conference CD-rom: Best Paper Proceedings, Copenhagen: EICAR e.V. [6] Real Time Wildlist http://www.wildlist.org/WildList/RTWL.htm * Información publicada con autorización de Virus Bulletin * Autor: Andrew Lee. Eset LLC, USA. * Traducción y adaptación al español: Ontinet.com, S.L. (c) Video Soft - http://www.videosoft.net.uy (c) VSAntivirus - http://www.vsantivirus.com