PDF de programación - ¿Cuánto tardan los grandes fabricantes en arreglar una vulnerabilidad?

Imágen de pdf ¿Cuánto tardan los grandes fabricantes en arreglar una vulnerabilidad?

¿Cuánto tardan los grandes fabricantes en arreglar una vulnerabilidad?gráfica de visualizaciones

Actualizado el 24 de Abril del 2017 (Publicado el 14 de Enero del 2017)
1.066 visualizaciones desde el 14 de Enero del 2017
1,9 MB
49 paginas
Creado hace 14a (23/09/2009)
¿Cuánto tardan los grandes
fabricantes de software en
arreglar una vulnerabilidad?

Estudio sobre la demora de los fabricantes de
software en la corrección de vulnerabilidades no
públicas

Hispasec Sistemas
Septiembre 2009





Creative Commons Reconocimiento-No comercial-Sin obras derivadas 3.0 Unported.

Basada en un trabajo de Hispasec Sistemas

Todas las marcas y logotipos que se encuentran en este estudio son propiedad de sus respectivas

Los permisos más allá de esta licencia están disponibles en Hispasec.com.

compañías o dueños.



h i s p a s e c . c o m

2

Introducción



_ ¿Cuánto tardan los grandes fabricantes de software en arreglar una
vulnerabilidad?

El tiempo que un fabricante tarda en hacer pública una solución para una vulnerabilidad es una de las
métricas más importantes para conocer cómo maneja la seguridad. Suele existir cierta controversia en este
aspecto. Se achaca a los fabricantes que tardan demasiado en disponer de una solución efectiva que ofrecer a
sus clientes o usuarios. Mucho más cuando la vulnerabilidad es conocida y por tanto sus clientes “perciben”
el peligro de utilizar ese software.

Existen dos escenarios muy diferentes a la hora de solucionar una vulnerabilidad: que sea conocida
públicamente, o que no. Esto es determinante para los grandes fabricantes. En el segundo caso, el ritmo
de solución es muy distinto al primero. Su imagen no está en entredicho, los clientes no se sienten en
peligro... pueden tomarse la solución con más calma, y centrarse en asuntos mucho más urgentes (que seguro
que existen). En Hispasec nos hemos preguntado cuánto tardan los grandes fabricantes en
solucionar una vulnerabilidad cuando no sufren la presión de los medios, cuando la
vulnerabilidad es solo conocida por ellos y quien la ha descubierto. Cómo reaccionan ante esta
situación “ideal” (desde su punto de vista), en la que la vulnerabilidad les ha sido comunicada en secreto, y
ambas partes acuerdan no hacerlo público hasta que exista una solución.

Este es un escenario relativamente sencillo de evaluar, puesto que podemos tomar la fecha en la que el
fabricante fue informado como inicio del contador, y la fecha en la que se publica una solución como final. El
tiempo que haya transcurrido nos permitirá saber de forma precisa cuánto tardan los
fabricantes en solucionar una vulnerabilidad que no es pública. Nos hemos servido de iDenfense y
ZeroDayInitiative para realizar un pequeño estudio al respecto.

_ iDenfense y ZeroDayInitiative

Son dos iniciativas de compañías privadas que compran vulnerabilidades, con la única condición de que se le
cedan en exclusiva. La intención de estas dos empresas es apropiarse de vulnerabilidades relevantes en
sistemas muy usados. Los investigadores privados que encuentren un fallo, pueden acudir a ellos a vender los
detalles. Una vez pagan por la vulnerabilidad, estas dos empresas aplican la política de “revelación
responsable”, es decir, informan al fabricante del problema y anuncian el fallo (siempre que sea posible) solo
cuando existe parche disponible. Ambas compañías esperan (a veces pacientemente) a que el fabricante haya
solucionado la vulnerabilidad para hacer público su descubrimiento. Se centran en grandes empresas de
software, y sobre ellas hemos realizado el estudio. También se centran en vulnerabilidades relevantes, que
supongan un impacto real y que permitan realmente ser explotadas por un atacante.

_ Cómo se ha realizado el estudio

Una vez que la vulnerabilidad sale a la luz, tanto iDefense como ZeroDayInitiative publican una cronología de
la vulnerabilidad, en la que ofrecen información sobre cuándo fue informado el fabricante, cuándo reconoció
el fallo, y cuándo se estableció un fecha en la que ambos harían pública la vulnerabilidad (que normalmente
es cuando existe parche). Si se da algún tipo de incidencia durante ese periodo (que el fabricante o
descubridor necesite más información, se niegue a solucionarlo...) también queda reflejado en él.

Nos hemos servido de esa cronología para calcular cuánto tiempo necesita el fabricante para
solucionar un fallo, desde que se le informa hasta que publica un parche. Pero bajo una
condición muy importante: la vulnerabilidad no es pública. Se supone que solo el descubridor, la empresa
intermediaria (iDefense y ZeroDayInitiative) y el fabricante la conocen. ¿Cómo actúan los fabricantes sin la
presión de que el fallo sea público o esté siendo aprovechado activamente?

El tiempo que necesita el fabricante normalmente incluye:

* Reconocimiento y estudio de la vulnerabilidad
* Pruebas y alcance
* Programación del parche
* Pruebas de estabilidad, interoperabilidad y rendimiento del parche
* En el caso de que (como Oracle, Microsoft, y ahora Adobe) se siga la política de publicación de parches en

unas determinadas fechas, se añade además esa diferencia de días hasta la fecha establecida.



h i s p a s e c . c o m

3

Hemos identificado cada vulnerabilidad por su CVE. También hemos querido añadir el valor base del CVSS

(versión 2) a cada una de ellas, para que se pueda apreciar la gravedad de la misma.


_ CVE

El CVE es el Common Vulnerabilities and Exposures, un estándar (administrado por la organización
Mitre.org) que se encarga de identificar unívocamente a las vulnerabilidades. El CVE ha tenido gran
aceptación entre todos los fabricantes porque la mayor parte de las veces es muy complejo saber a qué
vulnerabilidad nos estamos refiriendo solo por ciertas características. Se hace necesario una especie de
número de identidad único para cada fallo, puesto que en ocasiones son tan parecidas, complejas o se ha
ofrecido tan poca información sobre ellas que la única forma de diferenciar la vulnerabilidad es por su CVE.
Si no existe CVE del problema, lo hemos identificado por el CVE genérico CVE-000-000. Algunas
vulnerabilidades están identificadas por un “CAN” en vez de “CVE”. Se trata del formato “antiguo” que ya no
es usado por Mitre.org.

En algunas ocasiones, incluso aunque contradiga el concepto, varias vulnerabilidades pueden estar
identificadas con un mismo CVE. En estos casos lo que la identifica es el título asociado. Esto ocurre
cuando una misma zona de código contiene varias vulnerabilidades, o ese mismo código genera varios fallos
distintos. Los fabricantes en estos casos, a veces, agrupan varias vulnerabilidades dentro de un mismo CVE y
lo solucionan todos a la vez, aunque hayan conocido el fallo en distintos momentos.


_ CVSS

CVSS (Common Vulnerability Scoring System), un estándar que gradúa la severidad de manera estricta a
través de fórmulas establecidas. De esta forma los administradores conocerán de manera objetiva (a través
de un número) la gravedad de los fallos. Está basado en los tres pilares de la seguridad de la información: la
confidencialidad, integridad y disponibilidad de los datos, además de si el problema es aprovechable en
remoto o local, la complejidad de explotación y la necesidad de estar autenticado en el sistema. Cuanto más
próximo a 10, más grave es la vulnerabilidad.


_ Con qué criterio se han elegido las vulnerabilidades

Se han elegido todas las vulnerabilidades de cada fabricante, reportadas a iDefense y ZeroDayInitiative desde
2005 hasta final de agosto de 2009. Algunos fabricantes tienen cientos de vulnerabilidades y otros apenas
unas decenas. Esto no quiere decir absolutamente nada sobre la cantidad de vulnerabilidades
que sufren sus productos, o que un producto sea menos vulnerable que otro. Significa
simplemente que se reportan menos a través de estos métodos, bien porque no interesen a los propios
iDefense o ZeroDayInitiative, bien porque no interesen a los investigadores. Evidentemente, por
popularidad, el número de alertas de Microsoft Windows es significativamente mayor en este
estudio. La cuestión es simple: se reportan más a través de estos métodos porque son las
vulnerabilidades mejor pagadas. Sin duda otros sistemas sufren de igual número de vulnerabilidades,
pero al ser peor pagadas o interesar menos, no se reportan a través de iDefense o ZeroDayInitiative.

Según fabricante, el número de vulnerabilidades estudiadas que han sido reportadas desde 2005 a iDefense y
ZeroDayInitiative son:



Fabricante

Número de vulnerabilidades estudiadas

Sun

Novell

HP

Microsoft

Apple

IBM

CA

36

41

14

130

61

56

36



h i s p a s e c . c o m

4




Symantec

Oracle

Adobe

30

16

29



_ Mala interpretación de las cifras

Este estudio ofrece unas cifras. Las cifras adornan titulares y rellenan gráficas, pero no hay que olvidar que
informan en un contexto. Por sí solas no siempre tienen valor. Hay que reconocer que es complicado realizar
un estudio objetivo en este aspecto, pero lo hemos intentado en la medida de lo posible. Los valores
ofrecidos no pretenden más que ofrecer una noción de cuánto tarda un gran fabricante en
solucionar un fallo que le ha sido reportado a través de iDefense o ZeroDayInitiative. No
podemos aventurarnos a opinar sobre cuánto tarda en solucionar fallos que son reportados por otras vías,
puesto que muchas de las vulnerabilidades solucionadas por los fabricantes son descubiertas por su propio
equipo, y rara vez confiesan desde cuándo llevan trabajando en ellas.

Por tanto advertimos que estas cifras que
  • Links de descarga
http://lwp-l.com/pdf728

Comentarios de: ¿Cuánto tardan los grandes fabricantes en arreglar una vulnerabilidad? (0)


No hay comentarios
 

Comentar...

Nombre
Correo (no se visualiza en la web)
Valoración
Comentarios...
CerrarCerrar
CerrarCerrar
Cerrar

Tienes que ser un usuario registrado para poder insertar imágenes, archivos y/o videos.

Puedes registrarte o validarte desde aquí.

Codigo
Negrita
Subrayado
Tachado
Cursiva
Insertar enlace
Imagen externa
Emoticon
Tabular
Centrar
Titulo
Linea
Disminuir
Aumentar
Vista preliminar
sonreir
dientes
lengua
guiño
enfadado
confundido
llorar
avergonzado
sorprendido
triste
sol
estrella
jarra
camara
taza de cafe
email
beso
bombilla
amor
mal
bien
Es necesario revisar y aceptar las políticas de privacidad