"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)
[Nota de la redacción:
se ha publicado información
en español
sobre este tema en
abril
y mayo
de 2002].
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 denomima
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 tan
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
explicado y consecuente
y frecuentemente malintencionado,
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 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, ciértamente
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:
- 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.
- Cuanto mayor sea
el porcentaje
de detección,
mejor será
la capacidad
de detección
heurística.
- 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 razon, 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 Netzky, 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 examinación
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
- CNET. Demostrando
una metodología
defectuosa.
A través
de techrepublic:
http://techrepublic.com.com/5102-6270-1043870.html.
- 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.
http://www.nod32.com/news/joe_wells.htm.
- La respuesta
de CNET,
en mayo
de 2002
en
http://www.nod32.com/news/cnet_zdnet.htm.
- Bontchev.
V.: Analysis
and Maintenance
of a Clean
Virus
Library..
http://www.virusbtn.com/old/OtherPapers/VirLib/
- 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.
- Real Time
Wildlist
http://www.wildlist.org/WildList/RTWL.htm
|